> From: Randy Bush [mailto:ra...@psg.com] > Sent: Friday, November 11, 2011 10:41 PM > To: George, Wes > Cc: sidr wg list > Subject: various > > draft-ietf-sidr-bgpsec-ops-02 > > To prevent exposure of the internals of BGP Confederations > [RFC5065], > a BGPsec speaker which is a Member-AS of a Confederation MUST NOT > not > sign updates sent to another Member-AS of the same Confederation. >
[WEG] does that mean that routes using confeds as transit ASes cannot participate in BGPSec at all? (eg if the update path goes: Origin ASN -> confed AS ($private) -> confed AS ($public) -> eBGP peer) If that's the case, would be useful to be more explicit about it. 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 it's the latter, you probably need more clarifying text, and that may actually require some text in the protocol definition to cover the special-case handling. Related: It may be that we have to simply say that Private ASNs can't be BGPSec participants, whether in confeds or otherwise, for many of the same reasons - AFAICT it'd be impossible to build a signature path and then update it downstream to reflect the external AS it gets replaced with. > draft-ietf-sidr-pfx-validate-04 > > An implementation MUST support 4 Octet AS Numbers, [RFC4893]. > > as our friendly blood-sucking vendors have said, the latter is thought > to be obvious. but i figured to document it anyway, no harm. > > cool? [WEG] works for me! Wes 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
