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

Stephen Kent <> Tue, 29 November 2011 15:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B15A11F0C38 for <>; Tue, 29 Nov 2011 07:31:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -105.799
X-Spam-Status: No, score=-105.799 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id irYhEI0pNJUh for <>; Tue, 29 Nov 2011 07:31:48 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 2A18321F8C3D for <>; Tue, 29 Nov 2011 07:31:48 -0800 (PST)
Received: from ([]:49162) by with esmtp (Exim 4.74 (FreeBSD)) (envelope-from <>) id 1RVPes-000Ixv-6o; Tue, 29 Nov 2011 10:31:46 -0500
Mime-Version: 1.0
Message-Id: <p06240801cafaa8c5e519@[]>
In-Reply-To: <>
References: <> <p06240801cae79ccfa546@> <> <p06240803caf95d6f5166@> <>
Date: Tue, 29 Nov 2011 10:27:48 -0500
To: Christopher Morrow <>
From: Stephen Kent <>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Subject: Re: [sidr] Origin Ops, TALs and Local TAs
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 29 Nov 2011 15:31:48 -0000

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 &&
>   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
>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!".

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.