Re: [sidr] Origin Ops, TALs and Local TAs

[Stephen Kent <[e-mail]>]

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