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
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
