[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RFC 2401 section 5.2.1
>> do we want to use tunnel mode on non-VPN ipsec exchanges?
>> I don't think so.
>Why not? It can do everything transport mode does. (In particular, it is
>perfectly capable of working host-to-host.)
>"Recommendation 1: *Eliminate transport mode*. ...we do not know why
>IPsec has two modes... The extra cost of a second mode (in terms of added
>complexity and resulting loss of security) is huge..." -- Ferguson & Schneier
first of all, chews MTU. tunnel-mode-just-for-avoiding-transport-mode
does not seem to be the same as transport mode for me.
>It would be sensible to retain both if transport mode was the fundamental
>IPsec mode and tunnel mode was *just* IPIP tunneling over a transport-mode
>connection. But it's not. (If it were, tunnel mode could be explained in
>a single footnote in RFC 2401, rather than having implications everywhere.)
i still do not get why RFC2401 includes tunnel mode. I believe
this was introduced for single reason: to make it easier to negotiate
tunnel setup as well as IPsec setup, with IKE. there are enough number
of prior art for tunnelling available before 2401 (at least 7
specifications, before and after 2401, use IP protocol #4.
4 specifications use IP protocol #41).
if an implementation A handles IPsec tunnel mode as transport
mode with tunnels, does it break 2401 conformance? I understand
that if the peer i too picky about header field the peer will drop
the packet. also I understand we need some trick in IKE code, to
setup tunnels AND IPsec transport-mode SAs as necessary.
itojun
Follow-Ups:
References: