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: [email protected] [mailto:[email protected]] On Behalf Of
>> Murphy, Sandra
>> Sent: Tuesday, March 13, 2012 10:23 AM
>> To: [email protected]
>> 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
>> [email protected]
>> 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
> [email protected]
> https://www.ietf.org/mailman/listinfo/sidr
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
