[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RFC 2401 section 5.2.1
Henry Spencer wrote:
>
> On Wed, 22 Nov 2000 itojun@iijlab.net wrote:
> > >Many of the death-to-AH enthusiasts also favoring killing transport mode
> > >and doing everything with tunnel mode...
> >
> > 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.)
There is a contrary view - that transport mode after IP encapsulation
does everything tunnel mode does (provided transport mode is implemented
properly, e.g., that there are checks available after decryption, in
the subsequent passes of IP processing, as required by 2401). See our
ID (which is probably recently expired, but is also probably still available:
draft-touch-ipsec-vpn)
The argument for the contrary view is that tunneling - esp that using
protocol type 4 - is a separate protocol technique, and it would be useful
to extract out of IPSEC.
> "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
Agreed - and if you're going to get rid of one of them, things get much
simpler to omit tunnel mode.
> 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.)
There are differences between 2401's definition of encapsulation
(particularly the DF bit), but it is not clear they should remain.
(either 2401 should prohibit clearing the DF bit on the outer header,
or 2003 should permit it. there is no clear reason to have dissenting
positions).
I'm not clear that _any_ IPIP tunnel over transport
mode wouldn't have subsequent implications on IPSEC
checks on the interior packet headers.
Joe
Follow-Ups:
References: