>> 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 >> 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?
no. and it does not in any way say that, does it? > (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. 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 :) > 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. > 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. why is it needed to cross over into the large space of what is to be signed? the point of the bullet is what is NOT to be signed. > 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. randy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
