Sorry, where did the 2% load come from? Does that mean that every prefix in the Internet is already being advertised 50 times every day? Then, one more advertisement per day would make it 2% extra load.
Also, note that a beacon every day means a timeout of 3 days. Previous suggestions were a timeout of ~24 hours and a beacon of ~8 hours. An alternative to beaconing is a push model instead of pull. That is, every router registers it's interest with the repository instead of querying it periodically. Then the repository would tell all registered parties when a change occurred rather than waiting for them to ask. -- Jakob Heitz. On Aug 10, 2011, at 6:35 AM, "Montgomery, Douglas" <[email protected]> wrote: > > On 8/9/11 9:42 PM, "George Michaelson" <[email protected]> wrote: > >> >> On 10/08/2011, at 11:34 AM, Danny McPherson wrote: >> >>> >>> On Aug 9, 2011, at 9:23 PM, George Michaelson wrote: >>> >>>> >>>> You seemed to be saying "some people are saying beacons wont work" >>> >>> No, that's precisely why I referenced Randy's presentation, if you >>> didn't see it you should have a look at the proceedings... >>> >> >> Will look >> >>>> when you said: "I think Randy successfully convinced me during his >>>> talk at the Quebec City WG session that "beacons" at a frequency of 24 >>>> hours (or anything in the "hours" range) are pretty much useless and >>>> add considerable churn and complexity with little return from a >>>> practical attack surface perspective. " >>>> >>>> So, I am asking, are we removing support for beacons in BGPSEC because >>>> we don't understand their impact on BGPSEC and they add complexity >>>> which makes BGPSEC harder to push uphill. >>> >>> I was contemplating the ROI for a newly designed protocol (bgpsec) and >>> why they were put there in the first place (replay attacks [and more >>> frequent wedgie oscillation :)]) and considering attack surface and >>> practical implications, realizing that from an engineering tradeoff >>> perspective they're quite likely not worth the effort. Hence my broken >>> attempt at a corollary with phishing site lifetime and RIPv1 scaling >>> properties, because I don't have quantitative empirical data handy of >>> routing hijack duration, nor could I possibly predict what it might >>> entail in a bgpsec-enabled world, but I do suspect 24 hours is, umm... >>> quite a while. >> >> Popup announcements for spamming might well lie under 24h lifetime. I >> think some people have notes on that. You can inject a humongous amount >> of store-and-forward from far far less than 24h of routing. > > I think it important to remember that BGPSEC and Origin Validation are > basically preventative, not reactionary/response mechanisms. That is > infrastructure that is manipulated in human time scales (e.g., ROAs, > AS/router Certs) that prevent future false announcements. I think it is > the assumption that having ROAs in place will address most pop-up spam > false announcements. > > The issue of expire time and beacons - and reducing the vulnerability > window of "stale" BGPSEC signed announcements - is a bit more of a > reactionary measure. The idea of expire time exists to address an BGPSEC > signed update that *was a valid signed path* at one time but is no longer. > Given the assumption that the RPKI is a fairly stable and slowly > reacting infrastructure (and one that requires administrative actions to > change) it was seemed better to just bound the useful lifetime of a > BGPSSEC signed update, than to propose to churn the RPKI to invalidate > previously valid paths. > > At the 24hour + range, our estimates are that it adds 1-2% load of > announcements. > > Dougm >> > > _______________________________________________ > sidr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/sidr _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
