Subject: Fwd: IPsec issue #50 -- tunnel vs transport mode at link layer

From: Karen Seo <[email-masked]>
Date: Tue, 2 Sep 2003 18:43:57 -0400

>X-Sender: [email-masked]
>Date: Tue, 26 Aug 2003 14:39:00 -0400
>To: [email-masked]
>From: Karen Seo <[email-masked]>
>Subject: IPsec issue #50 -- tunnel vs transport mode at link layer
>Cc: "Angelos D. Keromytis" <[email-masked]>, [email-masked],
>    [email-masked]
>X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
>Status:  
>
>Folks,
>
>Here's a description and proposed approach for:
>
>IPsec Issue #:	50
>
>Title:		Tunnel vs transport mode for link security
>
>Description:	At present, security gateways must use tunnel mode
>		between two security gateways (SGs) or between a security
>		gateway and a host.  This is because in a number of
>		circumstances, tunnel mode is necessary to enable one
>		to address an IP packet to a specific, intermediate
>		IPsec processing point along the path to the eventual
>		destination.  This can't be done if the header contains
>		only the final destination address. However, for
>		point-to-point security, the goal is typically
>		confidentiality and/or integrity and authenticity
>		between two systems (SGs) which are often
>		intermediate between the source and destination and
>		where the next protocol is not transport or IP, e.g.,
>		GRE.  In these situations, use of transport mode is
>		reasonable and in fact, that is what is already being
>		done.  Therefore, 2401bis should allow this usage.
>
>Proposed approach
>
>	1. The section describing transport and tunnel modes should
>	be amended to allow transport mode to be used by a security
>	gateway for "link" security.  There should also be a
>	warning about the reduction in access control functionality
>	in this situation.  Text along the lines of the following
>	should be added:
>
>	"In the case where link security is desired between
>	two intermediate systems (security gateways) along a path,
>	transport mode may be used instead of tunnel mode.  Note
>	that the access control functions that are an important part
>	of IPsec are significantly constrained in this context.
>	So this way of using transport mode should be evaluated carefully
>	before being employed."
>
>Thank you,
>Karen

---

From: Stephen Kent <[email-masked]>
Date: Thu, 4 Sep 2003 16:29:54 -0400

At 11:31 -0700 9/4/03, Joe Touch wrote:
>Karen Seo wrote:
>>>Status: Folks,
>...
>Along these lines, this use of transport mode can be constrained further
>if the internal packet is IP, rather than UDP or TCP, esp. since the
>transport mode association cannot verify parts of the 'transport' header
>if it is not UDP or TCP. The current spec assumes that the 'transport'
>layer is UDP or TCP; are there any plans (perhaps not in this revision,
>but in the future) to augment these with, e.g., any protocol that may
>occur inside IP?
>
>(i.e., anything that is inside IP is a 'transport' protocol to IP, 
>including IP, UDP, TCP, SCTP, etc.)
>
>Joe

Joe,

We'll avoid using the term "transport" to refer to the next layer 
header as we rewrite the text, so as to make it clear that IP, ICMP, 
etc.are OK choices for a next layer.  If transport mode is used with 
IP as the next layer, then nothing special will happen re processing, 
but the SPD entry will have to indicate that the port fields are not 
to be used as selectors, i.e., they should be designated as OPAQUE. 
This is already part of 2401, in general, to accommodate protocols 
that don't have port fields, and to accommodate situations where the 
port fields are not available, e.g., when ESP or AH is the next 
protocol or when fragments are allowed to traverse a tunnel mode SA.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 4 Sep 2003 16:44:47 -0400

>>header as we rewrite the text, so as to make it clear that IP, 
>>ICMP, etc.are OK choices for a next layer.  If transport mode is 
>>used with IP as the next layer, then nothing special will happen re 
>>processing, but the SPD entry will have to indicate that the port 
>>fields are not to be used as selectors, i.e., they should be 
>>designated as OPAQUE. This is already part of 2401, in general, to 
>>accommodate protocols that don't have port fields, and to 
>>accommodate situations where the port fields are not available, 
>>e.g., when ESP or AH is the next protocol or when fragments are 
>>allowed to traverse a tunnel mode SA.
>>
>>Steve
>
>AOK - it would probably be useful in the future to consider other 
>selection criteria, akin to port numbers for TCP/UDP, that can be 
>used to match against the inner header as well, though I expect 
>that's too complex to consider at this point for 2401bis.
>
>Joe

Joe,

We do not anticipate a need to look beyond the first header in this 
case.  I think that contexts such as virtual nets really want to use 
IPsec to secure links between nodes, and in that case it probably 
makes sense to just apply the access controls to the outer header.

Steve

---

From: Joe Touch <[email-masked]>
Date: Thu, 04 Sep 2003 13:37:02 -0700

Stephen Kent wrote:

