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

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





Stephen Kent wrote:

> 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

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