Re: [sidr] route leaks message to IDR

["Murphy, Sandra" <[e-mail]>]

I am afraid that you missed the point that I was trying to make.

Adding information is not the problem.

Adding a new *routing feature* is the problem.

BGP presently has no feature that lets the sender restrict where the receiver might propagate a route.    So the security protections would have to invent the feature and secure it at the same time.

The consensus of the meeting was that this is a bad way to do design.  Adding a new feature as part of adding a new security protection has been found to lead to problems.  

Note that the current sidr work does not conflict with this.  The protections we are developing are there to protect features that already exist in the BGP spec, but are vulnerable to misuse.  The protections eliminate "bad" behavior, but they do not produce new routing features.

Wrt the interim meeting.  The minutes and jabber logs are available.  Commenting on the list is always possible.

The drafts were mentioned to show that people are actively beginning to work on this, not as pointers to a candidate.

The message below asks for idr's (not grow's) consideration of how to proceed.  Do you have some objection to idr being part of the definition of a new routing feature?

--Sandy

________________________________________
From: Eric Osterweil [[e-mail]]
Sent: Wednesday, March 14, 2012 2:38 PM
To: George, Wes
Cc: Murphy, Sandra; [e-mail]
Subject: Re: [sidr] route leaks message to IDR

I'd also like to add that (if I'm not mistaken) much of the BGPSEC work is _already_ proposing to "add information to BGP updates."  For example, I'm pretty sure there aren't any signatures in BGP right now, right?  I don't think this text is completely on the level, because my recollection of many of the sidr drafts is that they _ARE_ proposing to add data, semantics, and processes to the current operation of BGP.  By my reading of the text below, it sounds like we would only add these things if we were going to add route leak protection, and that sentiment seems wrong to me.  Moreover, the text below conflates the need for leak protection with some as-yet-unspecified approach that must use inline protocol changes.  I don't know that this has been openly agreed to by all (which is fine at this stage), but in reaching out to grow w/ this as a starting point I think we present both a problem and an unratified straw-man.  I think the text needs to be clarified.

Also, I'd like to request in the 5th para (or the 6th sentence?):
        s/The consensus in the room was/The consensus in the room (though it is not clear what portion of the wg agrees) was/

Thanks,

Eric

On Mar 14, 2012, at 5:49 PM, George, Wes wrote:

> 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.
> _______________________________________________
> sidr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sidr