[sidr] BGPsec - proposal for threat model, protocol, requirements

Brian Dickson <brian.peter.dickson@gmail.com> Tue, 01 November 2011 22:45 UTC

Return-Path: <brian.peter.dickson@gmail.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 E55D31F0C5B for <sidr@ietfa.amsl.com>; Tue, 1 Nov 2011 15:45:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.551
X-Spam-Level:
X-Spam-Status: No, score=-3.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 Tu2Q+DvoZs4h for <sidr@ietfa.amsl.com>; Tue, 1 Nov 2011 15:45:05 -0700 (PDT)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id AF7AF1F0C36 for <sidr@ietf.org>; Tue, 1 Nov 2011 15:45:04 -0700 (PDT)
Received: by faas12 with SMTP id s12so8270296faa.31 for <sidr@ietf.org>; Tue, 01 Nov 2011 15:45:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=CXM29YWn/Hyyf0yv5nieOG2HCoi0u5coVT1oMbT5dzE=; b=LYG+CI3UfMrSwesIrJiXESyokfXADDsw0C+yF1dQzOnDcQeqzY8XsxjzCBS7wsAsbR i0wZJcuLeIf+yWzP5brjMpiEDlTFQarnNUaVc+ZYWiEkRIpiQDh5XmJ5aNhN9dOKD+aS P1LPw6CJz2+Ojd05qq9AMdJWn/oenRkTnNlFI=
MIME-Version: 1.0
Received: by 10.223.5.82 with SMTP id 18mr3650311fau.27.1320187503863; Tue, 01 Nov 2011 15:45:03 -0700 (PDT)
Received: by 10.223.54.15 with HTTP; Tue, 1 Nov 2011 15:45:03 -0700 (PDT)
Date: Tue, 1 Nov 2011 18:45:03 -0400
Message-ID: <CAH1iCiotz1L=N_bj6rxzeSqGiLRaL9QG5pPgf==ePGnmDAGjCQ@mail.gmail.com>
From: Brian Dickson <brian.peter.dickson@gmail.com>
To: Stephen Kent <kent@bbn.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: sidr wg list <sidr@ietf.org>
Subject: [sidr] BGPsec - proposal for threat model, protocol, requirements
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: Tue, 01 Nov 2011 22:45:06 -0000

I have a proposal, to address the route-leak issue. It necessarily requires
changes to all of the following documents, if it is adopted:
- threat model
- protocol
- requirements
- NB: this proposed element does not have a corresponding value in vanilla BGP.
- (If BGP had this already, there would not be any route leaks.)

Here is what I propose:
Add an announced Path Attribute, "Transit", to every BGPSEC signature
block on an announced prefix.
"Transit" is a flag bit, and applies to the _announcement_ between
ASNs in the path.
Include this Transit flag in the set of things that are signed.
Make this attribute mandatory to BGPSEC, applied to every signature
block on a route.

Every BGPSEC peering session is either Transit, or Not-Transit, from
the perspective of the local AS.

For BGPSEC speakers A and B, all four combinations are legitimate scenarios:
A and B are "strictly speaking, peers" - e.g. 'tier-1' networks A and B:
- A->B is "not-transit"
- B->A is "not-transit"
A provides transit to B (or vice versa; exchange labels A and B):
- A->B is "not-transit"
- B->A is "transit"
A and B provide "mutual backup transit":
- A->B is "transit"
- B->A is "transit"

The last scenario *should* be extremely rare. The last scenario
happens to also be the default behavior
for BGP when unconstrained routing announcements exist, i.e.
inexperienced network engineers are
given "enable" and asked to "do BGP".

Here are the specific details and semantics, that in general make "the
right thing" happen, and stop
route leaks from happening, whether by accident or design.

