Dear RIPE NCC RPKI team,
< Speaking with no hats >
Thank you for sharing current status, plans, and reasoning behind
prioritization choices. I'm excited to see RIPE NCC's 'hosted' RPKI
service offering starting to move beyond "just ROAs".
Kind regards,
Job
On Mon, May 20, 2024 at 10:35:51AM
Dear all,
Fun news! RPKI ROAs now cover 50% of the global Internet’s routing table.
We estimate 70% of traffic is send towards ROV-valid destinations.
An analysis on this milestone and propagation of invalid routes:
https://www.kentik.com/blog/rpki-rov-deployment-reaches-major-milestone/
Kind
Dear RIPE Routing WG,
This is a call for presentation proposals for RIPE 86! The RIPE 86
meeting takes place in about 66 days: https://ripe86.ripe.net/
We ask both the Working Group and RIPE NCC for presentation proposals
for the eminent 1.5 hour Routing WG slot on Wednesday, May 24th, 2023.
Dear all,
With 2023 at our doorstep, I'd like to share some perspective on how
RPKI evolved in the year 2022.
Impact on the Global Internet Routing System
Decision makers might wonder: is investing time and resources worth it?
What is the
Dear RIPE NCC,
Thanks for offering the opportunity share feedback. I'd like to comment
in individual capacity on the porposal Service Criticality ratings.
Summary: I consider the proposed criticality ratings appropriate for the
RPKI service.
Elaboration:
1/ Confidentiality
Comment:
Dear all,
[[ ... If you are looking for a fun way to spend some time on your
second-last Friday of the year ... please read on! ... :-) ... ]]
The working group is encouraged to consider commenting on the Service
Criticality Framework proposal for RPKI. Understanding the community's
Hi Klaus!
On Mon, Dec 12, 2022 at 12:12:03PM +0100, Klaus Darilion via routing-wg wrote:
> Until now we have not used RPKI. For us at nic.at and RcodeZero DNS we
> are not on the validating side of RPKI, but we would only create ROAs,
> using the RIPE service. I could just login to the RIPE
Dear RIPE Routing WG,
This is a repeat of the call for presentation proposals for RIPE 85.
The RIPE 85 meeting takes place in about 32 days: https://ripe85.ripe.net/
We ask the Working Group and RIPE NCC for presentation proposals for the
illustrious 1.5 hour Routing WG slot on Wednesday,
Dear RIPE Routing WG,
This is a call for presentation proposals for RIPE 85.
The RIPE 85 meeting takes place in about 64 days: https://ripe85.ripe.net/
We ask the Working Group and RIPE NCC for presentation proposals for the
illustrious 1.5 hour Routing WG slot on Wednesday, October 26th, 2022.
Dear all,
Last night many people received "Resource Certification (RPKI)" alerts,
which in turn caused my phone to light up with questions! :-) In the
below message I'll attempt to provide an analysis of what happend and
answer frequently asked questions.
* What happened?
* Has this happened
Dear all,
RIPE NCC has asked the Routing WG Chairs to facilitate a working group
conversation on framing RIPE NCC's RPKI services subcomponents in terms
of criticality.
At the bottom of this email is a form that focusses on three components:
confidentiality, integrity and availability. Each
Dear all,
On the #DENOG IRC channel I was asked for current stats on the number of
RPKI-invalid IRR route/route6 objects in various databases as follow-up
to a talk at RIPE81 [0]. I figured I should share this with the WG too.
Below is a table with today's stats of number of invalid route/route6
Hi,
A question was raised during today's RPKI Data Open House: "are CRLs used?"
Just now I ran some statistics on today's RPKI state using the 5 RIR TALs:
* There are 30,914 CRL files.
* In totality, these 30K CRLs list revocations for 331,637 serials.
* 5,369 CRL files don't list
Hi all!
Sharing here as FYI. The impact of this event is very hard to
understand.
Aspect 1/ BGP routes might be impacted depending on *when* IRR mirror
operators remove the ARIN-NONAUTH from their list of sources (as far as
I understand ARIN will disable FTP/NRTM access). Commonly used mirror
Hi all,
It might be the case that the vulnerability is in the realm of disagreement
with some design choices of the past, rather than a traditional CVE hole in
one or more software packages.
I found the following paper which touches upon the “assumed trust” aspect
of RPKI in the relationship
On Wed, 16 Feb 2022 at 19:49, Rob Austein wrote:
> On Wed, 16 Feb 2022 13:10:27 -0500, Job Snijders wrote:
> > On Wed, 16 Feb 2022 at 19:07, Randy Bush wrote:
> >
> > sra commented to me that, an rp doing protocol fall-over from rrdp to
> > rsync, or vice versa, has to do the full download as
On Wed, 16 Feb 2022 at 19:07, Randy Bush wrote:
> thanks for the post mortem, ties.
>
> sra commented to me that, an rp doing protocol fall-over from rrdp to
> rsync, or vice versa, has to do the full download as the data structure
> is so different. i.e. load spike
Perhaps it doesn’t need to
Hi Ties,
Thank you for the quick reply.
On Wed, Feb 16, 2022 at 03:32:06PM +0100, Ties de Kock wrote:
> Ouch. Fallback to rsync due to a DNS misconfiguration (which should
> have recovered).
Thanks for the confirmation. Indeed, my monitors seem to have returned
to 'all clear'.
> There are
On Wed, Feb 16, 2022 at 03:05:30PM +0100, Job Snijders wrote:
> However, it seems RIPE NCC adjusted the default rsyncd settings and
> lowered the concurrent connection count from 200 (which already is too
> low for RPKI Repository Servers) to 150?
Small correction: I appear to be confused about
Hi all,
I noticed the RIPE NCC RRDP service (https://rrdp.ripe.net/) became
unreachable at 2022-02-16 13:34:10 UTC+0 (and still is down).
This RRDP outage event should not pose an issue for most RPKI
validators, because most RPKI cache implementations (which follow best
practises) will attempt
Dear RIPE NCC RPKI team,
On Wed, Feb 09, 2022 at 10:26:14AM +0100, Bart Bakker wrote:
> We are pleased to announce that we have published the source code used
> by the RIPE NCC for the RPKI back-end (the RPKI core) under the
> 3-Clause BSD licence on Github: https://github.com/RIPE-NCC/rpki-core
On Tue, Dec 21, 2021 at 01:23:01PM -0800, Randy Bush wrote:
> > We hope you will find these reports useful
>
> very much so. thank you.
Yes, I'd like to echo what Randy says. Thanks for sharing this.
> btw, re RIPE-009 - Unencrypted Communication
>
> in the up/down protocol, objects are cms
Hi all,
I'm writing the working group to initiate some conversation about a
long-standing point of confusion in the RPKI ecosystem: the ROA
MaxLength field.
What is the ROA MaxLength field?
The data format profile of RPKI ROAs allows an operator to specify the
Dear Bart, RIPE NCC RPKI team,
On Fri, Dec 03, 2021 at 12:47:05PM +0100, Bart Bakker wrote:
> Continuing from the work we started last year on strengthening our
> security compliance, we have asked an external party to carry out a
> security audit of our RPKI code. This was an important element
On Mon, Oct 11, 2021 at 11:33:40AM +0200, Tim Bruijnzeels wrote:
> Why now?
There are published RFC and running code. Time for the next step.
> RIPE NCC may have substantial resources, but they are applied
> sequentially. Perhaps RIPE NCC can shed a light on the effort
> involved, but I suspect
On Thu, Oct 07, 2021 at 04:30:58PM +0200, Tim Bruijnzeels wrote:
> If this is added to the RIPE NCC RPKI backlog then I would also
> request that LIRs, and PI holders, can have multiple CAs publish at
> the RIPE NCC. The reason for this is that one of benefits of running a
> delegated CA lies in
On Wed, Oct 06, 2021 at 04:08:00PM +0200, Tim Bruijnzeels wrote:
> Contrary to Route Origin Validation (with ROAs) there is no 'not
> found' state.
I don't think it is helpful to attempt to put BGPsec and ROAs in the
same equivalance class, draw parallels and then conclude that the
'not-found'
On Mon, Oct 04, 2021 at 11:48:12PM +0330, Ehsan Ghazizadeh wrote:
> Its an old doc worth reading.
You are offering the working group information from 2009. The same year
"Call of Duty: Modern Warfare 2" was released.
Since then, a number of IETF-consensus documents have been published.
For
Hi Ehsan, working group,
On Mon, 4 Oct 2021 at 14:17, Ehsan Ghazizadeh wrote:
> As far as i know, no vendor supports bgpsec, so what's the point of adding
> bgpsec support to hosted rpki?
>
There already are multiple RPKI validators which support BGPsec, multiple
signers, and multiple
Dear Nathalie, group,
On Mon, Sep 20, 2021 at 03:11:22PM +0200, Nathalie Trenaman wrote:
> Please be aware that the roadmap you mentioned just shows the roadmap
> for the current quarter and not for a longer period.
Ah, thank you for the clarification.
Are there any other items that predate
Hi working group,
In recent mail threads the concepts of "Hosted RPKI" and "Delegated
RPKI" came up, but as mentioned by Tim and Rubens, another flavor also
exists! A "hybrid" between Delegated and Hosted, informally known as
"publish in parent" (aka RFC 8181 compliant Publication Services).
Hi Rubens, others,
On Sun, Sep 19, 2021 at 08:06:54PM -0300, Rubens Kuhl wrote:
> Our experience in Brazil is that delegated RPKI is not much of an
> issue provided its software deployment is easy enough. Krill + Lagosta
> + Up/Down activation + Upwards ROA publishing adds to being really
>
Dear all,
[ TL;DR: What does the working group think about supporting an extension
to the RPKI Dashboard to enable publication of BGPsec certs? ]
At the moment the hosted "RPKI Dashboard" at https://my.ripe.net/#/rpki,
only permits Resource Holders to create RPKI objects of one specific
Hi Tim,
> But this should start with a problem statement which is discussed in
> the IETF. The context of the RPKI standards matter and a lot of the
> contributors to those standards are not active here.
It is not uncommon for initiatives to start in a special interest group
outside the IETF,
On Fri, Sep 10, 2021 at 11:39:39AM +0200, Tim Bruijnzeels wrote:
> I think all would agree that transparency is good.
>
> A key difference between RPKI and most other PKIs is that in the RPKI
> all objects are published in the open for all the see.
Small nitpick: all objects are SUPPOSED to be
Dear all,
With summer turning to fall in the Northern Hemisphere, yet again a new
schoolyear is ahead of us! :-) I hope you all are well.
I'm writing the group to solicit feedback for me and others to consider
during upcoming deliberations about activity plans, but even more so as
an RPKI
On Tue, Jul 13, 2021 at 05:25:11AM +0200, Daniel Karrenberg wrote:
> It might also be that the operational community has chosen other fora to
> discuss because this working group is not working.
What a strange thing to say. Of course there are other fora to discuss
RPKI, one of the most important
Hi,
On Mon, Jul 12, 2021 at 10:23:20AM +0200, Daniel Karrenberg wrote:
> Natanlie pointed us to
> https://www.ripe.net/manage-ips-and-asns/resource-management/rpki/rpki-planning-and-roadmap
> a while ago. Among other things this says:
>
> “In preparation for the improved RPKI repository
On Fri, May 07, 2021 at 03:29:44PM +0200, Nathalie Trenaman wrote:
> Our ops team just enabled ICMP echo-reply on rpki.ripe.net.
Thank you. Have a good weekend!
Kind regards,
Job
On Wed, May 05, 2021 at 12:52:51PM +0200, Kurt Kayser wrote:
> you surely know that every enabled protocol/port is a potential threat.
Sometimes disabling a protocol or port is a potential threat (because
hindering troubleshooting efforts harms network stability).
RIPE NCC is the only RIR that
Hi RIPE NCC, hi all,
In today's troubleshooting adventure, an operator experienced difficulty
pinpointing where exactly a connectivity issue between them and
rpki.ripe.net (193.0.6.138 + 2001:67c:2e8:22::c100:68a) resided.
It would be helpful if RIPE NCC reverted disabling responding to ICMP
Dear Rubens, all,
On Tue, Apr 27, 2021 at 10:18:32PM -0300, Rubens Kuhl wrote:
> TC IRR, an IRR operator focused on Brazilian networks, just changed to
> IRRd 4.2. The new version allowed TC to deploy RPKI validation
> (thanks NTT for sponsoring that development) and expose HTTPS
> endpoints for
Dear group,
I'd like to draw your attention to an excellent article on an intricate
interaction between BGP and TCP which can result in 'zombie routes' in
the BGP Default-Free Zone.
https://blog.benjojo.co.uk/post/bgp-stuck-routes-tcp-zero-window
My current running theory on the root cause
Dear Ties, group,
Thank you for the outline.
On Wed, Apr 14, 2021 at 02:33:37PM +0200, Ties de Kock wrote:
> The RPKI application does not support writing the complete repository to disk
> for each state (as needed for spooling the repository as proposed in scripts).
> Synchronously writing
Hi all,
Some might be wondering what the deal is with RSYNC and RRDP?
Why it is critical to continue to support RSYNC in the mid-term?
What's the industry's plan to migrate from RSYNC to RRDP?
TL;DR - All RIRs need to support both RSYNC and RRDP until at least 2024.
- All RRDP-capable
On Mon, Apr 12, 2021 at 02:12:10PM +0100, Nick Hilliard wrote:
> Erik Bais wrote on 12/04/2021 11:41:
> > This looks to be a 3 line bash script fix on a cronjob … So why
> > isn’t this just tested on a testbed and updated before the end of
> > the week ?
>
> cache coherency and transaction
Dear W. Boot,
On Thu, Apr 01, 2021 at 12:38:27PM +0200, W. Boot wrote:
> Would "invalid" also include unsigned space?
No. By definition, unsigned space can never ever be "RPKI invalid".
In order for any BGP route to be marked as "RPKI invalid", a RPKI ROA
_MUST_ exist. Without covering ROAs,
Hi all,
The expectation is that we can watch material in the way it was intended,
and have the presenter around for live Q and A / discussion. Presenters can
even answer questions while the information is being distributed, which I
find to add a new level of interaction previously not possible!
Dear RIPE Routing WG,
This is a call for presentation proposals for RIPE 82.
The RIPE 82 meeting takes place in about 8 weeks: https://ripe82.ripe.net/
We ask the Working Group and RIPE NCC for presentation proposals for the
illustrious 1 hour Routing WG slot on Thursday, May 20th 2021.
When
Dear RIPE NCC,
On Thu, Mar 18, 2021 at 04:03:16PM +0100, Nathalie Trenaman wrote:
> From the network operations perspective, there are no obstacles to
> enable ROV on AS
Excellent news!
> however, we have to consider that members or End Users who announce
> something different in BGP than
Dear RIPE NCC,
On Wed, Feb 17, 2021 at 11:28:32AM +0100, Nathalie Trenaman wrote:
> > The multitude of RPKI service impacting events as a result from
> > maloperation of the RIPE NCC trust anchor are starting to give me
> > cause for concern.
>
> I’m sorry to hear this. Transparency is key for
Dear RIPE NCC,
On Tue, Feb 16, 2021 at 04:56:31PM +0100, Nathalie Trenaman wrote:
> On Monday, 15 February we encountered an issue with our RPKI software.
> This issue prevented us from publishing RPKI object updates from
> 08:07-18:06 (UTC).
>
> During this period, Certificate Authority
52 matches
Mail list logo
