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

[Danny McPherson <[e-mail]>]

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