[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RFC 2401 section 5.2.1
Henry Spencer wrote:
>
> On Fri, 24 Nov 2000, Francis Dupont wrote:
> > 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.
> >
> > => it is...
>
> No. Not by RFC 2401, it's not. Please distinguish carefully between the
> way you think the protocols should work, and the way they are currently
> specified to work. Don't be misled by RFC 2401 saying that tunnel mode is
> "essentially" a tunnel within transport mode; that is a useful explanation
> but it is not literally true, not when you examine the details.
The differences are outlined in our ID, draft-touch-ipsec-vpn-00.txt.
On outbound processing, the difference is whether the inner or outer
IP address determines the SPD. The advantage to tunnel-in-transport
(IIPtran, in our doc) is that it uses the outer IP address to determine
SPD, thus enabling dynamic routing without the complication of
sychronizing key database updates and routing table updates.
On inbound processing, the two are (or at least should be) identical.
(i.e., either match inner and outer addrs in one step if tunnelmode,
or match outer, decapsulate via IPSEC, and reverify - via an additional
rule - the inner header on subsequent IP processing)
On the wire, they are indistinguishible, for a given key. Which means
that the inbound system in particular shouldn't assume that protocol
type 4 inside IPSEC implies tunnel mode; it definitely must check the
SPD to verify whether IPSEC or some other (non-IPSEC) code should
be doing the decapsulation.
Joe
Follow-Ups:
References: