Re: [sidr] RPKI <-> allocation consistency

Brian Dickson <brian.peter.dickson@gmail.com> Fri, 31 August 2012 12:34 UTC

Return-Path: <brian.peter.dickson@gmail.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 4F7D921F8602 for <sidr@ietfa.amsl.com>; Fri, 31 Aug 2012 05:34:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.348
X-Spam-Level:
X-Spam-Status: No, score=-3.348 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 nTTTXMIxvm0K for <sidr@ietfa.amsl.com>; Fri, 31 Aug 2012 05:34:40 -0700 (PDT)
Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 786C421F85C7 for <sidr@ietf.org>; Fri, 31 Aug 2012 05:34:40 -0700 (PDT)
Received: by weyu54 with SMTP id u54so1755413wey.31 for <sidr@ietf.org>; Fri, 31 Aug 2012 05:34:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=n6dZpkPlAJjfi7aXkyj3prYeWfcFhDdZP37TV/szFrE=; b=JXzz2lJZ0JNXIGlgRkRSsKCOE6Y3Ipf+VKubLabrn5sGAmQVHxhoANgzNGyv7NEEkh KSa6sDPGL3z+xebBB+FchJt8IKyjNHxFG8gXQqlFSie2MWBmqqdq3ey+Z1kKte6MONu+ zw5E92BTnJj1NS1+DmfUIRWDYQc4TyqKc9/qOq/DcVDXqKDTPHBqVIDNeC1HnUSIGTn0 t2b+Qd7yzvFDvl4t9lxgfeDyBQSJl4O3/OJs+wVKHw1Q08zpUmIkXuAfaq1XOfpusmzo 1rJ1ijGnP24M76zDY8pZkt5jE331sDOzNyNBfH++1FrK3z73z/zC8ODeMDCwO2+1r4/p UxTQ==
MIME-Version: 1.0
Received: by 10.180.86.3 with SMTP id l3mr4383770wiz.16.1346416479335; Fri, 31 Aug 2012 05:34:39 -0700 (PDT)
Received: by 10.223.61.12 with HTTP; Fri, 31 Aug 2012 05:34:39 -0700 (PDT)
In-Reply-To: <CAL9jLaY3JLBf7H5H2zWvxv2T=9ZsSQbOAxM+mTixefZkF8oVFw@mail.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>
Date: Fri, 31 Aug 2012 08:34:39 -0400
Message-ID: <CAH1iCiqScOwzcAWEuFfHKH4kP6gj45fKqs6rdPq97PsYO+uEMQ@mail.gmail.com>
From: Brian Dickson <brian.peter.dickson@gmail.com>
To: Christopher Morrow <morrowc.lists@gmail.com>
Content-Type: multipart/alternative; boundary="f46d044303faf8768504c88f0380"
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: Fri, 31 Aug 2012 12:34:41 -0000

On Thu, Aug 30, 2012 at 3:23 PM, Christopher Morrow <morrowc.lists@gmail.com
> wrote:

> On Thu, Aug 30, 2012 at 2:30 PM, Brian Dickson
> <brian.peter.dickson@gmail.com> wrote:
> > (2) If INRs are meant to be exclusive, why does the RPKI not enforce that
> > exclusivity?
>
> more than one origin ASN may be valid for a single prefix?
>

In the same paragraph you snip-quoted, was the following:
(Note here - the presumption is not uniqueness by ASN, but uniqueness by
organization controlling ROA assignment, where that single org could/would
issue ROAs for multiple ASNs.)

Same org == same CA.

So, does it not make sense that the RPKI, meaning its design, architecture,
procedures, etc., should actually enforce exclulsivity?

This is pretty fundamental to the number resource tree, and to routing
validation.

If this is a design flaw in the RPKI, I think it is one that needs to be
addressed.

Since origin validation is dependent on the RPKI and its validation rules,
it's kind of "square one" for all things SIDR.

Brian