[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: RFC 2401 section 5.2.1



> -----Original Message-----
> From: Joseph D. Harwood

> Not quite identical.  After IPsec processing, the received packet's
> selectors are checked against the SPD to make sure all of the
> appropriate
> processing has been performed.  In Tunnel mode, these
> selectors are from the
> inner (encapsulated) header, in IPIP + IPsec transport these
> selectors are
> from the outer header.

But, the claim was that the sending side can create the tunnel mode packet
just by adding the tunnel layer and then applying the standard transport
mode processing to packet. Thus, tunnel mode is identical to IPIP +
Transport mode. This is what I basicly do, and have not found any
interoperatibility problems due to this.

On receive side, assuming you implement the "tunnel mode", you need to have
the extra logic within the IPSEC processing that "uwraps" the tunnel that
follows ESP/AH. First you do AH/ESP processing is plain transport mode, and
then decide whether detunneling operation is required. The selectors are
matched against the addresses after this processing (with additional check,
that if the policy specified a tunnel, the outer src address must also match
the tunnel address).

[All this talk about inner/outer addresses in RFC-2401, although correct,
makes it hard to read. A processing oriented description, like above would
be much easily understood.]

I don't understand the claims that the presense of the transport mode is
complexity. The transport mode is already there and required anyway, and
tunnel mode just adds an extra "layer" to the IPSEC processing.



Follow-Ups: References: