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

From: [email-masked]
Date: Thu, 6 Feb 2003 17:20:16 -0800

I have a few clarifications regarding usage of IPsec for VPNs. I have been
even going through the thread of Modecfg vs. DHCP and seem a little confused
regarding the functionality.
 
- This particular debate of Modecfg vs. DHCP relates only to remote access
scenarios or does it extend to address management for site-to-site VPNs. I
would distinguish the 2 using the following definitions- One tunnel per
machine and address to be given out (whichever way - modecfg or DHCP) at
tunnel setup time would be Remote Access. Site-to-site would be that tunnel
is setup apriori between 2 gateways and both sides would be different
private subnets. Users in site-to-site VPNs get addresses typically from
their own subnet's DHCP servers. Please correct me if i am wrong..
 
- Is it also possible that in a site-to-site VPN the address allocation is
handled by only one of the private networks (subnets). ie. DHCP is tunneled
over to this network from all other private networks and responses tunneled
back? Is it a typical setup? Is the discussion of modecfg vs. DHCP relevant
in this case? I assume that their might be some routing issues in this setup
for tunneling the responses back to the DHCP requesters through the right
tunnels. Maybe some state maintenance at the gateways. 
 
- Typical IPsec implementations. Most of them are bump in the stack
(software ones).. Am I correct? Does it mean that IP routing is the only way
to direct traffic into the right tunnels? i.e destination address based. Are
their any implementations that do not follow this paradigm. Any pointers
would be helpful. 
 
thanks
 
-Bik

----------------------------------------------------------------------------
-------------- 
Bik Singh                                   818-575-2518 (Off) 
Research Scientist                      818-597-1502 (Fax) 
Product Development                  31355 Agoura Road 
Nomadix                         Westlake Village, CA 91361

---

From: Francis Dupont <[email-masked]>
Date: Sun, 09 Feb 2003 16:50:54 +0100

In your previous mail you wrote:

    
=> this is less and less true because someone can use a home-to-office
VPN from a or a few home networks. This is not very common with IPv4
(not enough addresses -> NATs :-) but should be very common with IPv6
where a home user can get between a /64 and a /48.

=> for IPv6 a prefix allocation/assignment should be used (DHPCv6-lite)
for instance.

=> I disagree: at the initiator side the only needed thing is a SPD
with some entries to disable infinite recursive protection and an entry
for everything else. The SPD is used before routing so the routes are
the same in general with and without the VPN.
At the responder/SG side, the only problem is the reverse routing.
Proxy ARP/ND works well for VPNs to hosts but for VPNs to subnetworks
only reverse route injection does the job.

Regards

[email-masked]

---

From: "Scott G. Kelly" <[email-masked]>
Date: Sun, 09 Feb 2003 11:55:49 -0800

Francis Dupont wrote:
<trimmed...>

> only reverse route injection does the job.

I'm not sure I fully understand what you just said, but one of the
things I think I just read is that routing happens after SPD use. I
think this is highly implementation specific. I've created an
implementation which supports per-interface policies. In this
implementation, the SPD for the ingress interface is consulted upon
receiving a packet, and the appropriate policy is applied. After this
step, a routing lookup is performed to determine the exit interface, and
then the SPD associated with that interface is consulted. This is a
powerful model with interesting properties.

Now, you could say that the SPD is used before routing, as the one on
the ingress interface certainly is, but what about the one on the egress
interface? As for routes being the same with or without the VPN, this is
typically true for exiting packets, although not necessarily in cases
where an encapsulation occurs due to policy related operations.

Scott

Scott

---

From: Francis Dupont <[email-masked]>
Date: Mon, 10 Feb 2003 10:47:34 +0100

I'm not sure I fully understand what you just said, but one of the
   things I think I just read is that routing happens after SPD use.

=> yes, policies are applied before the real routing happens.
Often there is a route lookup at the entry of IP output routine
but real routing can be done only at the end because of all the
special cases (multicast, routing headers, policies, etc).

   I think this is highly implementation specific. I've created an
   implementation which supports per-interface policies. In this
   implementation, the SPD for the ingress interface is consulted upon
   receiving a packet, and the appropriate policy is applied.

=> I considered only the egress processing (routing in the ingress
processing is marginal).

   After this
   
=> this is the standard way but this routing lookup doesn't do the
real routing, i.e., another route can be used to send the packet.

=> if there is an encapsulation, the route has to be reevaluated so
in this way the SPD is used before final routing. Especially in common
implementations the IPsec decision is from a SPD match, not a route table
one. But this is really implementation dependent and RFC 2401 is not
the clearest document we can find (:-).

Regards