On Wed, Mar 21, 2012 at 12:45 PM, Christopher Morrow <
[email protected]> wrote:

> On Wed, Mar 21, 2012 at 12:36 PM, Brian Dickson
>
> > I will claim it is possible to protect attributes which change, and that
> > discussion on which
> > attributes should be signed, should be open for discussion.
>
> curious how that'd be done, got examples?
>
> -chris
>

Gladly.

While it may not be terribly efficient (but then, information theory says
"duh"), here goes:

It basically uses the same kind of methods that "rsync" uses for arbitrary
binary data, or rcs/cvs/sccs use for source code.

It requires a new attribute type to stuff the data. It would be a block of
things, each which corresponds to one AS-hop.

Each "hop" would have two counts, for the two elements for that hop.

The two elements would be as follows.
The first is things that were deleted or changed. This can be a block of
attribute types and values, all the ones that were deleted or changed, in
there entirety.
The second is things that were added. Also in their entirety. (These would
be attributes that did not exist when the update was received.)

Validation would work backwards, by validating the last hop based on
current values and signature.
Then, working back one hop at a time, remove the things added, add or
change the things deleted or changed. Validate with this new set of values.
Lather, rinse, repeat.

For updates where little or nothing changed, the overhead (in processing
and space) is negligible.
For updates where a lot changes once, the overhead is slightly more.
Only where every hop involves lots of change, does stuff start to become
bloated. However, given the average number of AS-hops, and the proportion
of those where values change, I think this is manageable.

Additionally, lots of prefix/path combos will share attributes, and likely
also share attribute "stacks", so in-router storage isn't terribly bloated.

Ugly, but manageable, IMHO.

Brian
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr

Reply via email to