Re: questions on draft-touch-ipsec-vpn

[Joe Touch <touch@ISI.EDU>]

Paul Koning wrote:
 > 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.

Which is why we thought that IIPtran was a better way to describe the 
solution. #2 _requires_ describing what could (and/or should) be 
considered implementation details.

Note, however, that some so-called implementation details have 
implications in functionality. RFC2401 describes the use of different 
SPDs for each interface, equivalent to using interface as an additional 
index into the SPD. Depending on your perspective, this is either an 
implementation detail or a functionality requirement of the protocol.

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

It is exactly in the details where they differ that cause problems for 
dynamic routing, as described in our draft. They are not precisely 
functionally equivalent, in that the order of SPD indexing and 
forwarding lookup differ, notably for tunnels that exit the same 
physical interface.

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

Talking with other implementations requires equivalent packets on the 
wire, and any endpoint coordination. IIPtran sends the same resulting 
packets, and does not affect IPsec endpoint coordination (SPD entries). 
It does affect IKE and other IPsec setup protocols, as described in our 
draft.

We are currently determining how best to proceed with these 
recommendations in the context of the RFC2401-bis update. We (Lars and 
I, and a few others) feel that using IIPtran as a replacement for tunnel 
mode simplifies IPsec and results in increased capability, by removing 
the redundent description of tunneling as a special case for IPsec. 
Others feel that IIPtran can be included as an 'equivalent variant' of 
tunnel mode. In either case, that debate will occur in the context of 
RFC2401-bis. Our draft is intended to describe the change, not to 
mandate it.