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