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

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



At 3:44 PM -0800 2/10/03, Scott G. Kelly wrote:
>BSingh@Nomadix.com wrote:
><trimmed...>
>>  But I guess this is not what RFC2401 says and it leaves it open for various
>>  implementations to have different SPD methodology.. Can you update me on
>>  what other ways SPD entries are looked up for tunnel selection.. I am more
>>  interested in the source address or some source parameter being included as
>>  the criteria for tunnel selection or an SPD interface that lets me make
>>  policies based on the source of the packets.. Is it possible? If you can
>>  guide me there I would really appreciate it..
>
>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