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

Danny McPherson <danny@tcb.net> Mon, 01 December 2008 22:34 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 8A4023A6BB1; Mon, 1 Dec 2008 14:34:26 -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 CFB9E28C103 for <sidr@core3.amsl.com>; Mon, 1 Dec 2008 14:34:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.063
X-Spam-Level:
X-Spam-Status: No, score=-1.063 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482]
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 enipbCnfyQsj for <sidr@core3.amsl.com>; Mon, 1 Dec 2008 14:34:24 -0800 (PST)
Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 0614A28C0E4 for <sidr@ietf.org>; Mon, 1 Dec 2008 14:34:24 -0800 (PST)
Received: by dog.tcb.net (Postfix, from userid 0) id 6D324268766; Mon, 1 Dec 2008 15:34:20 -0700 (MST)
Received: from [192.168.0.100] (97-122-99-176.hlrn.qwest.net [97.122.99.176]) (authenticated-user danny) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Mon, 01 Dec 2008 15:34:20 -0700 (MST) (envelope-from danny@tcb.net)
X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=97.122.99.176; client-port=51109; syn-fingerprint=65535:55:1:64:M1316,N,W3,N,N,T,S; data-bytes=0
Message-Id: <264FCEF8-3DD1-49AB-B41F-56FD0A1B2870@tcb.net>
From: Danny McPherson <danny@tcb.net>
To: Geoff Huston <gih@apnic.net>
In-Reply-To: <CB9CD7AF-8CD3-4636-8D64-E876B9216B47@apnic.net>
Mime-Version: 1.0 (Apple Message framework v929.2)
Date: Mon, 01 Dec 2008 15:34:19 -0700
References: <C542C40B.5166%andy@arin.net> <A3751517-D15C-45DD-B530-027758F36B04@apnic.net> <FC10BBCC-6144-4420-ACFC-9454F26444BE@tcb.net> <6F70023C-57B1-4C8D-8DDF-B9D7D8F139F9@apnic.net> <56AFA6B5-BCFB-4CDC-B921-3590F71CCBA0@tcb.net> <0072BC84-507D-497C-B8B6-0F26DE804316@apnic.net> <19318B76-0E1E-4DC5-8017-D2350352169C@tcb.net> <16C1A7B4-C46F-4354-B1F8-4AF8EB5249B9@apnic.net> <C4A37FE7-88F1-4DEC-AB81-CC2EC6A96C79@tcb.net> <D1AE3911-CBB9-451A-AE47-CB254E403DED@apnic.net> <EC1B7F06-4137-4F97-8EE5-7676DB0E7155@tcb.net> <BD48FF05-04D0-4B71-AF1B-F074E0199202@apnic.net> <A09B46E4-02B0-4825-888C-CA24CD68EF50@tcb.net> <CB9CD7AF-8CD3-4636-8D64-E876B9216B47@apnic.net>
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 Nov 25, 2008, at 6:39 PM, Geoff Huston wrote:
>
> Sure. So here's some use cases of BOAs:
>
> 1. I have been allocated 203.10.61.0/24. I do not use it today in  
> any public routing context. It should not appear in BGP at all. I do  
> not give my authorization to any AS to originate a route for this  
> prefix, or any more specific of this prefix. If I generate a BOA for  
> 203.10.61.0/24 then my intention of saying that any use of this  
> prefix in the public Internet is unauthorized is clear.

If you do not give your authorization then do not issue a ROA.
With the incremental deployment argument, I'm not sure who would
be looking at BOAs if they're not looking at ROAs.

> 2. I have been allocated AS 131074 as an AS number. I do not use it  
> today in any public routing context. It should not appear in BGP at  
> all either as an origination AS nor as a transit AS in any AS path.  
> If I generate a BOA for AS131074 then my intention of saying that  
> any use of this AS number in the public Internet is unauthorized is  
> clear.

But the draft currently does not mitigate "nor as a transit AS",
unless I'm missing something.  Specifically:

S.5 graf 2:

"If a route object has an AS origination that refers to an AS number  
that is listed in a valid BOA, then the route object can be regarded  
as a Bogon object, and local policies that apply to Bogon AS's can be  
applied to the object. This holds whether or not the address prefix of  
the route object is described by a valid ROA or not."

I see nothing about "or as a transit AS" in there.

> 3. I have been allocated 203.10.60.0/22. I wish to ensure that any  
> more specific advertisement of this prefix is unauthorized. If I  
> generate a BOA for 203.10.60.0/23 AND 203.10.62.0/23 then my  
> intention is clear.

I still don't by it..  As an operator, you tell me who is authorized
to originate and that's the only origin AS I accept.  That's easier to
configure in a router, requires less objects in the RPKI, and makes life
much simpler.

> And a non-use case of BOAs:
>
> 4. I am a wholesale ISP, and while I allocate address space to my  
> clients from my aggregate address block (10.0.0.0/8) I also permit  
> my clients to use their more specific prefix at local exchanges. My  
> AS number is 131072 and I have generated a ROA for 10.0.0.0/8 ,  
> maxlength=8  origin AS 131072. I do not have a problem with more  
> specifics of 10.0.0.0/8 being used in routing contexts, as part of  
> my wholesale stance. I would prefer that my ROA did not cause my  
> customer's more specifics to be treated as unauthorized routes,  
> irrespective of whether they are ready to use a ROA today or not.


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