[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