On Nov 16, 2011, at 2:50 AM, Stephen Kent wrote: > >> 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? > > not sure what a federation is, but, yes, an RP can constrain what a TA > is allowed to assert, via a constraints file.
Ahh, this makes good sense. >> 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? > > I don't understand all of the words above. Apologies for the loose terminology here.. Try this.. AS1 --- ISP1 (AS2) --- ISP2 (AS3) --- AS4 In the case of LTA if these four parties wish to transact their constraints files (or shared "non-putative" RPKI TAs) must be familiar and synchronized with each other via some out of band mechanism - i.e., they either have to: 1) synchronize LTA contents across the set 2) share a common non-putative TA that magically does this and in doing so, they likely would want to constrain what a TA is allowed to assert, via a constraints file, as noted above? That is, LTA for the local AS doesn't fix the multi-AS/multi-administrator/RP issue, and so some synchronization or shared non-putative TA needs to be developed in they desire autonomy outside of the putative set. Is that correct? >> 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? > > LTA management allows this, but it becomes very complex to do well if there > are too many data items to manage. Yeah, that's what I'm mulling... Thanks, -danny _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
