[sidr] about grandparenting

"Murphy, Sandra" <Sandra.Murphy@sparta.com> Fri, 10 August 2012 20:45 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 969C721F861D for <sidr@ietfa.amsl.com>; Fri, 10 Aug 2012 13:45:45 -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 8FtvYcDppFwX for <sidr@ietfa.amsl.com>; Fri, 10 Aug 2012 13:45:45 -0700 (PDT)
Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 0C21321F861B for <sidr@ietf.org>; Fri, 10 Aug 2012 13:45:44 -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 q7AKjiQA002898 for <sidr@ietf.org>; Fri, 10 Aug 2012 15:45:44 -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 q7AKjiIJ008798 for <sidr@ietf.org>; Fri, 10 Aug 2012 15:45:44 -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 16:45:43 -0400
From: "Murphy, Sandra" <Sandra.Murphy@sparta.com>
To: "sidr@ietf.org" <sidr@ietf.org>
Thread-Topic: about grandparenting
Thread-Index: AQHNdzkcHOX63dulWkagCqlNnf/eOQ==
Date: Fri, 10 Aug 2012 20:45:43 +0000
Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F625F5556C@Hermes.columbia.ads.sparta.com>
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
Subject: [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: Fri, 10 Aug 2012 20:45:45 -0000

speaking as regular ol' member

This is a discussion of grandparenting, NOT a discussion of adoption of the grandparenting draft.

There have been suggestions of several different actions a grandparent might do.  Most of the comments so far focus on issuance of CA certificates to a grandchild.  But there are other actions a grandparent might take.

For example.  One action already mentioned would be issuing ROAs for the grandchild, by the grandparent.  That doesn't disturb the consistency with the allocation system.  We have long discussed that providers might issue ROAs for RPKI-unprepared children.  The RPKI structure allows for multiple ROAs for the same prefix (for multihoming) and for multiple ROAS for more specifics inside the same space signed by the same entity (eg for TE advertisements).  

For example.  The grandparent could also host a CA service for the child.  That's allowed and is currently practiced.  Under that hosted CA service, the grandparent could issue a cert for the grandchild.  The process controlling this would be a matter for the agreement about the hosting service.

For example.  The grandparent could issue a CA cert for the grandchild and reclaim that address space from the child by issuing new CA certs for the child that omit the reclaimed space.   (For: it keeps allocation and RPKI consistent.  Against: it fractures allocations and can produce routing table bloat.)   I think I saw this in one message on the thread.  How, when, where, why, with what proof or limitations - all that is out-of-band process and can vary per situation.

For example.  The grandparent could issue a ROA that it itself was allowed to originate the grandchild's address space, and forward traffic to the child with the expectation that the child will forward traffic to the grandchild.  (This only works in cases where there is continued connectivity from child to grandchild.)   There's no CA cert action there, so it doesn't disturb the consistency with the allocation system.

I presume there are lots of others.

Do we want to try to record the many possibilities?  A complete list (ulp!)?  Reasons for and against certain critical ones?

--Sandy, speaking only as regular ol' member