Re: [sidr] draft-ymbk-rpki-grandparenting-00.txt

Randy Bush <randy@psg.com> Fri, 29 June 2012 18:44 UTC

Return-Path: <randy@psg.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 C525421F884E for <sidr@ietfa.amsl.com>; Fri, 29 Jun 2012 11:44:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.584
X-Spam-Level:
X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 RrblSeByEc3o for <sidr@ietfa.amsl.com>; Fri, 29 Jun 2012 11:44:26 -0700 (PDT)
Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 21D1521F884D for <sidr@ietf.org>; Fri, 29 Jun 2012 11:44:25 -0700 (PDT)
Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <randy@psg.com>) id 1SkgB6-000DN8-3o; Fri, 29 Jun 2012 18:44:24 +0000
Date: Fri, 29 Jun 2012 08:44:23 -1000
Message-ID: <m2ehoy556g.wl%randy@psg.com>
From: Randy Bush <randy@psg.com>
To: Andrei Robachevsky <andrei.robachevsky@gmail.com>
In-Reply-To: <4FEDC445.2030402@gmail.com>
References: <20120606135903.5473.73476.idtracker@ietfa.amsl.com> <m28vg0lev7.wl%randy@psg.com> <4FEDC445.2030402@gmail.com>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset="US-ASCII"
Cc: sidr wg list <sidr@ietf.org>
Subject: Re: [sidr] draft-ymbk-rpki-grandparenting-00.txt
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, 29 Jun 2012 18:44:26 -0000

> Surely, what is described is technically possible, but it gives RPs no
> clue if the procedures were followed. In fact, what a RP may see would
> not be "congruent with the number resource allocation framework" [CP].
> 
> IMO a clean implementation would necessarily entail punching a hole in
> C's certificate. But this is not what the draft recommends.

if A and C both ran CAs, and G has used C's CA to issue a cert and ROA
for G's space, then (when C went unresponsive) A could either issue a
ROA to G or a cert and a ROA.  both work.  seems to me to be more a
matter of style than conformity.

it is no more a matter of 'hole punching' than A issuing a ROA for
various sub-pieces of its own space.  

what is interesting is the sharing of responsibility and control, not
that it is a subset of the space.  note that A might have owned a /16
which it then delegated a the whole /16 to C who redelegated the /16 to
G.  look ma, no holes!

randy