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

Geoff Huston <gih@apnic.net> Mon, 01 December 2008 19:59 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 20EBD3A67A7; Mon, 1 Dec 2008 11:59:38 -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 E40B53A67A7 for <sidr@core3.amsl.com>; Mon, 1 Dec 2008 11:59:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.549
X-Spam-Level:
X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 EE--PwJGqNmx for <sidr@core3.amsl.com>; Mon, 1 Dec 2008 11:59:36 -0800 (PST)
Received: from asmtp.apnic.net (asmtp.apnic.net [202.12.29.51]) by core3.amsl.com (Postfix) with ESMTP id D127E3A676A for <sidr@ietf.org>; Mon, 1 Dec 2008 11:59:35 -0800 (PST)
Received: from dhcp20.potaroo.net (dhcp20.potaroo.net [203.10.60.20]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 2533A110068; Tue, 2 Dec 2008 05:59:30 +1000 (EST)
Message-Id: <BEA2AFBC-3315-4ECB-95C2-FB515C6ED01E@apnic.net>
From: Geoff Huston <gih@apnic.net>
To: Stephen Kent <kent@bbn.com>
In-Reply-To: <p06240501c559c1c219eb@[128.89.89.227]>
Mime-Version: 1.0 (Apple Message framework v929.2)
Date: Tue, 02 Dec 2008 06:59:29 +1100
References: <C5521DCD.5484%andy@arin.net> <p06240501c559c1c219eb@[128.89.89.227]>
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

WG Hair hat OFF

Hi Steve,

What I _think_ you describes as the "ROA use convention" is the use of  
a ROA with an AS of 0 to act as an explicit denial in terms of saying  
"these prefixes are bogons". I could be wrong in my understanding of  
course.

I must admit that right now I don't think I understand your proposed  
"ROA use convention" clearly enough to agree with your assertion

The BOA Approach:

The BOA document is coupled with the ROA validation document so that  
the ROA interpretation and the BOA interpretation are explicitly  
described. in this context the ROA does NOT act with a double meaning  
- it is an explicit authority without any implicit negation  
connotations. The presence of a ROA does not act as a form of negation  
of any other form of route origination. The BOA has no max length  
attribute - any more specific of any prefix described in the BOA is  
encompassed in the BOA.

The "ROA use convention":

This "ROA use convention" has me confused. In particular my confusion  
lies in the following areas:

   1. Does a 'convention ROA' has any implicit denial associated with  
it, or is it a simple positive assertion as described above?

   2. How should a ROA with a AS value of 0 and a maxlength attribute  
be interpreted.
       Does a ROA for prefix=10.0.0.0/8 maxlength=8, AS=0 say anything  
at all about 10.0.0.0/9?

So if you don't mind I'll reserve judgement on your question and  
observe that while the BOA adds a further object to the repertoire of  
'recognised' RPKI signed objects, it does so in a manner that makes  
negation explicit, does not rely on variable interpretation of ROAs,  
does not stretch the ROA semantics beyond the simple positive  
authority to as AS to originate a route and allows for incremental  
piecemeal deployment in the network.

Regards,

    Geoff



On 02/12/2008, at 3:31 AM, Stephen Kent wrote:

> Given Geoff's examples of how to use BOAs, I think the only vase  
> that cannot be handled by the ROA use convention I proposed is the  
> negative assertion about As numbers.
>
> Geoff, do you agree?
>
> Steve

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