Re: [sidr] BGPSEC Threat Model ID

Geoff Huston <gih@apnic.net> Sat, 05 November 2011 04:10 UTC

Return-Path: <gih@apnic.net>
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 ECF3421F84A5 for <sidr@ietfa.amsl.com>; Fri, 4 Nov 2011 21:10:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.429
X-Spam-Level:
X-Spam-Status: No, score=-100.429 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_SORBS_WEB=0.619, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
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 5-1RNIuwYMnu for <sidr@ietfa.amsl.com>; Fri, 4 Nov 2011 21:10:02 -0700 (PDT)
Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id 778B621F8493 for <sidr@ietf.org>; Fri, 4 Nov 2011 21:09:54 -0700 (PDT)
Received: from [192.168.50.152] (unknown [213.164.30.109]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 94DA9B6761 for <sidr@ietf.org>; Sat, 5 Nov 2011 14:09:52 +1000 (EST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Apple Message framework v1251.1)
From: Geoff Huston <gih@apnic.net>
In-Reply-To: <m2pqh71hdz.wl%randy@psg.com>
Date: Sat, 05 Nov 2011 15:09:47 +1100
Content-Transfer-Encoding: quoted-printable
Message-Id: <10A3F6FD-1392-4E6E-A048-A8EED1E8C329@apnic.net>
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>
To: sidr wg list <sidr@ietf.org>
X-Mailer: Apple Mail (2.1251.1)
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 04:10:36 -0000

On 05/11/2011, at 12:34 PM, Randy Bush wrote:

>> I think the distinction between a leak and something more intentional
>> s a matter of policy.  Knowing the policy associated with the
>> adjacencies that an AS is leaking over would allow leaked
>> announcements to be identified
> 
> o We can not know intent, should Mary have announced the prefix to Bob


I disagree with this assertion of impossibility. The intention of the routing
policy databases in their various flavours and incarnations was to publish
intent and allow others to filter based on intent.

Yes, there is a viable form of filtering wayward prefix advertisements
that are of the form of adherence or otherwise to published intent, and if
everybody scrupulously entered the entirety of their routing policy into
some form of routing policy database then indeed there could be a viable
case to be made that you could create a routing security framework based
on such foundations.

So I'm not dismissive about the impossibility to know intent. One can
in theory know intent, and filter based on intent.

In many ways this is not so much different than what is going on with the
effort to secure the outcome operation of the protocol. In this case the routing
intent of the originator is not exposed, but it is possible to expose the relationship
between the originator and the prefix holder, and expose the authenticity of
inter-AS transactions that are described in the AS path. Again the same observation
is that this only really works if everyone plays along, otherwise the gaps
in the knowledge based of signed attestations cripple the general benefit of the outcome.

So these are two different sides of a validation coin, if you'll pardon the
analogy. One side says "I have no idea if BGP is being warped and twisted
or not, but if what I hear from my peer conforms to the set of published routing
policies, then I'll accept the update", while the other says "I have no
idea if this was intentional or not, but what I have received is not the
result of warping and twisting the operation of the BGP in unnatural ways
then I'll accept the update".

I suspect that most of this thread is these two points of view arguing past 
each other.