[rpd] New policy proposals and updated ones - RPKI-ROAs

[Nishal Goburdhan]

On 4 Jan 2020, at 12:05, Daniel Yakmut via RPD wrote:


> The current state of RPKI infrastructure, does not provide a 

> sufficient period between revocation of ROA and notification that a 

> given prefix has been allocated to an organization, which can impact 

> considerably on allocations.


if you’re going to make broad statements like this, you’d better 
have evidence to support it.  so, can you point to a study, or 
documented operational experience that corroborates what you’ve just 
written?

having actually done my fair share of mucking around with rpki, i would 
say that what you wrote, has not been *my* experience.  by that i mean 
that there’s been no appreciable delay that i’ve noticed with 
revocations that’s i’ve done, in a manner similar to what i expect 
afrinic would need to do.  but, ymmv.

(for the record, even though i don’t believe this to be a problem, i 
would still like to have seen that done as part of the impact 
assessment, but, let’s move than along .. )



> Except we can be able to provide a sufficient period or create a 

> different procedure, the proposal for the RPKI-ROAs does not fly.


why?  perhaps, you are of the mistaken belief that, being given a prefix 
by afrinic means that you can use this prefix on the internet 
*immediately*?  in fact, up until when the netop decides to get their 
initial route object into an IRR (which, btw, you can *not* do *before* 
you get the magic allocation email from afrinic..) you should almost 
expect that you can *NOT* get the prefix routed via any self-respecting 
transit, or IXP operator;  most of whom, only update filters once a day.

given that sensible network operators run multiple validators, that 
upgrade considerably faster (!) than IRR filters (and here, we are 
talking about minutes vs. a once a day update) i don’t see the problem 
you’re alluding to.  in my relatively simple view of the world, the 
process is something like:
t=0;  afrinic does internal approval of requested space after their due 
diligence process
t=1;  afrinic revokes the ROA covering this space (can be automated)
t=2;  afrinic issues a new ROA (or set of ROAs) covering the master 
prefix space, but without this prefix (can be automated)
t=3;  (well, not quite;  it’s more like t=+15min..)  afrinic confirms 
revocation from an external source and that rpki_state=not_found (can be 
automated)
t=4;  afrinic sends you the magic e mail to say that your netblock has 
been allocated

i think you’re getting confused at the t=3 marker;  because there is 
*always* the risk that someone’s validator cache broke.  that risk 
still exists today, just in a different form  (ie. a broken IRR filter, 
or any one of ten other things that could break).  if anything, this is 
actually an improvement given how quickly most validators update, vs. 
IRR filters.

(before you nitpick this, that’s not a complete process;  just an 
indication of the significant bits..)

whilst i don’t particularly care for this policy, i *do* care that 
what’s been used to assess it’s viability (use of rpki) is correct;  
and, in at least two cases, i’ve seen comments which appear to be 
“against” the policy make assumptions and expectations, and allude 
to operations of the rpki that are simply incorrect.

unless, of course, you have data to show otherwise.

—n.