Re: [RPSEC] BGP Security Requirements v08

At 9:40 AM -0400 7/19/07, Russ White wrote:
>...
>
>At least that change the processing rules for the AS Path, or change the
>AS Path itself. If we think of the AS Path as being constant end to end,
>and plan security based on that thinking, then we must think in
>exceptions to the rule set for each possible modification to the AS
>Path, and as people think of new ways to modify the AS Path, we have to
>think of new exceptions to the rules.

Of course the path is not an e-2-e constant, since it is legitimate 
for it to change, in certain ways, as the path info passes through 
each AS. However, I don't think we believe that all possible changes 
to the path are legitimate at each hop. That suggests that it may be 
possible to express what the allowed transformations are and develop 
mechanisms that allow the recipient of the path info to verify 
whether the received path is legitimate relative to the 
transformations that have been applied.

>It seems, to me, that it's easier just not to think of the AS Path as
>anything more, or less, than an attribute among attributes, all mutable
>for various reasons. This allows us to stop thinking in terms of an
>"end-to-end" advertisement, and see BGP for what it really is: A
>distributed database system in which each device along the way might
>change the data in subtle or not-so-subtle ways, and for valid reasons.

see comments above that apply here too.

>The question then changes from: "Who has touched this," to: "Is the data
>valid?" Of course, then you have to decide what "valid" means, but,
>there we digress into a lot of other conversations we've already had,
>and I don't want to repeat. :-)

and yet you are repeating them :-(

>Going back to the original question:
>
>The basic point, to me, is that the validity of the data is not a
>"true/false" situation.

I don't think we have a string basis to believe that this is 
undecidable. The examples you cite merely show that it's not trivial, 
but then routing is not trivial even absent security considerations.

>Hence, it's possible that passing information
>through or around a non-implementing AS, whichever way you want to put
>it, has potential benefit. There's no way to know that until you
>actually look at the way the proposed mechanism works, though.

I agree that it MAY have benefit (i.e., potential benefit) but since 
it also might be harmful, or might not be necessary, it seems 
inappropriate to mandate support for it in our requirements.

Steve

_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec