[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ICMP Security Failures
% I'd like to expunge use of the terms "transport-mode" and
% "tunnel-mode" from IPSEC documents. Not because the modes they
% describe aren't useful, but because I really consider them completely
% orthogonal to the security mechanisms IPSEC provides.
%
% "Tunnel mode" simply implies that a host has the ability to tunnel and
% detunnel packets, irrespective of whether that host also implements
% IPSEC (AH and ESP). It simply means that the host implements IP
% Protocol No. 4. If the host also happens to implement IP Protocols
% Nos. 50 and 51 (IP Security), it's free to combine all three in any
% fashion it chooses. But the mechanisms of IP security are completely
% independent of whether the payload is a UDP or TCP segment or another
% IP datagram.
The reason that both modes continue to need to be described is that
elsewise implementers will build support for only one or another of
the modes in an implementation rather than supporting both modes.
Both modes need to be widely available to applications. The two
modes are defined so that we can then mandate that both are implemented.
If they are not defined, we could not mandate that both are implemented
and interoperability and portability of secured applications would decrease.
Implementing support for IP tunnels does not imply that the same implementation
would automatically support secure IP tunnels if ESP/AH were also implemented
on that system (implementer might only permit ESP/AH processing to be called
prior to IP processing -- which might not be smart but would be conforming
under your proposal).
If you don't like the terms, please feel free to propose clearer terms.
Alternately, you perhaps can find a better way to specify things such that
it is very clear that an implementation must support both styles of use for
ESP.
Ran
rja@cisco.com