Re: [sidr] Origin Ops, TALs and Local TAs
Stephen Kent <kent@bbn.com> Tue, 29 November 2011 15:31 UTC
Return-Path: <kent@bbn.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B15A11F0C38 for <sidr@ietfa.amsl.com>; Tue, 29 Nov 2011 07:31:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.799
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id irYhEI0pNJUh for <sidr@ietfa.amsl.com>; Tue, 29 Nov 2011 07:31:48 -0800 (PST)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 2A18321F8C3D for <sidr@ietf.org>; Tue, 29 Nov 2011 07:31:48 -0800 (PST)
Received: from dhcp89-089-006.bbn.com ([128.89.89.6]:49162) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1RVPes-000Ixv-6o; Tue, 29 Nov 2011 10:31:46 -0500
Mime-Version: 1.0
Message-Id: <p06240801cafaa8c5e519@[128.89.89.6]>
In-Reply-To: <CAL9jLaZ7ccqD6gkyy1Rd2gdqwf3=C28D77Y1YSb2eMRGn8OGoQ@mail.gmail.com>
References: <80D9C12A-354E-4A90-8E97-946519E499D0@tcb.net> <p06240801cae79ccfa546@172.20.1.65> <72E12AD7-CFAF-4FBD-8A98-F93038F7E8FB@tcb.net> <p06240803caf95d6f5166@128.89.89.6> <CAL9jLaZ7ccqD6gkyy1Rd2gdqwf3=C28D77Y1YSb2eMRGn8OGoQ@mail.gmail.com>
Date: Tue, 29 Nov 2011 10:27:48 -0500
To: Christopher Morrow <morrowc.lists@gmail.com>
From: Stephen Kent <kent@bbn.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Cc: sidr@ietf.org
Subject: Re: [sidr] Origin Ops, TALs and Local TAs
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=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 && >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] Origin Ops, TALs and Local TAs Danny McPherson
- Re: [sidr] Origin Ops, TALs and Local TAs Rob Austein
- Re: [sidr] Origin Ops, TALs and Local TAs Danny McPherson
- Re: [sidr] Origin Ops, TALs and Local TAs Christopher Morrow
- Re: [sidr] Origin Ops, TALs and Local TAs Danny McPherson
- Re: [sidr] Origin Ops, TALs and Local TAs Christopher Morrow
- Re: [sidr] Origin Ops, TALs and Local TAs Stephen Kent
- Re: [sidr] Origin Ops, TALs and Local TAs Danny McPherson
- Re: [sidr] Origin Ops, TALs and Local TAs Stephen Kent
- Re: [sidr] Origin Ops, TALs and Local TAs Christopher Morrow
- Re: [sidr] Origin Ops, TALs and Local TAs Stephen Kent
- Re: [sidr] Origin Ops, TALs and Local TAs Christopher Morrow
- Re: [sidr] Origin Ops, TALs and Local TAs Danny McPherson
- Re: [sidr] Origin Ops, TALs and Local TAs Stephen Kent