[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: questions on draft-touch-ipsec-vpn



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

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.

We feel that IIPtran is a simpler and more direct solution, as it 
acknoweldges the separate functions of tunneling and IPsec.

> I get a hint from reading the draft that the proposal may be motivated by
> an implementation environment where there is already a platform with an IP
> stack and IPsec embedded in it, and it is desired not to change the IPsec
> implementation or its relationship to the rest of the IP stack.  Is that
> the reason for this choice of approaches?

We certainly prefer solutions that don't require new protocols or new 
implementations where possible. IIPtran achieves more of that than #2 
above as well.

Joe