Let me try phrasing the issue differently. I may still be missing the
point, from all sides.
I believe that what is actually wanted is primarily:
o To prevent any advertiser from sending an advertisement that would
cause other properly behaving parties to send traffic iin a way that
they are not "entitled" to cause
As secondary matter
o We want such attempted subversion to be visible at more than one hop
because experience tells us that not everyone deploys the tools
properly, and thus we can not count on every honest player doing their
job well.
(Colluding subverting players is addressed only to the degree that it is
covered by what we are after, not explicitly. We are staying away from
Byzantine Generals.)
The above probably needs more wordsmithing, but is a problem statement
that does not assume that packets follow their advertisements, nor that
any party can control what any other party actually does. It also
avoids getting into the question of the accuracy of the reflection of
the path of the advertisement, the AS path in the advertisement, and the
actual packet flow. Instead, it focuses on an attack we are trying to
prevent.
I believe that the primary solutions on the table are all solutions that
can be reasonably considered to address the problem as stated. (I.e. I
am not trying to change the solutions pace, only to clarify the problem
space.)
Apologies if I am still completely confused.
Yours,
Joel
On 2/25/2011 9:14 AM, John Scudder wrote:
On Feb 25, 2011, at 4:10 PM, Russ White wrote:
Can you explain the difference in some other way that doesn't mix the
two ideas?
Since after reading your message carefully three times I don't understand your
question, I'm unable to answer it. Sorry.
You're apparently trying to separate the idea of proving an update
traveled a specific path from the idea of using this information to
actually filter or determine any other policy. I don't see how you can
separate the two --can you explain how you can?
If you can establish the former (that the route did travel across the path it
said it did), that outcome can be used as input to policy. This is exactly
analogous to draft-ietf-sidr-pfx-validate-01, BTW.
Divide, conquer. A commonly used trick in computing. :-)
--John
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
