On 5/2/16, 1:04 PM, "Kathleen Moriarty" <[email protected]> wrote:
> >---------------------------------------------------------------------- >DISCUSS: >---------------------------------------------------------------------- > >1. Why is this document preceding the BGP spec? Shouldn't this be part >of the BGPSec protocol document? If BGPSec isn't getting deployed >because of the AS path migration problem and this gets us a little >further, but not quite as secure, maybe that's a trade off we need to >accept. But this document coming through first is a little concerning >even though the protocol spec is a normative reference. WG] This is largely a timing problem. The protocol draft was written first, but after this issue was identified, AS-migration was written, and both drafts were revised and reviewed in parallel. The WG discussed integrating AS-migration into the protocol spec, and decided to keep it separate. At the time, this was due to several dependencies and assumptions: First, the WG consensus between SIDR, GROW, and RTGWG was that BGPSec definitely needed to allow for AS-Migration, but before BGPSec could be expected to support AS-Migration, those tools needed to be documented as a formal part of the BGP protocol (in RTGWG), rather than just being de facto standard on account of their being implemented by all major router vendors and widely used by ISPs. That resulted in RFC 7705 (aka idr-as-migration), also written largely in parallel with sidr-as-migration (in fact they started as one document and were split). Second, the BGPSec protocol document was thought to be much closer to completion and publishing than either of these documents, and was expected to be completed well prior to sidr-as-migration such that it didn't make much sense to delay the protocol doc to integrate them. In the meantime, the protocol document underwent additional reviews that uncovered issues requiring more significant revision and delayed its progress such that the as-migration document is now ready first. The protocol document has had edits to ensure proper integration between the two documents where appropriate (adding clarity via references and language to ensure no conflict in what is being directed in each standard). Last, part of the rationale for keeping them separate is that while the WG strongly recommends that both parts be implemented, BGPSec does not strictly require the additional support for AS-migration (I.e. Implementing the functionality defined in BGPSec protocol document is a MUST, AS-migration is a SHOULD), and thus having the documents be separate makes a clear distinction between basic protocol function and add-on features. > > >2. The introduction makes this sound rather innocuous, but the security >considerations section is more explicit that this is a work around BGPSec >and isn't quite as secure. I'd like to see some text explaining this >better in the introduction, more similar to what's in the first paragraph >of the security considerations section. WG] The intent was not to imply that BGPSec with AS-Migration support is fundamentally less secure than BGPSec without it, so if that's what we're conveying between the two sections, I'd appreciate additional guidance on what specifically is giving you that impression. It's not really a work-around BGPSec as much as it's observing that the BGPSec protocol as written would break this common method for AS-Migration, and this document addresses that gap by ensuring that it can be done within the security framework provided by BGPSec. Thanks, Wes George Anything below this line has been added by my company’s mail server, I have no control over it. ----------- ________________________________ 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
