Re: [sidr] RPKI <-> allocation consistency
Stephen Kent <kent@bbn.com> Tue, 04 September 2012 17:55 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 6054321F867A for <sidr@ietfa.amsl.com>; Tue, 4 Sep 2012 10:55:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xF-6U3ndWbKZ for <sidr@ietfa.amsl.com>; Tue, 4 Sep 2012 10:55:22 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id DEB7721F8673 for <sidr@ietf.org>; Tue, 4 Sep 2012 10:55:21 -0700 (PDT)
Received: from dhcp89-089-092.bbn.com ([128.89.89.92]:50310) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1T8xLF-000170-7W; Tue, 04 Sep 2012 13:55:13 -0400
Message-ID: <50464081.4020305@bbn.com>
Date: Tue, 04 Sep 2012 13:55:13 -0400
From: Stephen Kent <kent@bbn.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: Brian Dickson <brian.peter.dickson@gmail.com>
References: <24B20D14B2CD29478C8D5D6E9CBB29F625F555CB@Hermes.columbia.ads.sparta.com> <D857A4BB-E484-45A4-A09F-FB8FAF2215AC@tcb.net> <C5B88834-3A10-41F7-A4F3-2B7C9B540197@verisign.com> <50389897.3040503@bbn.com> <97856400-9F70-4AEC-AF91-A0673A6D716D@verisign.com> <503C47A8.7030700@bbn.com> <303C576D-D1F8-4F62-8E0E-0D74A28B2771@verisign.com> <503D141F.1060404@bbn.com> <3A791D9E-4F16-4481-94AE-BD38A5389593@verisign.com> <CAL9jLaaew6HLdHK4=UrsUF2JKsRRV=sbXzCOFiDnLRKtVSK1tw@mail.gmail.com> <CAH1iCirWo+JYOpFjVhtxXYKGB86nLhcogC20bEy0-Ldkp7Oc8A@mail.gmail.com> <CAL9jLaY3JLBf7H5H2zWvxv2T=9ZsSQbOAxM+mTixefZkF8oVFw@mail.gmail.com> <CAH1iCiqScOwzcAWEuFfHKH4kP6gj45fKqs6rdPq97PsYO+uEMQ@mail.gmail.com> <50461289.1040907@bbn.com> <CAH1iCiqR3A2wdCo7Gs1RWmLZnJLUuO8=-WXj9QN-bfxBwnX02Q@mail.gmail.com>
In-Reply-To: <CAH1iCiqR3A2wdCo7Gs1RWmLZnJLUuO8=-WXj9QN-bfxBwnX02Q@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: sidr@ietf.org
Subject: Re: [sidr] RPKI <-> allocation consistency
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, 04 Sep 2012 17:55:22 -0000
Brian, > Sorry, have to call B.S. on this one. unsportsman-like comment, 15 yards and loss of a down. > > Make-before-break is fully possible with exclusivity. In the general case, the resources are transferred between two CAs, and these CAs need not be ISPs, e.g., they might be RIRs. So, before an ISP can issue ROAs for the newly-received INRs, the ISP has to have these INRs added to it's CA cert. If the parent of that CA was not the parent for the ISP that previously held the resources, then it too has to have the INRs in question added to its cert, and so on. Thus means that, in general, there will be more that one CA, at corresponding tiers of the RPKI, that will have the same INRs in their 3779 extensions. Equivalently, this means that some CA will have issued certs to two of its children, where the certs overlap (wrt the INrs being transferred). > Exclusivity enforced at the CA level still allows for multiple ROAs > (and thus multiple announcing AS). Since this is not just a ROA question, I am ignoring the parts of your message that focus on ROAs, or on BGP details that seem to be the result of this (confused) focus. Steve
- [sidr] RPKI <-> allocation consistency Murphy, Sandra
- Re: [sidr] RPKI <-> allocation consistency Danny McPherson
- Re: [sidr] RPKI <-> allocation consistency Eric Osterweil
- Re: [sidr] RPKI <-> allocation consistency Murphy, Sandra
- Re: [sidr] RPKI <-> allocation consistency Eric Osterweil
- Re: [sidr] RPKI <-> allocation consistency Stephen Kent
- Re: [sidr] RPKI <-> allocation consistency Eric Osterweil
- Re: [sidr] RPKI <-> allocation consistency Stephen Kent
- Re: [sidr] RPKI <-> allocation consistency Eric Osterweil
- Re: [sidr] RPKI <-> allocation consistency Brian Dickson
- Re: [sidr] RPKI <-> allocation consistency Stephen Kent
- Re: [sidr] RPKI <-> allocation consistency Stephen Kent
- Re: [sidr] RPKI <-> allocation consistency Christopher Morrow
- Re: [sidr] RPKI <-> allocation consistency Andy Newton
- Re: [sidr] RPKI <-> allocation consistency Christopher Morrow
- Re: [sidr] RPKI <-> allocation consistency Eric Osterweil
- Re: [sidr] RPKI <-> allocation consistency Christopher Morrow
- Re: [sidr] RPKI <-> allocation consistency Brian Dickson
- Re: [sidr] RPKI <-> allocation consistency Brian Dickson
- Re: [sidr] RPKI <-> allocation consistency Christopher Morrow
- Re: [sidr] RPKI <-> allocation consistency Arturo Servin
- Re: [sidr] RPKI <-> allocation consistency Brian Dickson
- Re: [sidr] RPKI <-> allocation consistency Tim Bruijnzeels
- Re: [sidr] RPKI <-> allocation consistency Brian Dickson
- Re: [sidr] RPKI <-> allocation consistency Christopher Morrow
- Re: [sidr] RPKI <-> allocation consistency Stephen Kent
- Re: [sidr] RPKI <-> allocation consistency Stephen Kent
- Re: [sidr] RPKI <-> allocation consistency Brian Dickson
- Re: [sidr] RPKI <-> allocation consistency Stephen Kent
- Re: [sidr] RPKI <-> allocation consistency Brian Dickson
- Re: [sidr] RPKI <-> allocation consistency Stephen Kent
- Re: [sidr] RPKI <-> allocation consistency Robert Loomans
- Re: [sidr] RPKI <-> allocation consistency Brian Dickson
- Re: [sidr] RPKI <-> allocation consistency Stephen Kent
- Re: [sidr] RPKI <-> allocation consistency Brian Dickson
- Re: [sidr] RPKI <-> allocation consistency Brian Dickson
- Re: [sidr] RPKI <-> allocation consistency Brian Dickson