Re: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-01.txt

Stephen Kent <kent@bbn.com> Fri, 12 December 2008 18:39 UTC

Return-Path: <sidr-bounces@ietf.org>
X-Original-To: sidr-archive@megatron.ietf.org
Delivered-To: ietfarch-sidr-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAAC63A6B03; Fri, 12 Dec 2008 10:39:32 -0800 (PST)
X-Original-To: sidr@core3.amsl.com
Delivered-To: sidr@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0514A28C131 for <sidr@core3.amsl.com>; Fri, 12 Dec 2008 10:39:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.227
X-Spam-Level:
X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YHRBKQQeaJFz for <sidr@core3.amsl.com>; Fri, 12 Dec 2008 10:39:30 -0800 (PST)
Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 17F3F3A6B03 for <sidr@ietf.org>; Fri, 12 Dec 2008 10:39:30 -0800 (PST)
Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from <kent@bbn.com>) id 1LBCv3-0004Lo-Dx; Fri, 12 Dec 2008 13:39:21 -0500
Mime-Version: 1.0
Message-Id: <p06240800c56836ccc2af@[128.33.244.160]>
In-Reply-To: <3998050D-E54A-4F8B-8D18-0AAB55956879@hxr.us>
References: <C5521DCD.5484%andy@arin.net> <p06240501c559c1c219eb@[128.89.89.227]> <BEA2AFBC-3315-4ECB-95C2-FB515C6ED01E@apnic.net> <p06240501c55b5d22b2c5@[69.58.70.106]> <3998050D-E54A-4F8B-8D18-0AAB55956879@hxr.us>
Date: Fri, 12 Dec 2008 10:52:28 -0500
To: Andrew Newton <andy@hxr.us>
From: Stephen Kent <kent@bbn.com>
Cc: sidr@ietf.org
Subject: Re: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-01.txt
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: sidr-bounces@ietf.org
Errors-To: sidr-bounces@ietf.org

At 9:27 AM -0500 12/10/08, Andrew Newton wrote:
>On Dec 2, 2008, at 7:24 PM, Stephen Kent wrote:
>
>>An AS 0 ROA is a positive assertion about the prefixes expressed in 
>>it, as far as RP software is concerned. The "feature" of this 
>>assertion is that, any unauthenticated assertions about the 
>>prefixes should be rejected in favor of this verifiable ROA 
>>(assuming that the ROA was signed by an entity that holds the 
>>prefixes in question). In saying that I am making some assumptions 
>>about how ROs use ROAs, and Danny has argued that we need to be 
>>more precise about such assumptions.
>>
>>I see the AS 0 ROA as a valuable tool to deal with unallocated and 
>>reserved address space, during the very long period when relying 
>>parties will see a mix of verifiable and unverifiable assertions 
>>about route origination. I have not thought so much about the 
>>utility of this capability in a fully deployed system. I also did 
>>not consider assertions about AS numbers, a feature of BOAs.
>
>Steve,
>
>Sorry for the late reply on this subject, but I was rereading the 
>archives and it brought to my recollection a statement you made at 
>the microphone in Minneapolis regarding AS 0 ROAs.  I didn't readily 
>grasp the meaning of what you said, so I'm seeking clarification.
>
>As I recall, you stated that a registry wishing to use a BOA to 
>cover its space could just as well use AS 0 ROAs with a different 
>practice.  
>Whenever that registry allocated space, it would have to reissue the 
>AS 0 ROAs so the newly allocated space is not covered.  At least I 
>think that was the gist of what you described.
>
>Is this correct, or can you explain again the scenario you mentioned?
>
>-andy


Andy,

Your characterization is good paraphrase of my comments at the mic. 
In fairness to Geoff's BOA proposal, my ROA As 0 convention is not as 
powerful, in that it has no provisions for making a negative 
assertion about AS numbers.

If I were a registry (or an ISP) making use of the AS 0 ROA approach, 
I would issue one EE cert and one associated ROA )covering all of the 
unallocated space that I hold). The EE cert would have a lifetime 
consistent with the time I take to respond to allocation requests, 
maybe on 1-day lifetime. That way I would not have to put the EE cert 
on a CRL when a new AS 0 ROA was issued; I'd just be issuing one new 
cert and one new ROA every day. Since it is probably good practice to 
issue a CRL every day, the set of objects published by the 
registry/ISP would have to change that frequently anyway, so this is 
not much of a new burden, (e.g., the manifest has to change whenever 
a new CRL is issued).

I also note that even if we don't adopt AS 0 ROAs as a recognized way 
to make this sort of assertion, any ROA issuer can use it anyway, 
either explicitly or via analogous means :-).

Steve


_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr