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
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