1) The "transit" bit can be demoted to "not-transit" (on received,
signed BGPSEC routes).
2) The "transit" bit cannot be promoted from "not-transit" to
"transit" (on received, signed BGPSEC routes).
3) Routes can be originated as "transit" or "not-transit". The
sensible default behavior is "transit".
4) Routes that are received, under a default configuration, SHOULD be
demoted to "non-transit".
4a) Transit ISPs MUST change the (default) configuration on their
customers' BGP sessions to not-demote their customers' routes.
4b) Mutual-Transit arrangements MUST change the (default)
configuration to not-demote their respective routes.
5a) A route with the "transit" bit MAY be sent over any BGPSEC peering session.
5b) A route received with the "transit" bit set MAY be accepted by the receiver.
6a) A route with the "transit" bit not set (i.e. a not-transit route)
MAY NOT be sent over a peering session that does not permit "transit"
routes in unmodified (i.e. a peering session that demotes to
not-transit).
6b) A route with the "transit" bit not set (i.e. a non-transit route)
MAY ONLY be accepted over a peering session configured to send
"transit" routes (i.e. an "upstream" peer).

If this logic is implemented in the PROTOCOL, and outside of user
configuration control
(i.e. limiting user control to "not-demote" and "send-transit"),
route leaks cannot happen, or at worst have a scope
of the next local AS if the _receiver_ makes a configuration error.

That is to say, route leaks become, at worst, non-transitive.

Here's a summary of how and why:
Not-transit (peer) routes can only be sent "downstream",
where "downstream" can include mutual-transit links.
Transit routes can be sent everywhere, but only retain
their "transit" bits when _both_ the sender _and_ receiver agree
that the link is a transit link.

As soon as a route loses its "transit" bit, it can never regain it,
whether by accident or design.

Note the following:
- "Transit" or "not-Transit" is applied on the sender side of peering.
Default is "Transit".
- "Demote" or "not-Demote" is applied on the receiver side of peering.
Default is "Demote".
- The originator of a route sets "Transit".
- "Transit" on a sender-side really means "Do not demote this on send".
- Thus, a sender with "Transit" configured, will never _promote_ a
non-transit route to transit.
- And thus, a receiver will automatically filter out
"non-transit"-marked routes from a combined
 set of routes that includes "transit" and "not-transit", if only
"transit" are allowed (e.g. an upstream ASN)

[The original motivating discussion follows...]

On Tue, Nov 1, 2011 at 9:57 AM, Stephen Kent <kent@bbn.com> wrote:
> At 4:20 PM -0400 10/29/11, Danny McPherson wrote:
>
> Some comments on sidr-bgpsec-threats-00 below..
>
> Most substantial of my concerns is Section 5's "Residual
> Vulnerabilities", specifically:
>
>  "BGPSEC has a separate set of residual vulnerabilities:
>
>   - BGPSEC is not able to prevent what is usually referred to as
>     route leaks, because BGP itself does not distinguish between
>     transit and non-transit ASes-

This is a chicken-and-egg issue. Since there are several documents before
the WG, some of which have not yet even been accepted by the WG, it
is premature to say what BGPSEC does and does not do.

We are (in this WG) collectively defining what BGPSEC does and does not do.
The real question is, fundamentally, are there unavoidable limitations that
make it impossible for BGPSEC to do particular things?

> Do we really consider it acceptable that the solution and machinery
> we're recommending will NOT prevent "route leaks",

IMHO, "No". Frankly, I consider fixing the route leak problem non-negotiable.
We can and must fix it. It hasn't been fixed in BGP, because there has
always been the
ability to mess with transitive attributes. Without enforcement, it
can't truly be fixed.

Since BGPSEC is solving the attribute-tampering problem, the practical realities
that enabled route leaks, no longer strictly exist (within a BGPSEC realm).
Which means, we can stop route leaks.

I argue that, because we can, now, we MUST.

> Route leaks represent a violation of an ISPs local policy, i.e., the ISP
> is propagating routes that it, locally, did not intend to propagate. There
> is no semantic in BGP that captures this aspect of local policy.

Actually, no. Route leaks represent both a violation of a BGP speaker's intended
local policy, *and* a violation of other BGP speakers' intended policies.

There is nothing that prevents the addition of this new semantic
(single bit) alongside signatures,
and in particular within the signed data, which unequivocably
establishes this intent.

By signing the intent, it becomes globally known as well as locally significant.
And by being signed, it is tamper-evident. Rejecting tampered paths,
or de-prefering
tampered paths, eliminates route leaks.

Problem solved (IMNSHO).

Brian