On Dec 7, 2012, at 2:38 PM, Murphy, Sandra wrote: > From comments made at the mike in the last IETG sidr session after the > discussion of key rollover techniques, I think there might be a bit of > confusion about beaconing. > > An Expire Time was a feature of the bgpsec protocol in versions 00-01. The > purpose of the Expire Time was to prevent replay and ensure freshness. The > effect of this feature was to require periodic readvertisements of all > prefixes, hence the name "beaconing". > > Based on wg discussions, "beaconing" was removed from the bgpsec protocol in > versions 02 (Mar 12) forward. > > Protection against human time scale replay, e.g., from neighbor relationships > that change, was suggested to be possible through the use of key rollover.
I'm pretty sure the captured proceedings for "Discussion of Key Rollover Mechanisms for Replay-Attack Protection" [!=beacon?] mentions "beacon" at least eleven times. Additionally, "BGPSEC router key rollover" was about periodic updates (aka "beacons") as well. Folks can name them periodic updates, or beacons, or even stretch and call them triggered updates if you want. Adding new attributes to standards-track BGP that require a "refresh" function through *some* new attribute by the origin AND independently by each transit AS (and perhaps each BGPSEC-enabled BGP router therein) under the auspices of "key rollover" rather than "freshness" is, well, still pretty much the same thing functionally - they're still periodic updates in a soft state protocol that don't exist in BGP today. I still contend that doing anything to introduce periodic updates in the global inter-domain routing system is a terrible idea and is something we should avoid altogether. Even [ripv1-rfc1058] provides some hints as to why this is a bad idea. I know we're focusing on hyper-deduced stuff here, but the combinatorial effects of orders of magnitude larger updates in BGP through BGPSEC proposals, breaking and effectively disabling the ability for BGP update packing anywhere, considerable added churn through origination and transit node-triggered "beacons", and added processing overhead for cryptographic functions for signing and validation, all in today's BGP, sure makes me real concern about our goals and if the reward outweighs the risk here. I highly recommend that these documents be experimental and people playing with this stuff in BGP do so in closed environments, not on routers attached to the global routing system; it's fragile enough as is. -danny [!=beacon?] http://www.ietf.org/proceedings/85/slides/slides-85-sidr-4.pdf [ripv1-1058] http://tools.ietf.org/html/rfc1058 _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
