alvaro, > In thinking about this point some more…what about > draft-ietf-sidr-slurm? Isn’t that supposed to address the private > space? > > 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.
if a private-as router in confederation C signs from that as, others in the confed C may (or may not) have the slurmy data. but assuredly, when that route finally makes its way out to the global internet, there will be a signature in the path which no one can validate. randy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
