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
