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