Re: [Sidrops] I-D Action: draft-ietf-sidrops-prefer-rrdp-00.txt

[Tim Bruijnzeels <[e-mail]>]

Hi,

> On 27 Mar 2021, at 04:16, Randy Bush <[e-mail]> wrote:
> 
>> Is the below the short summary people agree to?
>> 
>> 	- Try RRDP first
>> 	- Immediately fall back to RSYNC if RRDP didn't work
>> 	- Don't contact RRDP URIs more than once every 10 minutes
>> 	- Don't contact RSYNC URIs more than once every 30 minutes
>> 	- Don't contact RRDP or RSYNC URIs less than once ever 60 minutes
> 
> i certainly do not agree to that last line, and doubt you do
> 
> as far as the other numbers, see draft-ietf-sidrops-rpki-rov-timing for
> my current opinion.  but i am willing to listen.

@Job, can you elaborate why you believe that RRDP should not be contacted more frequently than once every 10 minutes?

The idea behind allowing more frequent checking IFF 'if-modified-since' is used (and quite possibly other relevant headers), is that: A) CDNs would not even blink, B) you have a chance of getting updates out more quickly - e.g. you issued a wrong ROA and want to correct it.

Are you worried about stampeding RPs in case they all check this frequently and then fall back together? I.e. there would be less of a spread? Because if this is the main reason, then I would argue that the fix would be to fall back more carefully, rather than tell people not to check RRDP as often.

Ultimately the timing between the RPs and the repositories are only one step in the chain. To get your updates from your intended changing of BGP to other validating routers at least the following steps are involved.
1- Let your RPKI CA update ROAs
2- Let your RPKI CA publish
3- Wait for RPs to synchronise RRDP/rsync
4- Have other routers pick up the changes RTR or other

Ideally I think you would want the whole chain of 1-4 to typically take an amount of time that is comparable to / acceptable wrt BGP convergence. The numbers above talk about step 3 in this chain. I think it's hard to say how much it can or should be optimized - also considering that the other steps take time. My gut feeling says that the 2 minute range for checking - when everything works - is about right. Don't get me wrong, I am not fundamentally opposed to 10 minutes, but I want to understand the reason.

As an aside:
Ultimately, as others have pointed out before me, the only real way to be sure that routers have all the information they need, when they need it would be to look into shipping relevant information in BGP itself. This deals with timing issues, and is much safer with regards to repo availability - the info is in the mesh and decentralized. Obviously this is not feasible in the short term as it's a great deal of work. We would need to define validation for relevant info possibly TLS like with relevant info, perhaps think RTR like integration so that BGP speakers can offload signing to a local signer, as well as validation (perhaps let them use both central repos for bootstrapping as well as updated info in BGP).. many, many discussion I am sure. Still, I think this would be a good path to consider long-term.

Back to now though.. and the more practical question: why 10 minutes?

Regards,

Tim