In message <200012190608(_dot_)BAA02165(_at_)tsx-prime(_dot_)MIT(_dot_)EDU>,
"Theodore Y. Ts'o" writes
:
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.
While I wouldn't go quite that far, I've been saying for years that the
IP header doesn't need any authentication if we have IPsec. To me, a
host's identity is represented by its certificate (I'm speaking a bit
loosely here); its IP address is merely the way that packets reach it.
I could post my analysis of this again (it was originally written
during the Stockholm IETF, in a note explaining why I thought AH was
useless), but I don't think that this is the place for it.
--Steve Bellovin