Re: [sidr] Route Leaks and BGP Security

[Brian Dickson <[e-mail]>]

On Tue, Nov 22, 2011 at 4:12 PM, Christopher Morrow
<[e-mail]> wrote:
> On Tue, Nov 22, 2011 at 7:35 AM, Russ White <[e-mail]> 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....

Brian