> We'll avoid using the term "transport" to refer to the next layer header 
> as we rewrite the text, so as to make it clear that IP, ICMP, etc.are OK 
> choices for a next layer.  If transport mode is used with IP as the next 
> layer, then nothing special will happen re processing, but the SPD entry 
> will have to indicate that the port fields are not to be used as 
> selectors, i.e., they should be designated as OPAQUE. This is already 
> part of 2401, in general, to accommodate protocols that don't have port 
> fields, and to accommodate situations where the port fields are not 
> available, e.g., when ESP or AH is the next protocol or when fragments 
> are allowed to traverse a tunnel mode SA.
> 
> Steve

AOK - it would probably be useful in the future to consider other 
selection criteria, akin to port numbers for TCP/UDP, that can be used 
to match against the inner header as well, though I expect that's too 
complex to consider at this point for 2401bis.

Joe

---

From: Stephen Kent <[email-masked]>
Date: Thu, 4 Sep 2003 17:41:42 -0400

At 14:21 -0700 9/4/03, Joe Touch wrote:
>>>>used with IP as the next layer, then nothing special will happen 
>>>>re processing, but the SPD entry will have to indicate that the 
>>>>port fields are not to be used as selectors, i.e., they should be 
>>>>designated as OPAQUE. This is already part of 2401, in general, 
>>>>to accommodate protocols that don't have port fields, and to 
>>case.  I think that contexts such as virtual nets really want to 
>>use IPsec to secure links between nodes, and in that case it 
>>probably makes sense to just apply the access controls to the outer 
>>header.
>>
>>Steve
>
>As we've discussed in our ID, in the context of virtual nets it is 
>more useful to use IPsec transport mode with IP in IP encapsulation. 
>The access controls need to be on the inner header to provide the 
>firewall capability of IPsec, though we do feel that firewalling is 
>a separate function that might be considered a separate service 
>eventually.
>
>Joe

Sorry, Joe but I must disagree.

I reread your ID last week.  The virtual nets context needs to use 
IP-in-IP encapsulation to do its job, and thus it makes sense to 
perform that encapsulation prior to invoking IPsec, and to employ 
access controls only to the outer header. In a VN context, the 
end-to-end access control probably ought not be performed by IPsec 
applied to links. In many cases it might not be possible to craft 
meaningful SPD entries given that traffic could flow through nodes, 
rather than originating "behind" nodes.

In contrast, other, typical IPsec users do not intrinsically need a 
tunnel for communication, but rather the use of IPsec imposes the 
need for a tunnel, if one is needed at all. For example, two end 
systems communicating with one another could use transport mode or 
tunnel mode, but the latter choice would be a result of a security 
policy decision, not a basic communication service. When L2TP uses 
IPsec, it does so in transport mode as a link security measure; the 
GRE tunnel that L2TP employs is one that it already used prior to 
invoking IPsec. The common VPN context uses IPsec in tunnel mode 
because it must direct the traffic to a specific IPsec SG to ensure 
decryption can take place, another example where it is the use of 
IPsec that requires the tunneling. Here the need is to apply access 
controls to the inner packets, because what is being protected is 
communication to the systems behind the SG, not just a secure link to 
the SG. Since these configurations typically do not involve transit 
traffic through the VPN SGs as intermediaries, it is feasible to 
craft useful SPD entries. The PPVPN context is like the VPN context, 
except that the placement of the PPVPN devices implies more 
complexity re demuxing.

I think that the model we should be using, which is less restrictive 
than what 2401 says, is that a user of IPsec can perform tunneling 
before invoking IPsec, if the application context warrants, and in 
that case IPsec can be used in transport mode and will enforce access 
controls based only on the external header. consistent with the 
provision of link security. If the user configures IPsec to perform 
the tunneling, then the users is indicating explicitly that the 
desired service calls for access control to be applied to the packet 
prior to the tunneling, and that the tunneling is needed for security 
purposes, but not intrinsically for the application context.

Steve

---

From: Joe Touch <[email-masked]>
Date: Thu, 04 Sep 2003 14:21:00 -0700

Stephen Kent wrote:

> IPsec to secure links between nodes, and in that case it probably makes 
> sense to just apply the access controls to the outer header.
> 
> Steve

As we've discussed in our ID, in the context of virtual nets it is more 
useful to use IPsec transport mode with IP in IP encapsulation. The 
access controls need to be on the inner header to provide the firewall 
capability of IPsec, though we do feel that firewalling is a separate 
function that might be considered a separate service eventually.

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 04 Sep 2003 11:31:53 -0700

...

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 22 Sep 2003 11:40:06 -0700

Stephen Kent wrote:

 >> firewall capability of IPsec, though we do feel that firewalling is a
 >> separate function that might be considered a separate service 
eventually.
 > Sorry, Joe but I must disagree.

