Re: [sidr] route leaks message to IDR

["George, Wes" <[e-mail]>]

I'm basically fine with the wording below. The only thing I might add would be some mention of the reason why we're talking about route leaks, why they're considered a problem that should be solved in the context of SIDR, etc - mainly that there are those among the WG and operator community that believe BGPSec as currently proposed is incomplete without a method to prevent route leaks, and given the costs to deploy and manage BGPSec, the inability to protect against this problem limits its attractiveness for deployment.

This is covered in detail in the referenced drafts, but is worth including in the summary text.

Thanks,

Wes


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Murphy, Sandra
> Sent: Tuesday, March 13, 2012 10:23 AM
> To: [e-mail]
> Subject: [sidr] route leaks message to IDR
>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sidr

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.