Re: [sidr] Route Leaks and BGP Security

Brian Dickson <> Tue, 22 November 2011 23:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1976211E80C1 for <>; Tue, 22 Nov 2011 15:18:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.5
X-Spam-Status: No, score=-3.5 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zHUe5iSieoSA for <>; Tue, 22 Nov 2011 15:18:13 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 3D6D411E80BA for <>; Tue, 22 Nov 2011 15:18:13 -0800 (PST)
Received: by bkbzv15 with SMTP id zv15so471730bkb.31 for <>; Tue, 22 Nov 2011 15:18:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qiRCN8deu9xX7nYcPbbWnsh6SO3FwgSS82/3jXt9kz4=; b=AyqDPG3A2cNdWZpW5jzVKoANbXEzW7KYeNCYR5zKvGZJtTSrjlKzUa6YhqBmm4HmeL KxU8JxJgPNzWNyBqNzEeDItS2VpC0RfwXONuEioo8CgG8tyVMla8EJ6/60urfrb2VBld a6v9ZOik9b1fpVgarT52R5kJ1PRojwc4QNFcM=
MIME-Version: 1.0
Received: by with SMTP id l16mr1493337bks.14.1322003892355; Tue, 22 Nov 2011 15:18:12 -0800 (PST)
Received: by with HTTP; Tue, 22 Nov 2011 15:18:12 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <>
Date: Tue, 22 Nov 2011 18:18:12 -0500
Message-ID: <>
From: Brian Dickson <>
To: Christopher Morrow <>
Content-Type: text/plain; charset="ISO-8859-1"
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 23:18:14 -0000

On Tue, Nov 22, 2011 at 4:12 PM, Christopher Morrow
<> wrote:
> On Tue, Nov 22, 2011 at 7:35 AM, Russ White <> wrote:
>> insistence that local policy overrules the signatures --so all the
>> entire SIDR effort is doing is providing more information on which to act.
> sure.
>> Why wouldn't signing communities be providing more information on which
>> to act, as well? How can we say that providing more information on which
> If communities were guaranteed to exist along the entire path, maybe?
> If people didn't add communities and drop them 'at will' maybe? If we
> understood what a community meant, maybe?
> I don't see any of the three things there being the case though :(
> Communities are really only useful inside a single AS or to the direct
> peers (where they signal ala RFC1998 action to be taken on the peer
> network).

I've been thinking about ways to handle additional attributes to the
set of things signed,
while also allowing some of those to be added/changed/deleted along the way.

I'll be working on a more formal message (or possibly draft), but
wanted to at least
get the idea in folks' heads, that it isn't impossible, and might even
be workable.

The simplest case is, the extra values get added to the signature
block of the originator,
and nobody modifies those values along the way. (Obviously there are
some attributes
where this is not possible because BGP requires them to change.)

[In this simple case, nothing new is really needed.]

The problem happens the first time you change something, and gets
worse with every change.

The idea I'm working on, is to create a "stack" of attributes that change.
This is very much like the stack in a language like 'C'.

The current values are kept in the normal place in BGP.

The immediately previous value(s) that were replaced (or deleted) are
pushed onto
the top of the stack, as well as some kind of indicator of what
attributes were added,
changed, and deleted, and which entry in the AS_path these correspond to.
(Maybe a NULL indicator as a placeholder if nothing changed...)

Signature validation required a reverse-diff be applied while working
backwards through
the signatures. The set of additional signed attributes gets
reconstituted, and combined
into some canonical form for validating the signature.

It's clunky, for sure, and for attributes that are high-volume and
subject to lots of change
along an AS-path, might bloat things a bit.

On the other hand, it provides data not previously available for path
selection, along with
crypto validation of that data.

Comments on this idea are welcome. It's a work in progress....