Re: typical IPsec-based VPNs incl. modecfg vs. DHCP

["Scott G. Kelly" <scott@airespace.com>]

Hi Steve,

Comments below...

Stephen Kent wrote:
<trimmed...> 
> >I think RFC2401 is quite explicit about what selectors are used in SPD
> >lookups. Based on this, the virtual interface approach suffers from (at
> >least) two problems: first, routing lookups are most specific to least
> >specific (i.e. "best match"), meaning the administrator may not be able
> >to strictly control the ordering of SPD elements. Secondly, it does not
> >support protocol and/or ports as selectors.
> >
> >Scott
> 
> The notion that I've been developing for separating routing from
> access control in IPsec, and which was discussed among a set of folks
> interested in overlay nets and PPVPNs, is to make a call to a routing
> function prior to SPD lookup. The function would return a virtual
> interface ID (VID) and that can be used to select an SPD if one has a
> set of SPDs, one per virtual interface.  In a very simple context
> this call always returns the same VID and there is only one SPD. In a
> more complex environment the function returns meaningfully different
> results, and one can have multiple SPDs, or one SPD in which the VID
> is yet another selector (if you want to think of it that way).
> 
> Steve

As a matter of clarification, the "virtual interfaces" I refer to above
are also called "tunnel interfaces" in some implementations. I saw some
early open source ipsec implementations which used this approach (maybe
bsd-based). Basically, a tunnel is established, and then the tunnel is
treated as an interface (a virtual interface). There is no SPD/SAD
selection, per se; rather, a standard routing lookup determines which
interface a packet exits via, and ipsec tunnels have vif entries in the
routing table, making them look like "exit interfaces".

In such cases, no SPD entries are consulted following the routing
lookup, and the routing table (effectively) becomes the SAD/SPD. I think
this has obvious issues in terms of satisfying the selector criteria you
outlined in RFC2401, for the reasons I enumerated above. 

I also think this is significantly different than what you are referring
to above (the design you are developing), and I think you refer to the
same sort of design I described as having implemented in order to
support independent, per-interface policies. I hope you didn't think I
intended to criticize your approach. On the contrary, I think this model
is very powerful.

Scott