>If the router is mis-configured, whether intentionally or not, it won't
be intentionally sending bad information to the peer router for the
simple reason that no vendor is going to implement the "please
send incorrect information" configuration option.
There are plenty of ways to say, not about rsvp in particular but about
configuration in general, "reset the configuration to send X rather
than Y". That is what misconfiguration is.
Surely the number of times prefixes have been mis-originated in the
Internet is enough to demonstrate that sending bad information to a
peer happens everywhere and often?
Furthermore, can we say that root access to a router would not permit
download of not a full new operating system but a small piece of code,
that will counter the effect of the real routing code? I don't think so.
Let me know if that's wrong.
I don't think that it is possible to design a protocol that *both*
(i) Deals with the hacker produced Byzantine software case; and
also (ii) Works well enough in a normal network that anyone would
ever use it.
No one is asking for the design of a protocol robust against Byzantine
behavior, that's hard. People are being asked to analyze their protocol
that they are expert in to see how much damage byzantine behavior could
do. If byzantine behavior turns out to be no big deal, you're done.
If byzantine behavior tunrs out to wreak havoc on a global scale, well,
then you need to worry about how to prevent misconfiguration or software
faults or subversion through other means.
Note: turns out ccamp is subscribers-only. So the ccamp people haven't
seen any messages I've sent. I've just subscribed, so this message may
get through. I'll resend everything the ccamp list misses.
--Sandy