Re: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting

Byron Ellacott <bje@apnic.net> Fri, 10 August 2012 05:18 UTC

Return-Path: <bje@apnic.net>
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 292F621F8523 for <sidr@ietfa.amsl.com>; Thu, 9 Aug 2012 22:18:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
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 Z04O01UmXjo9 for <sidr@ietfa.amsl.com>; Thu, 9 Aug 2012 22:18:30 -0700 (PDT)
Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id 2378221F8517 for <sidr@ietf.org>; Thu, 9 Aug 2012 22:18:29 -0700 (PDT)
Received: from [IPv6:2001:dc0:a000:4:c433:b84f:e7bf:7e70] (unknown [IPv6:2001:dc0:a000:4:c433:b84f:e7bf:7e70]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 950CDB686C; Fri, 10 Aug 2012 15:18:28 +1000 (EST)
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: multipart/signed; boundary="Apple-Mail=_9EB1072E-F977-4EB0-8509-E7A08E06A355"; protocol="application/pkcs7-signature"; micalg="sha1"
From: Byron Ellacott <bje@apnic.net>
In-Reply-To: <CC4A0AFF.C3E96%dougm@nist.gov>
Date: Fri, 10 Aug 2012 15:18:28 +1000
Message-Id: <A32F5174-A4C6-4A7B-A8F4-66575C7082EF@apnic.net>
References: <CC4A0AFF.C3E96%dougm@nist.gov>
To: "Montgomery, Douglas" <dougm@nist.gov>
X-Mailer: Apple Mail (2.1278)
Cc: sidr wg <sidr@ietf.org>
Subject: Re: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting
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, 10 Aug 2012 05:18:31 -0000

Hi Doug,

On 10/08/2012, at 3:02 PM, Montgomery, Douglas wrote:

> On 8/10/12 12:36 AM, "Byron Ellacott" <bje@apnic.net> wrote:
> 
>> If C has taken some action, LEA triggered or otherwise, that means the
>> RPKI system no longer asserts that G's intent for packet delivery is
>> true, then merely allowing G to issue an RPKI assertion does not prevent
>> C from asserting whatever they like, too.  If a LEA requires C to issue
>> an AS0 ROA 10.42.2.0/23, then creating an ASn ROA for the same prefix,
>> same maxLength will not ensure packets are delivered correctly.
> 
> The way I understand
> http://tools.ietf.org/html/draft-ietf-sidr-pfx-validate-08, if there is a
> valid ROA that matches a route, and a valid AS0 ROA that also covers the
> route, the route will be considered VALID.
> 
> AS0 ROAs don't "trump" other valid ROAs.

Substitute "ASm" for "AS0" in my example.

I believe you're right about AS 0.  I was taking the first sentence of the Security Considerations of draft-ietf-idr-as0 [1] too literally; AS0 ROAs are not entirely equivalent to BOAs, after all :-)

(But this is sort of my point, the RPKI system's verification of right of use breaks down if you start certifying multiple people as having a simultaneous right to use resources :-)

  Byron

[1] http://tools.ietf.org/html/draft-ietf-idr-as0