Re: questions on draft-touch-ipsec-vpn

[Paul Koning <pkoning@equallogic.com>]

Excerpt of message (sent 2 April 2002) by Joe Touch:
> There are two solutions:
> 
> 1. use IIPtran
> 
> 2. use a new virtual device for each new IPsec tunnel
> i.e., such that the routing table sends packets to that device name
> 
> These two solutions are equivalent in function, but different in 
> complexity. #2 implies that all SPDs have either one or more transport 
> mode SA, or exactly one tunnel mode SA (and no transport mode SAs). This 
> ends up treating tunnel mode as a special case w.r.t. association with 
> devices, for an indirect (routing) reason.

That sure sounds like an implementation detail that's an artifact of a
particular implementation choice.  Virtual devices and routing tables
don't exist in the RFCs, for good reasons -- they are an internal
matter.  You can use them if you like, or use something else if that
is easier.  I built an implementation that does not require a virtual
device per tunnel -- that approach never came up as a possibility
during the design.

Tunnel mode is functionally equivalent to transport mode applied to an
IP-IP tunnel, and in fact is inspired by that construct even if it's
not identical in all details.  

If you want to talk with other implementations that happen to have
IP-IP tunneling implemented for some reason, and they also include
transport mode, then clearly you can use that stack.  Of course, a lot
of security gateways don't care to implement such a stack.  On the
other hand, if you mean to mandate such a combination as a
replacement, or an additional requirement, in place of tunnel mode, I
have to object.

     paul