Hi Wes, (FWIW, I agree with Kathleen's DISCUSS on this but one question below before I post my own ballot...)
On 02/05/16 20:31, George, Wes wrote: > > 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. This is only a timing problem if bgpsec doesn't change in some incompatible manner. If such a change happens then this is more than a timing issue. What'd be bad about just holding this in the WG until bgpsec is ready? Since there's a normative reference anyway getting the IESG to approve both at once seems like it'd be better. Cheers, S. > >> >> >> 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. >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
