>I'm pretty sure the captured proceedings for "Discussion of Key Rollover >Mechanisms for >Replay-Attack Protection" [!=beacon?] mentions "beacon" at least eleven times.
And hence the confusion. Sriram's presentation was about strategies of doing key rollover, not a protocol feature. >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. One of the strategies Sriram mentioned involved key rollover at regular intervals. The other strategies do not change keys regularly. The new attribute does not have a required refresh function. It uses crypto and any use of crypto requires the ability to change keys. The strategy for changing the crypto keys is an individual decision of the ISPs, not a protocol feature. ISPs may decide to change keys at regular periods, or they may not. (And reports of current ISP behavior wrt TCP MD5 keys seems to be that they currently decide never to change keys at all, ironically.) No one knows what ISPs will decide, so it is incorrect to describe the system effects of this one strategy out of many key rollover strategies as a feature of the protocol. >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. Periodic updates are not introduced in this wg. Periodic updates are not a feature of the protocol. Periodic updates could arise only if everyone chose the regular interval key rollover strategy. There is nothing in this sidr work that forces that choice. The strategy for changing keys is a function of the *individual* *independent* decisions by the ISPs. Perhaps you would prefer it if the ops document discouraged the ISPs from choosing that particular key rollover strategy. --Sandy, speaking as co-chair ________________________________________ From: Danny McPherson [da...@tcb.net] Sent: Friday, December 07, 2012 6:24 PM To: Murphy, Sandra Cc: sidr@ietf.org Subject: Re: [sidr] about "beaconing" and the bgspec-protoocol 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 sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
