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

From: "Scott G. Kelly" <[email-masked]>
Date: Mon, 10 Feb 2003 15:44:25 -0800

[email-masked] 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

---

From: [email-masked]
Date: Mon, 10 Feb 2003 15:16:54 -0800

Thanks for your responses.. I have another query regarding this.

I have a question about the IPsec SPD.. I had worked a long time back on
Linux freeswan.. What I do remember from that is that each tunnel on the
outbound side was represented as a virtual interface like ipsec0. So the
ipsec engine would insert routes in the routing tables on setup ( I wasn't
doing IKE) for these entries leading to my question in the first place
because I got the impression that IP routing is necessary and the most
typical demultiplexing method to insert packets into different tunnels.. i.e
somehow SPD policies map to a routing entry which would mean the destination
address being the sole criterion for tunnel selection. 

Thanks

-Bik

---

From: Francis Dupont <[email-masked]>
Date: Tue, 11 Feb 2003 13:42:11 +0100

In your previous mail you wrote:

=> first routes are not enough because they work only on destinations.
Second there is nothing about the nature (i.e., interface or not) of
IPsec tunnels in RFCs.

   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.

=> usually SPD entries are standard filters (i.e., same than for QoS)
on the 5-tuple (addresses, protocol, ports) with some restrictions
for forwarded packets (because deep parts of the 5-tuple can be hard
or impossible to get, for instance for fragments).

   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?

=> yes. For instance if you'd like to encode the SPD for a mobile VPN,
a source=<my VPN address> destination=<everything> protocol=<any> ports=<any>
will do the job: any packet using the VPN address (i.e., not the local address)
will be encapsulated.

Thanks

[email-masked]

---

From: Suresh Kumar <[email-masked]>
Date: Tue, 11 Feb 2003 08:15:30 -0800 (PST)

Hello IPSec Gurus,

Any public domain/portable or commerical implemenation of IKE available for Solaris 8.0.  If any of you have ported any freeware to solaris please share your experience with me.

Suresh.

---------------------------------
Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine's Day

---

From: "Michael Richardson" <[email-masked]>
Date: Tue, 11 Feb 2003 13:33:35 -0500

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "BSingh" == BSingh  <[email-masked]> writes:
    BSingh> Thanks for your responses.. I have another query regarding this.

    BSingh> I have a question about the IPsec SPD.. I had worked a long time
    BSingh> back on Linux freeswan.. What I do remember from that is that
    BSingh> each tunnel on the outbound side was represented as a virtual
    BSingh> interface like ipsec0. So the ipsec engine would insert routes in

  No, each tunnel does not have a virtual interface in FreeS/WAN.
  Each *physical* interface has a virtual interface, like "ipsec0" associated
with it. We steal the packets via routing, and then insert them into the real
interface using magic.  

  We are heading towards a situation where each tunnel could have a virtual
interface (it will be an option). We are heading away from having an the
virtual interfaces have anything to do with the physical interfaces.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

---

From: Stephen Kent <[email-masked]>
Date: Thu, 13 Feb 2003 17:02:37 -0500

>support protocol and/or ports as selectors.

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

---

From: Stephen Kent <[email-masked]>
Date: Thu, 13 Feb 2003 17:48:47 -0500

At 2:29 PM -0800 2/13/03, Scott G. Kelly wrote:
><SNIP>
>
>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.
>

No problem, Scott. I was catching up on mail and got things out of 
order. I understand the differences between what you described and 
what I have suggested. My message was really a clarification for the 
list, nothing more.

Steve

---

From: "Scott G. Kelly" <[email-masked]>
Date: Thu, 13 Feb 2003 14:29:07 -0800

Hi Steve,

Comments below...

Stephen Kent wrote:
<trimmed...> 

Scott

---

From: Derek Atkins <[email-masked]>
Date: 13 Feb 2003 22:28:25 -0500

> outlined in RFC2401, for the reasons I enumerated above. 

This works fine for output processing, but not necessarily for input
processing.

-derek

-- 
       Derek Atkins
       Computer and Internet Security Consultant
       [email-masked]             www.ihtfp.com

---

From: "Scott G. Kelly" <[email-masked]>
Date: Fri, 14 Feb 2003 08:39:39 -0800

Hi Derek,

[recipient list trimmed...]

> This works fine for output processing, but not necessarily for input

I guess I don't understand what you mean. I don't think it works
according to what is specified in RFC2401, as (1) you cannot control the
SPD ordering due to the fact that route selection is best match (unless
your SPD happens to be ordered from most specific to least specific),
and (2) you cannot select traffic based on protocols/ports. So, it
doesn't really work right (where "right" means "in accordance with
RFC2401") for either egress or ingress, does it?

Scott

---

From: Derek Atkins <[email-masked]>
Date: 14 Feb 2003 12:13:37 -0500

> RFC2401") for either egress or ingress, does it?

Well, you can..  The point that was being made was that you'd have a
SPD "per route".  So, after you choose the route you're going to take
you lookup the SPD and choose the SA to use (if any).  The traffic could
be dropped at this point, too.

My only point was that on input you don't necessarily have the "input
routing" information, so you may not know which virtual route was
used, so searching input SPDs are much more difficult.

-derek