[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