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

[Stephen Kent <kent@bbn.com>]

At 11:31 -0700 9/4/03, Joe Touch wrote:
>Karen Seo wrote:
>
>>>X-Sender: kseo@po2.bbn.com
>>>Date: Tue, 26 Aug 2003 14:39:00 -0400
>>>To: ipsec@lists.tislabs.com
>>>From: Karen Seo <kseo@bbn.com>
>>>Subject: IPsec issue #50 -- tunnel vs transport mode at link layer
>>>Cc: "Angelos D. Keromytis" <angelos@cs.columbia.edu>, kivinen@ssh.fi,
>>>    kseo@bbn.com
>>>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.
>...
>
>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