[Sidrops] RPKI protocol development (was: Re: Update on Re-chartering)

[Nick Hilliard <[e-mail]>]

[e-mail] wrote on 17/10/2025 13:45:
> The two-step approach was initially meant to unlock quickly 
> draft-ietf-sidrops-manifest-numbers. However, given that it seems that 
> the authors of that draft are not in rush, the discussion around exact 
> language for adding implementation requirement into the charter, and 
> some charter item proposal (e.g., from Chongfeng), I have withdrawn the 
> recharter from the last week IESG telechat so that we go straight with 
> more changes to the charter.


Hi Med, Chairs,

We have a number of serious real world operational problems with the 
RPKI at moment and speaking with my DFZ operator hat on, there is 
urgency about the status of some of the protocol documents which are 
currently in the sidrops pipeline.

The first problem relates to ASPA. This is the first inter-domain AS 
path filtering policy mechanism that looks like it's going to fit the 
sweet spot of 1. providing enough functionality to be useful, 2. 
straightforward to configure and 3. scalable and automable. 
Operationally we urgently need a functional AS path filtering policy 
mechanism because the tools we have at the moment don't work properly, 
which is one of the reasons that we're continually seeing inadvertent 
routing leaks on the internet. For the few organisations who do 
non-trivial as-path filtering, we're still stuck in the dark ages of 
configuration blobs pulled from IRR databases and local sources, and 
this mechanism doesn't work for most organisations due to implementation 
complexity, reliability and overhead.

The second problem relates to RPKI Repository cache synchronisation. In 
the real world, we are continually seeing both RIR and NIR (national 
internet registry) RPKI Repositories going off-line. To clarify, entire 
regional chunks of the RPKI routinely become unavailable. Operationally, 
this isn't ok.

This is understood to be largely a consequence of the inefficiency of 
rsync and rrdp causing the repositories to become overloaded with cache 
sync requests and falling over due to resource exhaustion. This is 
directly impacting both the perceived and operational reliability of the 
RPKI. Operationally, we need a cache synchronisation protocol which is 
significantly more efficient than either rsync or rrdp. If the 
preliminary figures about its efficiency are in any way accurate, the 
Erik protocol shows significant algorithmic performance gain over both 
rsync and rrdp.

The third problem relates to protocol specification maturity. RPKI 
affects real world routing decisions right at the bottom of the global 
routing stack. It's been a nuisance that this has caused problems for 
the sidrops wg at the IETF, but more importantly we've run into problems 
in the real world due to specification problems in rfc8210. We're too 
far down the routing stack to have the luxury of shipping RFCs which 
risk having interoperability problems. This ask has been requested 
repeatedly over the last couple of years.

Can we please prioritise modification of the WG charter to include 
protocol development, or implement an appropriate alternative, e.g. a 
new WG aimed at protocol maintenance / development ("sidrmaint"?), so that:

1. rfc8210bis, aspa-profile and aspa-verification can be wglc'd, 
including a mandate for interoperability reports
2. rpki-erik-protocol can be adopted so that we can work on fixes for 
the current operational problems affecting the major RPKI Repositories.

Nick