[e2e] It's all my fault

[Noel Chiappa]

    > From: "Fergie" <fergdawg at netzero.net>

First, let's all remember to differentiate between "user control of paths"
as an architectural concept, and "source-routing" the current specific
engineering mechanism. Just because there may be specific problems with the
latter, that doesn't necessarily say anything about the former.

And "user-control of paths" doesn't even imply any form of classic source
routes; i.e. large numbers of addressses in the headers.


    > So, if source-routing is a "desired" option, how can I ensure that
    > the "source" is valid?
    > In other words, if it is used for malicious purposes, how can I trace
    > it back to it's "real" source?
    > This is a major issue for me, from a security perspective.

Well, but this is a problem with ordinary datagram traffic, too, right? I
don't recall offhand the specific details of how that particular
source-routing mechanism works, but if it has the original source in some
easily-findable location in the packet header, whatever mechanism works
for normal datagrams should also work with this, no?

If the point is that it's more expensive to find this address in the
header, then we get to a different problem.


Any time the protocol includes a less-used mechanism X, and people
building/buying boxes decide to buy boxes that implement X in a way such
that if a large %-age of traffic suddenly starts using it, the box keels
over, then that's just an attack vector for some pond-scum.

The problem is that any protocol design is going to include less-common,
but more expensive to process, forms of traffic; i.e. control-plane stuff.
Any of them, over-used, becomes an attack vector. You can't simply delete
things from the protocol (or implementation) any time one of them is used
as an attack vector. Doing that leads to all sorts of
operational/diagnostic tools (e.g. ICMP, and Path-MTU-Discovery) suddenly
no longer working. I don't know if anyone has attacked TTL-Expired yet
(causing the target to have to send out bazillions of Time-Expired ICMP
messages), but no doubt someone will at some point, at which point
"traceroute" will stop working. What's next, attacking via trying to open a
BGP connection?

The answer is not to delete less-used stuff, it's to i) make sure we can
track down the pond-scum and lock them in a room and throw the room away
(which is, alas, not under our control), and ii) build boxes that respond
reasonably to these sorts of attacks.

That means that they have to a) rate-limit things so that they can't sink
the box, and b) include mechanisms so that when one of those things starts
happening, we can track down the source(s) easily, and turn them off.

	Noel