[sidr] Freshness belt and suspenders ....

[DougM lists <[e-mail]>]

I thought John Scudder's belt and suspenders comment was a good one.   
We have looked at some level of detail at both explicit expire times in 
updates and key roll techniques to manage freshness of BGP updates.   
Neither approach is a silver bullet and both have the potential to swamp 
the system with either updates or updates and RPKI data.

Ideas discussed to date of bounding the potential load imposed by either 
single mechanism are imperfect.   Without bounds, either mechanism could 
be abused at the expense of the entire net.

Sandy has called previously for a discussion of the general requirements 
for "the freshness/replay problem".    Assuming we don't want to leave 
the problem half solved (e.g., deal with withdraw suppression as well as 
explicit replay and peering topology changes), the idea of combining 
mechanisms seems to offer an opportunity.

Combining John and Randy's comments  during the discussion .....

Assume we bound the units of expire time to days (for example, choose 
your acceptable background granularity) past epoc.    Assume we express 
bounds that components MUST support at least two pre-published keys per  
router/AS.

Emergency or topology driven key roll at the router, works at speed of 
BGP convergence.   Day based expire times catch those freshness problems 
that can't be addressed by router key roll.

Some bounds are necessary to prevent / discourage me from pre-publishing 
vast number of router keys signed with very short lived certificates 
..... i.e., I can churn the system just as bad with frequent key rolls 
on routers.

Anyway, combining the two mechanisms would give us a reactive system 
(router key roll) along with a background system that covers the rest of 
the threat space.

I think that was John's point.
dougm