Re: [sidr] BGPSEC Threat Model ID

Russ White <russw@riw.us> Sat, 05 November 2011 12:48 UTC

Return-Path: <russw@riw.us>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1605B21F8663 for <sidr@ietfa.amsl.com>; Sat, 5 Nov 2011 05:48:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.303
X-Spam-Level:
X-Spam-Status: No, score=-2.303 tagged_above=-999 required=5 tests=[AWL=0.296, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CzciDEc-am9W for <sidr@ietfa.amsl.com>; Sat, 5 Nov 2011 05:48:48 -0700 (PDT)
Received: from ecbiz91.inmotionhosting.com (ecbiz91.inmotionhosting.com [173.205.124.250]) by ietfa.amsl.com (Postfix) with ESMTP id 8EAD621F8610 for <sidr@ietf.org>; Sat, 5 Nov 2011 05:48:48 -0700 (PDT)
Received: from rtp-isp-nat1.cisco.com ([64.102.254.33]:47106 helo=[10.117.153.102]) by ecbiz91.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <russw@riw.us>) id 1RMffz-0008Bq-Iu for sidr@ietf.org; Sat, 05 Nov 2011 08:48:47 -0400
Message-ID: <4EB530B4.4090803@riw.us>
Date: Sat, 05 Nov 2011 08:48:52 -0400
From: Russ White <russw@riw.us>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: sidr@ietf.org
References: <E96517DD-BAC7-4DD8-B345-562F71788C6A@tcb.net> <p06240807cad42f85eb7d@193.0.26.186> <32744.216.168.239.87.1320175657.squirrel@webmail.tcb.net> <p06240801cad6ab773279@193.0.26.186> <D9A38669-883D-4090-9F95-BC5C63220950@tcb.net> <p06240801cad800485596@193.0.26.186> <EEBF68E0-FAD9-4AF3-B81B-78760D200D9B@tcb.net> <p06240808cad85ff73d61@193.0.26.186> <080F8FFF-D2C7-4414-B53A-233F88D2009F@vpnc.org> <CAFU7BATC-6DUDNuadakwSa5wj0ryy0=49=XveBXD5Wv=5JL-ag@mail.gmail.com> <m2aa8c489s.wl%randy@psg.com> <53FA9B4A-552C-4998-8F69-592A0F5AA13B@verisign.com> <CAL9jLaZj1wcmDnbm1f9=csUv2Uuq_w3rS6UEYmUHAQDPWT9zFg@mail.gmail.com> <m262iz2xl8.wl%randy@psg.com> <A2661B25-CC2E-44E4-93CE-5AFE4F67E4DA@verisign.com> <m2pqh71hdz.wl%randy@psg.com> <10A3F6FD-1392-4E6E-A048-A8EED1E8C329@apnic.net>
In-Reply-To: <10A3F6FD-1392-4E6E-A048-A8EED1E8C329@apnic.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - ecbiz91.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - riw.us
Subject: Re: [sidr] BGPSEC Threat Model ID
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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>
X-List-Received-Date: Sat, 05 Nov 2011 12:48:49 -0000

>> o We can not know intent, should Mary have announced the prefix to Bob

Let me point out a fundamental issue here.

Security is, and always has been, about matching intent with reality. If 
I lock my doors, there is an implied intent that no-one go into my house 
(in band). If I give a neighbor a key, I will give them explicit 
instructions as to my intent --"only go in if the dog is barking, or to 
feed the dog, or..." (out of band)

You MUST know intent to provide security. Get over it. You can't match 
expectations to reality unless you know what the expectations are.

What is the entire security model of the RPKI and origin auth? To ensure 
the intent of the RIR in assigning address space is followed, and to 
ensure the intent of the owner of that address space is carried out.

You could argue that you're only trying to secure the "semantics of 
BGP," which means you're trying to enforce the intent of the BGP 
specifications (you can't get away from intent!), but that opens up 
another wormhole of problems.

"You can't prove intent" is a red herring.

:-)

Russ