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

RE: RFC 2401 section 5.2.1

Hi,
For the past few days, I have seen lots of discussion on the relevance of
transport and tunnel modes. Although I am not working on these protocols for
a very long time, but I see no reason for the relevance of transport mode
over the tunnel mode. The reason being:

1) Ref : RFC 2401, Section 4.1  Definition and scope.
  It says
	 "In IPv4, a transport mode security protocol header
  	 appears immediately after the IP header and any options, and before
  	 any higher layer protocols (e.g., TCP or UDP)".

	i.e.  In transport mode, the packet will look like [IP][ESP][HLP].
Here I have taken ESP as an example.
Now we see that in this case, ESP will encrypt *only* [HLP] and thus IP is
not protected i.e. encrypted. Even if we select authentication in ESP, the
IP header is not protected.

  About Tunnel Mode, RFC 2401 says,
	"The security protocol header appears after the outer IP header, and
   before the inner IP header".

 	i.e. In Tunnel Mode, the packet will look like [outer
IP][ESP][InnerIP][HLP].
Now we see that ESP can encrypt the inner IP packet thus maintaining its
confidentiality. If authentication in ESP is used, the inner IP header is
fully authenticated also. And I think a security protocol should work in
this manner.

So, having this argument, I see no reason for Transport mode being more
relevant than the Tunnel Mode.
Any suggestion/correction in this regard is most welcome.


2) Now taking up the argument that transport mode with tunneling is same as
Tunnel mode in IPSec.
	The tunneled transport mode protected packet will look like :
			[OuterIP][InnerIP][ESP][HLP].
	If my first point is correct, then we can see the extent of coverage in
this case on the same lines as before and compare it with the Tunnel mode
protected packet, which will look like,
			[OuterIP][ESP][InnerIP][HLP].

	Again on the same arguments, Tunnel mode will provide better protection
compared to Transport mode.

Any suggestions or corrections to my arguments are most welcome.

Regards,
Awan.


> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Markku Savela
> Sent: Wednesday, November 22, 2000 2:24 PM
> To: ipsec@lists.tislabs.com
> Subject: 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: