Re: questions on draft-touch-ipsec-vpn

[Mark Duffy <mduffy@quarrytech.com>]

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.

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.  (At least, when implementing from
certain starting points -- I understand you are working within the
constraints of an existing platform/stack.)

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

--Mark