Re: [sidr] about grandparenting

Andy Newton <andy@arin.net> Tue, 14 August 2012 17:34 UTC

Return-Path: <andy@arin.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 C138B21F8796 for <sidr@ietfa.amsl.com>; Tue, 14 Aug 2012 10:34:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.575
X-Spam-Level:
X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599]
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 6HcR0FyRNtI1 for <sidr@ietfa.amsl.com>; Tue, 14 Aug 2012 10:34:00 -0700 (PDT)
Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id 7BD6A21F8794 for <sidr@ietf.org>; Tue, 14 Aug 2012 10:33:59 -0700 (PDT)
Received: by smtp2.arin.net (Postfix, from userid 323) id 0182C2135AA; Tue, 14 Aug 2012 13:33:59 -0400 (EDT)
Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp2.arin.net (Postfix) with ESMTP id 6C8D0213587; Tue, 14 Aug 2012 13:33:58 -0400 (EDT)
Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.283.3; Tue, 14 Aug 2012 13:33:18 -0400
Received: from CHAXCH01.corp.arin.net ([169.254.1.124]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0298.004; Tue, 14 Aug 2012 13:33:50 -0400
From: Andy Newton <andy@arin.net>
To: "Murphy, Sandra" <Sandra.Murphy@sparta.com>
Thread-Topic: [sidr] about grandparenting
Thread-Index: AQHNdzkcHOX63dulWkagCqlNnf/eOZdZoPcAgAALNYCAAC5fgA==
Date: Tue, 14 Aug 2012 17:33:49 +0000
Message-ID: <D0D7640E-9D11-445F-B532-2D444666A1C1@arin.net>
References: <24B20D14B2CD29478C8D5D6E9CBB29F625F5556C@Hermes.columbia.ads.sparta.com>, <B6BBB3C7-2271-4CA3-9143-DC1719B924BC@arin.net> <24B20D14B2CD29478C8D5D6E9CBB29F625F55FB2@Hermes.columbia.ads.sparta.com>
In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F625F55FB2@Hermes.columbia.ads.sparta.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.1.1.56]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <30F07806A221C64FB319B99BD7898C96@corp.arin.net>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "sidr@ietf.org" <sidr@ietf.org>
Subject: Re: [sidr] about 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: Tue, 14 Aug 2012 17:34:00 -0000

On Aug 14, 2012, at 10:47 AM, Murphy, Sandra wrote:

> speaking as a regular ol' member:
> 
> On Tuesday, August 14, 2012 10:07 AM, Andy Newton [andy@arin.net] said
> 
>> I'm not speaking for anybody but me here, but I would think 
>> that the notion of RIRs issuing "operational" ROAs would be 
>> a BIG layer 9 issue.
> 
> 
> Given all the caveats below.
> 
> If you believe RIRs should not issue ROAs


For clarification, I personally don't have an opinion on this. It is just my observation that there have been concerns about the roles of RIRs in the RPKI, and this would seem to collide with such concerns.

> , what would be your preferred method to deal with that: (a) relying party policy - reject ROAs signed by x,y,z keys, (b) cert policy - some words in the CP (c) operational - registries promise not to implement a feature in their code that would allow this (d) contractual - the registry agreement promises that they will not do this,  (e) technical - some bits in the RPKI objects, etc.

A, B, C, and D are above my pay grade. E, such as a grandchild bit in a ROA or something, is interesting but I doubt would resolve layer 9 concerns.

> 
> (Why did you speak of an "operational" ROA?  What would a non-operational ROA be?)
> 

ROAs that represent real routes, not things like IANA space. If there is a better term, let me know.

-andy