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

"Murphy, Sandra" <Sandra.Murphy@sparta.com> Fri, 10 August 2012 21:38 UTC

Return-Path: <Sandra.Murphy@sparta.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 1CBED21F8666 for <sidr@ietfa.amsl.com>; Fri, 10 Aug 2012 14:38:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.543
X-Spam-Level:
X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, 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 LRopoonDAHGf for <sidr@ietfa.amsl.com>; Fri, 10 Aug 2012 14:38:21 -0700 (PDT)
Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 6A6B021F8652 for <sidr@ietf.org>; Fri, 10 Aug 2012 14:38:21 -0700 (PDT)
Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q7ALcCs9003194; Fri, 10 Aug 2012 16:38:12 -0500
Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q7ALcCXE009790; Fri, 10 Aug 2012 16:38:12 -0500
Received: from HERMES.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5]) by Hermes.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5%21]) with mapi id 14.01.0355.002; Fri, 10 Aug 2012 17:38:11 -0400
From: "Murphy, Sandra" <Sandra.Murphy@sparta.com>
To: Byron Ellacott <bje@apnic.net>, "Montgomery, Douglas" <dougm@nist.gov>
Thread-Topic: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting
Thread-Index: AQHNcmzBDgLmICzaeEOZLRGrqn0RiJdN2OWAgAJwHwCAAZHEAIAAPBsAgACqxoCAAAdMAIAABGUAgADEjbQ=
Date: Fri, 10 Aug 2012 21:38:10 +0000
Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F625F5575F@Hermes.columbia.ads.sparta.com>
References: <CC4A0AFF.C3E96%dougm@nist.gov>, <A32F5174-A4C6-4A7B-A8F4-66575C7082EF@apnic.net>
In-Reply-To: <A32F5174-A4C6-4A7B-A8F4-66575C7082EF@apnic.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [157.185.63.137]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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 21:38:22 -0000

speaking as regular ol' member:

wrt:
------
(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 :-)
------

The CA certs assert the right to use resources.  The ROAs assert authorization to originate routes.  That's different.

There can be multiple ROAs for the same address space, so people can be multi-homed.  (This could maybe also be useful in AS migration cases.)

I believe Doug Montgomery is right.  By the algorithm for validating BGP routes, issuing one ROA does not "trump" other existing ROAs, and thereby make previously valid routes look invalid.

--Sandy, speaking as regular ol' member

________________________________________
From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Byron Ellacott [bje@apnic.net]
Sent: Friday, August 10, 2012 1:18 AM
To: Montgomery, Douglas
Cc: sidr wg
Subject: Re: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting

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