[apologies in advance for cross-post] An example of why some of the work in SIDR is making me uneasy, particularly given they're currently aiming for standards track at the moment..
I'll just note that this is *your* BGP system they're talking about.. -danny Begin forwarded message: > From: Danny McPherson <[email protected]> > Subject: Re: [sidr] about "beaconing" and the bgspec-protoocol > Date: December 7, 2012 6:24:00 PM EST > To: "Murphy, Sandra" <[email protected]> > Cc: "[email protected]" <[email protected]> > > > 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 > _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
