Date: Mon, 18 Dec 2000 14:45:08 -0800 (PST)
From: Mike Fisk <mfisk(_at_)lanl(_dot_)gov>
Gateways that surreptitiously modify packets can break ANY end-to-end
protocol no matter what layer it's at. Assume that we sacrifice IP
addresses as not necessarily end-to-end. Fine, there are gateways that
need to modify your TCP ports too. Okay, sacrifice make it so ports
aren't covered by e2e assumptions like IPsec. Fine, there are gateways
that do ACK spoofing. Okay, sacrifice all header data and assume that
only payload is e2e. Whoops, even the payload has to be modified by some
gateways. The hypothesis that you can have these gateways and have
any part of the packet be guaranteed to be e2e is false.
Given our inability to rule out the need for gateways that change IP
addresses (or other routing headers), this leads to the conclusion that
applications shouldn't use any header field (IP address, port, etc.) for
authentication.
OK, in that case, we've completely thrown out the end-to-end principle,
and completely wiped out any possibility of IPSEC. If that's the world
we live in, where any part of the IP header can be subject to attack by
an intermediate attacker.... err, "service provider", then you shouldn't
be using IPSEC. You should be using TLS instead.
It of course also means that no part of the IP header can be
authenticated in anyway, since it's of course all subject to change by
such gateways.
Is that really the architecture that we should be building in the
Internet. I know some extremists would say yes, absolutely, and others
would be say that this would be a horror. The problem though is that
we're designing that assume (and depend upon) both architectural
philosophies. Is it any wonder that we're having disconnects?
- Ted