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

Andrew Newton <andy@hxr.us> Wed, 10 December 2008 14:27 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 79D363A6B9F; Wed, 10 Dec 2008 06:27:53 -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 469863A6B9F for <sidr@core3.amsl.com>; Wed, 10 Dec 2008 06:27:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 z2w-MSgM6KUs for <sidr@core3.amsl.com>; Wed, 10 Dec 2008 06:27:51 -0800 (PST)
Received: from zeke.ecotroph.net (zeke.ecotroph.net [70.164.19.155]) by core3.amsl.com (Postfix) with ESMTP id 727A03A68DC for <sidr@ietf.org>; Wed, 10 Dec 2008 06:27:51 -0800 (PST)
Received: from zx80.arin.net ([::ffff:192.136.136.49]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Wed, 10 Dec 2008 09:27:44 -0500 id 01588470.493FD1E0.00006B27
Message-Id: <3998050D-E54A-4F8B-8D18-0AAB55956879@hxr.us>
From: Andrew Newton <andy@hxr.us>
To: Stephen Kent <kent@bbn.com>
In-Reply-To: <p06240501c55b5d22b2c5@[69.58.70.106]>
Mime-Version: 1.0 (Apple Message framework v929.2)
Date: Wed, 10 Dec 2008 09:27:43 -0500
References: <C5521DCD.5484%andy@arin.net> <p06240501c559c1c219eb@[128.89.89.227]> <BEA2AFBC-3315-4ECB-95C2-FB515C6ED01E@apnic.net> <p06240501c55b5d22b2c5@[69.58.70.106]>
X-Mailer: Apple Mail (2.929.2)
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"; DelSp="yes"
Sender: sidr-bounces@ietf.org
Errors-To: sidr-bounces@ietf.org

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
_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr