[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Fwd: IPsec issue #50 -- tunnel vs transport mode at link layer
At 14:21 -0700 9/4/03, Joe Touch wrote:
>Stephen Kent wrote:
>
>>>>
>>>>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
>>
>>
>>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
>
>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