[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 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 agree that we 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.
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.
...
> 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.
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.