> M4. Still in Section 7: “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.” This is another case where the BGPSec spec says > something different: Section 4.3. (Processing Instructions for > Confederation Members) presents a mandatory mechanism that includes > signing, but not necessarily validating. BTW, if the updates are not > signed, then the signed path would be broken, even if all the routers > in the path support BGPSec, right? Is that the recommendation? > > it is common for a bgp confederation to include private ASs for which > there can be no unique authorative router credentials in the rpki. > hence i am suspicious of the protocol spec.
i recant. the protocol spec 4.3 says the intra-confed path elements are stripped before exporting outside the confed. To prevent exposure of the internals of BGP Confederations [RFC5065], a BGPsec speaker exporting to a non-member removes all intra- confederation Secure_Path segments. Therefore signing within the confederation will not cause external confusion even if non-unique private ASs are used. randy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
