On Tue, Nov 22, 2011 at 4:12 PM, Christopher Morrow <[email protected]> wrote: > On Tue, Nov 22, 2011 at 7:35 AM, Russ White <[email protected]> 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 _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
