> From: sidr-boun...@ietf.org [mailto:sidr-boun...@ietf.org] On Behalf Of > Christopher Morrow > Sent: Wednesday, April 11, 2012 12:29 PM > To: Jakob Heitz > Cc: i...@ietf.org List; sidr@ietf.org > Subject: Re: [sidr] iBGP, BGPSEC and incremental deployment (was No BGPSEC > intradomain ?) > > On Wed, Apr 11, 2012 at 12:17 PM, Jakob Heitz <jakob.he...@ericsson.com> > wrote: > > Confeds are out of scope. > > how are confeds out of scope? > if you want path validation for ibgp/originated-by-you routes and the > originating router is in one of the confed sub-ases you have that > router sign with the confed-external/public asn, no? I'm fairly > certain we planned to support this sort of activity... though I could > be missing the part which is out-of-scope? >
[WEG] There was discussion on the SIDR list on November 12 (subject line "various") specifically regarding private ASNs and confeds and their discussion in the bgpsec-ops draft. I am writing offline and therefore can't provide a more specific pointer to the message itself nor confirm (as memory of the more previous versions that I've reviewed fails) that the product of that discussion has made it to an updated version, but I'm pretty sure that it has. I'd encourage you to look back at this and see if you have additional feedback regarding in/out of scope and implementation. FWIW, confeds being truly out of scope may make BGPSec a no-op in my network, as I can't guarantee that confeds will be gone (unless you are suggesting that they should be deprecated a la AS_SETs). My earlier recommendation is that we have to be specific about how BGPSec handles signing and stripping to manage an ASPath including confeds, whether it only signs at the external side and previous signatures (if exist) are dropped, or if it is capable of handling something like this: Origin ASN (public) -> Transit ASN1 (public) -> [confed ASN(s) (private)] -> confed ASN42 (public) -> confed ASN55 -- in that example, if the entire path is BGPSec capable, what does ASN42 send as the signed path? You have several ASNs that maybe need path count 0 in their signature so that they are signed but don't interfere with the externally-visible path, or the Transit ASN1 has to forward sign its updates as if they are directly connected to confed ASN42 (public), meaning that we are potentially allowing it to transit multiple ASNs within the confed unsigned. Randy had said previously that confed ASNs shouldn't sign towards each other, so maybe that answers that question, but since it has come back up, please give it some thought. Thanks Wes George 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 sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
