On Mar 14, 2012, at 9:24 PM, Murphy, Sandra wrote: > 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.
This presumes the protections are to be incorporated into the control plane. I don't know that everyone feels that way, which is why I suggested my second comment. > > 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. So, now maybe I'm confused... Is BGPSEC not adding a new feature, or is it a bad way to do design? > > 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. By adding information to BGP updates. Again, this thread started with a statement to (as you corrected): idr. I think the wording needs work... > > Wrt the interim meeting. The minutes and jabber logs are available. > Commenting on the list is always possible. I did not invalidate your summary of the minutes. I simply clarified that those at the interim meeting do not (in this case) speak for all of us, and it's not clear how many of us agree. Why is that not fair? > > 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? Nope, I think it's great, but lets not conflate issues and use vagaries where we can be specific. ;) Eric > > --Sandy > > ________________________________________ > From: Eric Osterweil [[email protected]] > Sent: Wednesday, March 14, 2012 2:38 PM > To: George, Wes > Cc: Murphy, Sandra; [email protected] > 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: [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
