Re: [sidr] BGPSEC Threat Model ID
Stephen Kent <kent@bbn.com> Wed, 02 November 2011 16:36 UTC
Return-Path: <kent@bbn.com>
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 3F75011E80AE for <sidr@ietfa.amsl.com>; Wed, 2 Nov 2011 09:36:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.463
X-Spam-Level:
X-Spam-Status: No, score=-106.463 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 iKg0d-eCfwvo for <sidr@ietfa.amsl.com>; Wed, 2 Nov 2011 09:36:12 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id ECB8111E8090 for <sidr@ietf.org>; Wed, 2 Nov 2011 09:36:11 -0700 (PDT)
Received: from dommiel.bbn.com ([192.1.122.15]:46117 helo=[193.0.26.186]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1RLdnO-000MCL-0y; Wed, 02 Nov 2011 12:36:10 -0400
Mime-Version: 1.0
Message-Id: <p0624080fcad71d2a2f00@[193.0.26.186]>
In-Reply-To: <CAH1iCir-UoT+BMOD53oxQ9fdMiGirvaTL0eZDS3A5wVEDuw2LA@mail.gmail.com>
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> <CAH1iCir-UoT+BMOD53oxQ9fdMiGirvaTL0eZDS3A5wVEDuw2LA@mail.gmail.com>
Date: Wed, 02 Nov 2011 12:35:42 -0400
To: Brian Dickson <brian.peter.dickson@gmail.com>
From: Stephen Kent <kent@bbn.com>
Content-Type: multipart/alternative; boundary="============_-891870727==_ma============"
Cc: sidr wg list <sidr@ietf.org>
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: Wed, 02 Nov 2011 16:36:13 -0000
At 12:08 PM -0400 11/2/11, Brian Dickson wrote: >... > >BGPSEC is an _extension_ to BGP. (This is according to the WG Charter.) >Adding ways of identifying updates as "bad", whether because of >failure to authenticate, >or because of authenticated data which indicates a semantic violation, >is in-charter. >Blocking updates does not fundamentally change the BGP path selection process. >Thus, it isn't more than an enforced filtering methodology. It fits >squarely within the >model proposed by BGPSEC. Dropping an update because it fails BGPSEC validation is certainly in scope, and it is consistent with the BGP model, which allows any AS to drop any update for any reason. >If there is a need to address _malicious_ route leaks, and it is not >possible to address >without securing the necessary added semantic elements, then clearly >those added >elements can't and won't be done by the IDR WG, since securing those elements >would be the responsibility of SIDR. logical, and likely to be true :-). >Put another way - adding elements to BGP to address accidental route >leaks will do >nothing to address malicious route leaks. I don't agree that this follows, but it might be true anyway. >On the other hand, anything which addresses malicious route leaks, by >definition, >will also address accidental route leaks. probably. >Malicious route leaks and accidental route leaks are two of the >biggest threats to BGP. >Having two solutions, one done by IDR and another by SIDR, is >clearly redundant, >since the SIDR solution would make the IDR solution moot. I doubt that we will have two solutions, so I will not worry about this. >Thus, it make the most sense to include the solution to malicious >route leaks in SIDR's mandate. that does not follow. In addition to the charter question (for which I think there is a clear, out-of-scope answer) the other major issue is whether a solution to route leaks is consistent with the basic BGP model. if so, then I suspect that IDR will be happy to have SIDR proceed with such a solution, under a revised, extended charter. If not, then IDR could rightfully object that our extensions are inappropriate. >If need be, I request the WG chairs expressly poll the WG on this issue. > >I suggest that the issue remain in-charter for some period of time, >until a solution to the problem is presented, >at which time it be included in the main protocol document for BGPSEC, >at which time it become mandatory. The SIDR charter is very brief and it lays out some clear requirements which I cite below. These do not extend to route leaks. >(BTW - I have already given a preliminary proposal, which is not an >I-D yet, and which needs some work. >But, this establishes the feasibility of achieving the semantics >needed to mitigate the risk of route leaks.) I've been busy replying to Danny's messages, so I have not looked at your proposal. >... > >Here's the thing: >(1) RPKI authenticates the Originator. >(2) The Originator signs "stuff" carefully restricted stuff. >(2a) "stuff" MUST include all the things from RPKI. not really. look at the BGPSEC protocol sig block. >(3) Every additional AS in the path adds itself and signs the result. >(4) "Stuff" can include additional elements in addition to the things >already identified in the -00 version of the protocol document. it could, if appropriate. >(4a) The signature allows the receiver to validate that it was sent by >the Originator. The RPKI assures that the Originator is allowed to >originate the Update. and the sig is matched against RPKI data to verify that the BGP speaker that signed the update did so on behalf of an ASN that the speaker is authorized to represent. when the data covered by the sig is AS path info, the semantics of the RPKI certs and ROAs match the signed data. when we consider adding other data under a sig, we have to ask whether it is sufficient to know that a specific speaker signed the data. As an example, if one receives an S/MIME message, and the sig validates, that does NOT mean that you can trust he FROM field in the message header! >(4b) It follows that there is no reason not to trust all Transitive >values set by Originator, and Signed by the Originator disagree, for the reasons alluded to above. >(4c) It also follows that Non-Transitive values could be set by one's >Neighbor AS, signed by that AS, and have those values Secured. huh? >(5) If any BGP path attribute used in Path Selection is not signed, >then BGPSEC has failed to meet its charter requirements. Look at the charter again. In particular it begins by saying: The purpose of the SIDR working group is to reduce vulnerabilities in the inter-domain routing system. The two vulnerabilities that will be addressed are: * Is an Autonomous System (AS) authorized to originate an IP prefix * Is the AS-Path represented in the route the same as the path through which the NLRI traveled The charter does NOT say that other path attributes need to be secured. Steve
- [sidr] BGPSEC Threat Model ID Danny McPherson
- Re: [sidr] BGPSEC Threat Model ID Stephen Kent
- Re: [sidr] BGPSEC Threat Model ID Danny McPherson
- Re: [sidr] BGPSEC Threat Model ID Stephen Kent
- Re: [sidr] BGPSEC Threat Model ID Brian Dickson
- Re: [sidr] BGPSEC Threat Model ID Russ White
- Re: [sidr] BGPSEC Threat Model ID Stephen Kent
- Re: [sidr] BGPSEC Threat Model ID Brian Dickson
- Re: [sidr] BGPSEC Threat Model ID Russ White
- Re: [sidr] BGPSEC Threat Model ID Randy Bush
- Re: [sidr] BGPSEC Threat Model ID Brian Dickson
- Re: [sidr] BGPSEC Threat Model ID Russ White
- Re: [sidr] BGPSEC Threat Model ID Danny McPherson
- Re: [sidr] BGPSEC Threat Model ID Danny McPherson
- Re: [sidr] BGPSEC Threat Model ID Stephen Kent
- Re: [sidr] BGPSEC Threat Model ID Russ White
- Re: [sidr] BGPSEC Threat Model ID Danny McPherson
- Re: [sidr] BGPSEC Threat Model ID Stephen Kent
- Re: [sidr] BGPSEC Threat Model ID Paul Hoffman
- Re: [sidr] BGPSEC Threat Model ID George, Wes
- Re: [sidr] BGPSEC Threat Model ID Shane Amante
- Re: [sidr] BGPSEC Threat Model ID Randy Bush
- Re: [sidr] BGPSEC Threat Model ID Eric Osterweil
- Re: [sidr] BGPSEC Threat Model ID George, Wes
- Re: [sidr] BGPSEC Threat Model ID Danny McPherson
- Re: [sidr] BGPSEC Threat Model ID Jen Linkova
- Re: [sidr] BGPSEC Threat Model ID Christopher Morrow
- Re: [sidr] BGPSEC Threat Model ID Brian Dickson
- Re: [sidr] BGPSEC Threat Model ID Randy Bush
- Re: [sidr] BGPSEC Threat Model ID Randy Bush
- Re: [sidr] BGPSEC Threat Model ID Sriram, Kotikalapudi
- Re: [sidr] BGPSEC Threat Model ID Eric Osterweil
- Re: [sidr] BGPSEC Threat Model ID Brian Dickson
- Re: [sidr] BGPSEC Threat Model ID Christopher Morrow
- Re: [sidr] BGPSEC Threat Model ID Christopher Morrow
- Re: [sidr] BGPSEC Threat Model ID Jakob Heitz
- Re: [sidr] BGPSEC Threat Model ID Christopher Morrow
- Re: [sidr] BGPSEC Threat Model ID Brian Dickson
- Re: [sidr] BGPSEC Threat Model ID Randy Bush
- Re: [sidr] BGPSEC Threat Model ID Randy Bush
- Re: [sidr] BGPSEC Threat Model ID Eric Osterweil
- Re: [sidr] BGPSEC Threat Model ID Randy Bush
- Re: [sidr] BGPSEC Threat Model ID Christopher Morrow
- Re: [sidr] BGPSEC Threat Model ID Christopher Morrow
- Re: [sidr] BGPSEC Threat Model ID Danny McPherson
- Re: [sidr] BGPSEC Threat Model ID Shane Amante
- Re: [sidr] BGPSEC Threat Model ID Christopher Morrow
- Re: [sidr] BGPSEC Threat Model ID Shane Amante
- Re: [sidr] BGPSEC Threat Model ID Christopher Morrow
- Re: [sidr] BGPSEC Threat Model ID Geoff Huston
- Re: [sidr] BGPSEC Threat Model ID Jakob Heitz
- Re: [sidr] BGPSEC Threat Model ID Brian Dickson
- Re: [sidr] BGPSEC Threat Model ID Russ White
- Re: [sidr] BGPSEC Threat Model ID Russ White
- Re: [sidr] BGPSEC Threat Model ID Russ White
- Re: [sidr] BGPSEC Threat Model ID Brian Dickson
- Re: [sidr] BGPSEC Threat Model ID Brian Dickson
- Re: [sidr] BGPSEC Threat Model ID Stephen Kent
- Re: [sidr] BGPSEC Threat Model ID Geoff Huston
- Re: [sidr] BGPSEC Threat Model ID Stephen Kent
- Re: [sidr] BGPSEC Threat Model ID Danny McPherson