Danny,
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.
A TAL points to a self-signed RPKI cert, which contains a 3779 extension that
describes all of the address space under that cert. It also has an
SIA extension that points to the repository publication point where
one begins retrieval of other RPKI certs, etc.
I think it's probably safe to assume everyone is going to have a
"Constraints" file for some things.
The local TA mechanism specifies that capability, but we've been told
that most folks will find it too hard to manage that capability
correctly.
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?
the TAL doesn't but the cert to which it points does. If one uses a
TAL for IANA (consistent with the IAB recommendation that you helped
author), then 3779 processing will catch conflicts.
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).
Agreed that an RIR claiming 0/0 is bad. I think this is holdover from
the pre-TAL TA model. Hopefully this will go away.
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.
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.
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.
Steve
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
