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> Tue, 02 December 2008 02:32 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 342D83A6859; Mon, 1 Dec 2008 18:32:13 -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 A8AB03A6859 for <sidr@core3.amsl.com>; Mon, 1 Dec 2008 18:32:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.768
X-Spam-Level:
X-Spam-Status: No, score=-0.768 tagged_above=-999 required=5 tests=[AWL=-0.251, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, J_CHICKENPOX_43=0.6]
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 c0JM3J7sr-jj for <sidr@core3.amsl.com>; Mon, 1 Dec 2008 18:32:11 -0800 (PST)
Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id E291B3A67F5 for <sidr@ietf.org>; Mon, 1 Dec 2008 18:32:11 -0800 (PST)
Received: by dog.tcb.net (Postfix, from userid 0) id 6C842268766; Mon, 1 Dec 2008 19:32:08 -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 19:32:08 -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=52244; syn-fingerprint=65535:55:1:64:M1316,N,W3,N,N,T,S; data-bytes=0
Message-Id: <4232C338-DC4C-4746-90BD-5C83C31172A9@tcb.net>
From: Danny McPherson <danny@tcb.net>
To: Sandra Murphy <sandy@sparta.com>
In-Reply-To: <Pine.WNT.4.64.0812011806190.1144@SANDYM-LT.columbia.ads.sparta.com>
Mime-Version: 1.0 (Apple Message framework v929.2)
Date: Mon, 01 Dec 2008 19:32:07 -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> <264FCEF8-3DD1-49AB-B41F-56FD0A1B2870@tcb.net> <Pine.WNT.4.64.0812011806190.1144@SANDYM-LT.columbia.ads.sparta.com>
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 1, 2008, at 4:12 PM, Sandra Murphy wrote:
>
> The issue in incremental deployment is not what the people who  
> haven't deployed it should do but what the people who DO deploy it  
> should do. What do the people who DO understand ROAs(and BOAs) do  
> when they see something unsecured - it might be legit, just not  
> produced by someone who understands ROAs(BOAs).

Right, but if the owner also published a BOA about who they
should not accept it from - what's the value add for those
who have deployed it again?  They can say, ohh, there's a ROA
for AS 1 to originate 10.0.0.0/8.  They also published a BOA
for AS2 to originate 10.0.0.0/16.  So, what's that mean to me
since I deployed it?  Accept 10.0.0.0/8 only from AS 1.  I'm
not going to put a policy in my router that says AND accept
it from anyone else, or any more specific, except AS 2.  Tracking
those BOAs is costing money (hardware, time, complexity) and
there is no added benefit.

>> 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.
>
> So it seems you are in the "and that's all" camp in interpreting  
> ROAs, right?

No, I'm in the "show-me-how-to-configure-this-in-a-router-and-
convince-me-that-all-the-complexity-and-added-infrastructure-is
worth-the-investment-when-I'm-pretty-sure-I'd-be-just-as-happy
with-an-'explicit accept'='implicit deny'-model-like-all-my-other-
security-policies" camp.

I'm certain that if more people who are supposed to deploy this
stuff were paying attention they'd be making the same arguments,
but they're not, and so we need to give heavy consideration to this.

> Does your answer assume operators are using ROAs to produce route  
> filters?

Maybe.

> Does your answer change if operators are using ROAs in the decision  
> procedure, as presented at the last meeting?


Maybe.

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