I agree that we disagree. ;-)

 > IP-in-IP encapsulation to do its job, and thus it makes sense to perform
 > that encapsulation prior to invoking IPsec, and to employ access
 > controls only to the outer header. In a VN context, the end-to-end
 > access control probably ought not be performed by IPsec applied to
 > links. In many cases it might not be possible to craft meaningful SPD
 > entries given that traffic could flow through nodes, rather than
 > originating "behind" nodes.
 >
 > tunnel for communication, but rather the use of IPsec imposes the need
 > for a tunnel, if one is needed at all. For example, two end systems
 > communicating with one another could use transport mode or tunnel mode,
 > but the latter choice would be a result of a security policy decision,
 > not a basic communication service.

Providing an end-to-end (gateway to gateway) service for securing 
traffic between two enterprises would be a feature of an application 
that might use IPsec, as well as other services (e.g., firewalls, 
tunnels) and protocols (IKE, a tunnel configuration protocol, a firewall 
configuration protocol), to provide a consistent and coherent capability.

I do not agree that this necessitates direct support for an integrated 
solution inside IPsec, any more than supporting VNs inside IPsec does.

...
 > before invoking IPsec, if the application context warrants, and in that
 > case IPsec can be used in transport mode and will enforce access
 > provision of link security.

Transport mode checks the internal transport header. When a tunneled 
packet uses transport mode, the inner packet is an IP header, and should 
be checked as well.

 > If the user configures IPsec to perform the
 > tunneling, then the users is indicating explicitly that the desired
 > service calls for access control to be applied to the packet prior to
 > the tunneling, and that the tunneling is needed for security purposes,
 > but not intrinsically for the application context.

If the user configures IPsec to perform transport mode, then the user is 
indicating a desire (presumably) to restrict the transport-level header. 
To the extent that IPsec should be checking these headers at all (IMO 
that's a firewall issue, and should be outside IPsec), it should check 
IP as much as it should check TCP or UDP.

---

From: Stephen Kent <[email-masked]>
Date: Tue, 23 Sep 2003 11:33:38 -0400

Joe,

>tunnels) and protocols (IKE, a tunnel configuration protocol, a 
>firewall configuration protocol), to provide a consistent and 
>coherent capability.
>
>I do not agree that this necessitates direct support for an 
>integrated solution inside IPsec, any more than supporting VNs 
>inside IPsec does.

We're not converging on this disagreement.  I'll not pursue it anymore.

>packet uses transport mode, the inner packet is an IP header, and 
>should be checked as well.

For outbound traffic there is no difference between the header 
examined by transport or tunnel mode in IPsec. But for inbound 
traffic, transport and tunnel mode examine different headers. That is 
the essence of the difference between the two modes. Please do not 
redefine what transport mode does today to match what you want it to 
do in the future.

Steve

---

From: Joe Touch <[email-masked]>
Date: Tue, 23 Sep 2003 08:50:17 -0700

Stephen Kent wrote:

> For outbound traffic there is no difference between the header examined 
> by transport or tunnel mode in IPsec. But for inbound traffic, transport 
> and tunnel mode examine different headers. That is the essence of the 
> difference between the two modes. Please do not redefine what transport 
> mode does today to match what you want it to do in the future.

_Tunneling_ (encaps/decaps) is the "essence of the difference".

Which headers are checked, or whether such is part of IPsec or a 
separate firewall service, or whether such is applied consistently 
within IPsec, is certainly an artifact of what is done today.

Redefining what is done today is the "essence of the difference" that 
warrants revision of 2401.

Transport mode ignores all but two (coming to be three) specific 
Internet transport protocols. It will be incomplete until it handles the 
remainder.

Joe

---

From: Stephen Kent <[email-masked]>
Date: Tue, 23 Sep 2003 12:05:55 -0400

At 8:50 -0700 9/23/03, Joe Touch wrote:
>>>Transport mode checks the internal transport header. When a 
>>>tunneled packet uses transport mode, the inner packet is an IP 
>>>header, and should be checked as well.
>>
>>traffic, transport and tunnel mode examine different headers. That 
>>is the essence of the difference between the two modes. Please do 
>>not redefine what transport mode does today to match what you want 
>>it to do in the future.
>
>Redefining what is done today is the "essence of the difference" 
>that warrants revision of 2401.
>
>Internet transport protocols. It will be incomplete until it handles 
>the remainder.
>
>Joe

Joe,

I'm afraid you decided a while ago that tunnel mode does match your 
model of how IPsec should work. The vast majority of folks who have 
implemented IPsec, do not seem to share this view. I have stated how 
we're changing the spec so that you can perform IP-in-IP tunneling 
legitimately claim conformance. However, I am not comfortable 
changing the fundamental notion of tunnel and transport mode to 
accommodate your model, and thus break all the extant implementations 
that have complied with 2401.

Unless I am directed otherwise by the WG chairs, or the Security ADs, 
I will not continue this discussion.

Steve