In the interim meeting, the consensus was that we needed idr to be involved in any definition and solution for route leaks. It was decided to discuss a message to the idr wg on the sidr list.
Brian Dickson has submitted drafts about route leaks, as he offered in the meeting. So here is a first draft at a messate to idr. Comments please. ============== The sidr interim meeting in February discussed the problem of route leaks. While those in the room could recognize route leaks in a diagram, they could not determine a way to determine that from information communicated in BGP. Proposals to stop route leaks add information to BGP updates that would be used to restrict the propagation of those updates by the neighbor onward to providers, customers, peers, etc. This is a change to BGP behavior, which now relies on local configuration only to choose a best path and advertise it. Adding features to stop route leaks would restrict that advertisement and restrict what local policy could choose. The consensus in the room was that adding a new feature to a protocol as part of a security protection (i.e., not just ensuring an already defined behavior but producing brand new behavior) is unwise and leads to problems. The sidr working group requests that idr discuss the route leaks problem with sidr and determine the best path forward. The idr wg should also be aware that drafts have been submitted about route leaks, so work is underway. http://tools.ietf.org/html/draft-foo-sidr-simple-leak-attack-bgpsec-no-help-01 http://tools.ietf.org/html/draft-dickson-sidr-route-leak-def-01 http://tools.ietf.org/html/draft-dickson-sidr-route-leak-reqts-02 http://tools.ietf.org/html/draft-dickson-sidr-route-leak-solns-01 =================== --Sandy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
