Randy: Hi!
In thinking about this point some more…what about draft-ietf-sidr-slurm? Isn’t that supposed to address the private space? Thanks! Alvaro. On 12/2/16, 12:56 PM, "Randy Bush" <ra...@psg.com<mailto:ra...@psg.com>> wrote: 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.
_______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
