Re: [sidr] Route Leak fix: V free routing

"Montgomery, Douglas" <> Mon, 21 November 2011 16:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 979F511E80C0 for <>; Mon, 21 Nov 2011 08:37:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.299
X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FvA5o2ueZL9a for <>; Mon, 21 Nov 2011 08:37:11 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 43AE811E80C9 for <>; Mon, 21 Nov 2011 08:37:10 -0800 (PST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.1.339.1; Mon, 21 Nov 2011 11:37:08 -0500
Received: from ([fe80::41df:f63f:c718:e08]) by ([]) with mapi; Mon, 21 Nov 2011 11:37:08 -0500
From: "Montgomery, Douglas" <>
To: "" <>, "" <>, "" <>, Stephen Kent <>
Date: Mon, 21 Nov 2011 11:37:06 -0500
Thread-Topic: [sidr] Route Leak fix: V free routing
Thread-Index: Acyoa7v2Ab7mGKLzRaWfJukAxZBETw==
Message-ID: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" <>
Subject: Re: [sidr] Route Leak fix: V free routing
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 21 Nov 2011 16:37:15 -0000

These ideas have floated around for 20+ years.  They have even appeared in
early BGP specs ... See "LINK TYPE" in

I actually think this is a useful idea, but the discussion always rat
holes in the supposition of absolute filtering rules and proof by counter

I think it would be simple for transmitters to indicate and sign their
view of the peering relationship they are sending an update over.
Customer, provider, peer, or unspecified.

(where/how you encode this is a detail, I would suggest in the PATH SIG
unless we decide to take on the more general approach below).

What receivers do with that information ... Just like validation state,
would be a matter of local policy.

Worse case is everyone chooses unspecified and we waste two bits under the

Best case for those who don't care about declaring who their
customers/providers are to their customers/providers .... Then receivers
can choose to filter "V" routes if they wish.

Doug Montgomery ­ Mgr. Internet & Scalable Systems Research / ITL / NIST

On 11/21/11 10:01 AM, ""
<> wrote:

>What about using a "BGP community" to set your bit "1/0" and propose
>mechanisms to sign the communities tagged by an AS?
>-----Message d'origine-----
>De : [] De la part de
>Jakob Heitz
>Envoyé : vendredi 4 novembre 2011 06:18
>À : Brian Dickson; Stephen Kent
>Cc : sidr wg list
>Objet : [sidr] Route Leak fix: V free routing
>I had a different idea.
>Model the internet as providers, customers and peers.
>A provider is above you, a customer is below you and
>a peer is level to you.
>Add a "down" bit to the BGPSEC signature block.
>If an AS sends an update to a customer, it sets the
>"down" bit.
>The rule is "V" free routing.
>Once an update goes "down", it can not come back "up".
>Sending to peers is always ok.
>If an AS receives from a customer an update
>that has a "down" bit in the BGPSEC attribute,
>it will detect the update as a route leak.
>Policy will dictate how to deal with it.
>An AS sets the "down" bit to indicate its wish that
>the announced prefix stay within the customer's bounds.
>As it is signed, it can not be changed further down
>the path.
>Jakob Heitz.
>On Tuesday, November 01, 2011 4:01 PM, Brian Dickson <> wrote:
>> Upon further consideration, in the interest of not revealing
>> information that is currently not revealed in BGP, I'll suggest
>> modifying my earlier proposal as follows:
>> - the proposed flag needs to exist and be signed by the sender, but
>> only the last instance of the flag is carried with the route.
>> - the enforcement of not-promote still needs to be done by the
>> protocol
>> - the route will only have the "transit" bit on a per-route basis, of
>> the last AS (regardless of where demotion occurred, if at all)
>> - the receiver of a route with the "transit" bit set will generally
>> already be aware that the receiver is providing transit service, if
>> legitimately set
>> Otherwise, everything else still stands to reason...
>> Brian
>> On Tue, Nov 1, 2011 at 6:45 PM, Brian Dickson
>> <> wrote:
>>> 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 <> 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
>> _______________________________________________
>> sidr mailing list
>sidr mailing list
>sidr mailing list