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

[Stephen Kent <[e-mail]>]

At 7:53 PM -0500 11/28/11, Christopher Morrow wrote:
>...
>
>I think danny's example (as explained off-line in taipei) was something like:
>
>   o 3 cooperating ASNs (say: 701, 7018, 2914)
>   o one customer on either side of the 3 ASNs (a-widget-maker &&
>a-widget-user/customer)
>   o All have RPKI + BGPSEC deployed
>   o the 'blackhelicopters of forgotten payment' arrive at ARIN's
>doorstep and remove the Registration data for a-root/24.
>
>   For a-widget-customer to still access a-widget-maker all of the
>intermediate ASN's (and a-widget-customer even) will have to enter
>into their LTA's some bogus/temporary certificate data... Or, I
>suppose, they could just wing it on 'not validated' but still the only
>prefix-in-town?
>
>I think Danny's proposing some federation of LTAs under distributed
>control where these folks all agree that "a-widget-maker/24 is still
>a-ok by us!".
>
>-chris

OK, that's a very helpful statement of the concern.

If the widget maker had a cert for the /24, the LTA management mechanisms
can allow the co-operating ASes to continue to use it, even after an RIR
removes it. The current spec assumes that the ASes retrieve the old cert
from their local caches to do this. We might explore (standard) ways 
to move certs to deal with the possibility that one or more of the 
ASes in question
does not have the old cert in its cache.

There are controls to allow RPs to ignore the expiration of the certs for
the widget maker, but that's not the best outcome. Ultimately the widget maker
would like to have a new CA cert issued to it, and continue to manage the'
corresponding CRL, manifest, and ROA(s). All of that can be 
accommodated using the LTA mechanisms, but it will become complex if 
there are a lot of exceptions of this sort.

Steve