Re: [sidr] Route Leaks and BGP Security

Terry Manderson <> Tue, 22 November 2011 04:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1A1C61F0C4C for <>; Mon, 21 Nov 2011 20:15:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cQRqNHg5UiOQ for <>; Mon, 21 Nov 2011 20:15:17 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 55DB61F0C43 for <>; Mon, 21 Nov 2011 20:15:17 -0800 (PST)
Received: by ggnp4 with SMTP id p4so844355ggn.31 for <>; Mon, 21 Nov 2011 20:15:16 -0800 (PST)
Received: by with SMTP id s1mr3639562anm.164.1321935316343; Mon, 21 Nov 2011 20:15:16 -0800 (PST)
Received: from [] ( []) by with ESMTPS id h28sm35562468ani.17.2011. (version=TLSv1/SSLv3 cipher=OTHER); Mon, 21 Nov 2011 20:15:15 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Terry Manderson <>
In-Reply-To: <>
Date: Tue, 22 Nov 2011 14:15:09 +1000
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <>
To: Christopher Morrow <>
X-Mailer: Apple Mail (2.1084)
Cc: sidr wg list <>
Subject: Re: [sidr] Route Leaks and BGP Security
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: Tue, 22 Nov 2011 04:15:18 -0000

Speaking for myself on this one.

On 22/11/2011, at 12:47 PM, Christopher Morrow wrote:
> ok, so if we step forward and ask for 'give me an attribute to
> indicate customer/peer/other', would we then trust that? it'd be
> (presumably) set per as-hop, is that anymore trustworthy than the
> communities supposed above?
> (I'd also ask what the rules are for setting this sort of thing, but I
> don't think that matters since we can't really trust the value in it)

So lets say (hypothetically) we adopt a requirement of this system to allow a relying party to parse a route and know if it is intended or not by some construction of verifiable information.

I can't, for the life of me, see a transitive attribute _in_ BGP (signed or otherwise) making a positive step in trying to secure intent of the local AS as effected by a routing domain 2+ hops away.

> yup, I don't think we're going to get to the fully publicly exposed
> policy world though... are we? (we can't, I think, expect everyone to
> expose that sort of thing, never mind keep it updated)

History tells us we are (for the most part) inept at doing so, even with tools available.

But what we do know is that when policy is implemented, the results are transparent and can be seen
(ris, routeviews, et al) by anyone who cares to look.

> yup... no-export/advertise were taken as 'advisory' communities that
> networks MAY heed, but certainly weren't bound to do so.
> So, back to the question:
> "Given BGP as it is today, how do you know if a route is a leak or not?"
> I suppose documenting: "One leak scenario is <see id name>" is a fine
> thing, does it help to actually fix the problem though? I think what I
> heard in the meeting and on the thread(s) here was: "Sure leaks are
> important, there's not a way devised so far that distinguishes a
> 'leak' route from a 'normal' route, more than 1 as-hop from the
> 'source' of the leak.
> In the id/draft:
>   isp1   isp2 - me
>       \     /
>        AS1
> I can't tell at 'me' that the route I see is a 'leak', just that I see
> an as-path that is isp1-as1-isp2.

The bit I think that is missing is some knowledge that isp1 asserts it has valid routing through isp2, and any other potential 'true' paths. (noting AS1 is considered the 'Serleena' here)

From what I recall draft-huston-sidr-aao-profile takes a step in that direction. (insert my reluctance about tightly binding routing operations to allocation practice) in such that it only publicises the valid paths, through subsequent AAO's by by other ASNs. Thus if an AAO (in my reading) is created by isp1 with only an adjacency to isp2. It provides "me" with an ability to say that the received route with AS1 on path is invalid.

The AAO doesn't dive into local policy, and if isp1 has a private peering with AS3, then it need not put that in an AAO and thus the business dealings remain private - everything else ends up being seen in routeviews over time. So this is one way... but not the only way.

The killer problem here is that partial deployments will create path islands, where only a number of the ASN hops have created AAO objects and thus a path validity exercise will still fall into a potential leak trap until all ASNs get there. The question then could then be, "is it o.k. for the answer to route leaks to be near unusable until we have a significant deployment"