[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.
Tunnel mode was defined for IPsec because it has processing (vs.
syntax) implications that are different than using IP-in-IP tunneling
in conjunction with transport mode, as has been mentioned on this
list many times in the past.
Steve
References: