Ross, as I've said before I definitely think analyzing the impact of
malicious software--especially at domain boundaries etc-- is an
important part of what we do.
let me give you some examples of things that we don't care about:
* Malicious software could choose a different preferred route for some
packet.
* Malicious software could advertize a prefix permitted by
configuration and cause other routers to send traffic for that
prefix to the malicious router.
* Malicious software could consume CPU or create a denial of service on
other routers.
And some malicious attacks I think we care about:
* Malicious software could subvert configuration on other routers.
For example I'd consider it a BGP protocol bug if I set up filters
to constrain what prefixes a BGP speaker was allowed to announce to
me and that speaker being malicious could get around my filters.
* Where malicious software on one side of a customer domain could violate
that domain boundary. For example, in a 2547-style VPN, where PE does the
VPN encapsulation, malicious CE should not be able to violate traffic
isolation.
The reason the assertions being made about the RSVP restart mechanism
don't seem to ring true to those of us in the security community is
that local state is often more trusted than network state and that
there is an inversion of trust direction. I think we're going to be
very uncomfortable letting this spec go forward without at leat
understanding what the new attacks are created by this spec. I'm
particularly uncomfortable with potential interactions between the
restart mechanism and future extensions to objects in the path
message.