Rob/Steve, et al., Relative to the SIDR Origin Ops draft and local trust anchor (LTA) configuration, I'm trying to understand how one would actualize trust anchor locators (TALs) and LTAs in a deployment scenario and was hoping you could help me here.
I think it's probably safe to assume everyone is going to have a "Constraints" file for some things. Because the TALs don't actually specify the list of resources covered by the referenced self-signed CA certificates the relying party must consult each trust anchor (e.g., RIR) to determine the INR extension(s) within this certificate, and the onus is on the RP to resolve conflicts, is this correct? For example, currently, in the experimental pilot RPKI system many of the INRs are asserting 0.0.0.0/0 and 0::/0, which opens the opportunity for conflicts that must be resolved by the RP, when they likely have no real capability to do this (hence the IAB statement on this topic). Here's my primary question. If I wanted to form a 'federation' of sorts for resiliency would I have to use additional TALs in conjunction with my LTA and paracertificate hierarchy? If so, can an RP include some sort of filter to constrain what a TA can assert as within their resource holdings? That is, because for LTA to work every relying party in the transaction path (i.e., source and destination networks, as well as intermediate RPs) would need to override the putative [global] TA RPKI for every other operators resources and generate a paracertificate hierarchy therein, is that right? And if that's the case, wouldn't it be simpler for RPs to be able to associate resources with each trust anchor rather than trusting them to convey to the RP what resources they are authoritative for? Does this question make sense, or is this problem solved elsewhere? Thanks, -danny _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
