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

[Joe Touch <touch@ISI.EDU>]

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