Re: questions on draft-touch-ipsec-vpn

[Joe Touch <touch@ISI.EDU>]

Mark Duffy wrote:
 > At 10:13 PM 4/2/02 -0800, Joe Touch wrote:
 > 
 >>Mark Duffy wrote:
 >>
 >>>Hi, I have a few questions for the authors of draft-touch-ipsec-vpn-03.txt.
 >>>
 >>>The draft addresses the use of IPsec to secure the virtual links of an
 >>>overlay network.  In this application, the goal is to make forwarding
 >>>decisions based on evaluating the packet destination address against a
 >>>forwarding table, rather than by evaluating a set of packet selectors
 >>>against an SPD.  I.e. the policy aspect of IPsec is not desired in this
 >>>application and must somehow be gotten around.
 >>>
 >>>The draft describes using IP-in-IP tunnelling and securing the result with
 >>>transport mode IPsec (IIPtran).  Why choose this approach over simply
 >>>negotiating tunnel mode IPsec with wild-card selectors (i.e. 0.0.0.0/0) and
 >>>then at a higher level using the routing decision to choose which tunnel to
 >>>use?
 >>
 >>This was addressed in a presentation in Minneapolis. The counterexample 
 >>is when two tunnels, both with wildcard selectors, go out the same 
 >>physical interface. In that case, the routing table has insufficient 
 >>information to indicate which tunnel to use.
 >>
 >>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
 > 
 > I think what you mean by "use a virtual device for each ... tunnel" is that
 > the IPsec tunnel is modeled in the system as a point to point link, onto
 > which the system has an interface, correct?  With IIPtran, doesn't the
 > IP-in-IP tunnel have to be modeled in exactly that same way?  Maybe I am
 > being thick but I don't see the gain there.

#2 requires an implementation that has a handle (a device, at least in 
systems we've used) that can be used as a destination in the routing table.

IIPtran doesn't require that handle, because it wraps the packet in an 
IP address that can be used to identify the SA.

 > In either case I would see motivations following from one other in the same
 > order:
 > a.  I want to create a point-point link in the overlay network
 > b.  I need an "overlay" interface at both routers of the overlay network.
 > c.  I create a tunnel connecting those overlay interfaces
 > 
 > Both IIPtran, and tunnel mode IPsec with 0.0.0.0/0 selectors can accomplish
 > this; the latter just seems more direct. 

We think the former is more direct, because it is sufficient to have 
IPsec transport mode with existing tunneling mechaninsms. The latter 
requires that tunnel mode be used in a particular way, and with 
particular constraints depending on the implementation (notably when 
tunnels go out the same interface, as already discussed).

 >>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.
 > 
 > I don't follow that.  I think #2 by definition involves tunnel mode SAs;
 > that is how it is isolating the overlay traffic. 

Yes. In #2, a tunnel would have a SPD with exactly one entry, a tunnel 
mode SA. No SPD could ever have anything EXCEPT a single tunnel mode SA 
OR multiple transport-mode SAs (that's all I was saying above).

  > Each virtual link would
 > *typically* consist of a single bidirectional SA pair.  However, it could
 > conceivably consist of an aggregate of any number of SA pairs, so long as
 > a) they all go to the same overlay next hop, and b) the union of all their
 > selectors is 0.0.0.0/0, i.e. between them all they will admit any packet

Consider a). If the tunnels start in the same place, have the same 
selector, and go to the same place, AND are in the same virtual link 
SPD, the routing table doesn't have enough information to distinguish 
when to use each SA. Only one would ever get used.

Consider b); that might work, but if you're putting up tunnels for a 
VPN, they typically always have 0.0.0.0/0 selectors.

 > In any event, what is the special case with respect to devices you mention?
 > If that refers to casting the tunnel endpoints as IP interfaces of the
 > overlay router, I come back to believing that the same would be required of
 > the IP-in-ip tunnels.

The IP-in-IP tunnels, by virtue of wrapping the packet first, encode 
sufficient information in the wrapper to distinguish outgoing SA. That's 
how they differ from solutions that try to do BOTH wrapping AND keying 
in the same step (i.e., IPsec tunnel mode). This is explained in one of 
the first diagrams in our ID.

Joe