> From: Randy Bush [mailto:[email protected]] > > the statement attempts to very clearly apply ONLY to two members of the > confed speaking to each other, period. if it is not clearly restricted > to that case, please say how it could be reworded to more clearly be so > restricted. > > ( i should be able to differentiate you and shane. he sends text :)
[WEG] ouch. Cut a mental midget some slack as he attempts to understand well enough to know if he needs to propose new text. :-) That's very clear by itself. What was (and is) less clear is how that interacts with the rest of the network. More on that below. > > > Or do you mean that confed AS1 will not be in the signature chain/AS > > path and the public ASBR (the external side of the confed) will sign > > as if it learned the routes directly from the Origin ASN? > > if bt AS1 you mean what you call "AS ($private)" above, yes, that is > what is meant. [WEG] ok, given that, I can suggest text to add to what you've already proposed - "However, signed updates received from BGPSec speakers outside of the confederation (i.e. those transiting the confederation ASes) MUST be passed to the other Member-ASes BGPSec speakers intact. This will allow those speakers to sign updates to their eBGP peers using the confederation identifier ASN and give a complete chain of signatures as if the confederation were a single ASN." > > Related: It may be that we have to simply say that Private ASNs can't > > be BGPSec participants > > tell that to someone trying to secure some multi-as private network > using rfc 1918 addresses and asns. [WEG] you know I debated making a clarifying exception to the above case when I wrote this mail, but I figured it'd be clear from the above discussion that I was talking about the application where the routes need to be announced into the DFZ, not the case of using your own TA/private space to secure a completely private network with this machinery. If you're using Private ASNs either as origin or as transit for something that has to be announced to the rest of the world, today you can do things like replace-AS, remove-private-as, or you can re-originate it from a public ASN (network statements, etc). In this context, Re-origination should work, but I'm thinking that replace-AS/remove-private will not, unless you also strip the signatures for everything behind the ASN you're replacing, and only sign from that point outward. In other words, you can break the chain of signatures and start a new one, but you can't "fix" the existing signatures. Perhaps that's obvious to everyone involved in the implementation, but it was not obvious to me until I thought through it. Text might take the form of: "If a BGPSec speaker receives updates from another BGPSec speaker with a Private ASN in the path, and is configured to strip those private ASN(s) from updates to its eBGP peers, it MUST also strip any BGPSec signatures contained in that update before signing the update and announcing it to its eBGP peers, even if the eBGP peer is a BGPSec speaker. This is to prevent exposing internal ASNs outside of the network where they are being used." 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 [email protected] https://www.ietf.org/mailman/listinfo/sidr
