[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.