Subject: IPsec VPNs incl. modecfg vs. DHCP

From: [email-masked]
Date: Fri, 7 Feb 2003 09:40:12 -0800

Posting again due to bad format last time.
------------------------------------------

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). i.e.. 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: "Scott G. Kelly" <[email-masked]>
Date: Fri, 07 Feb 2003 13:14:23 -0800

I'll take a shot at answering this. Comments inline below...

> Posting again due to bad format last time.

This is probably a reasonable attempt at a definition, but it leaves out
remote access scenarios where a personal security gateway is at the
remote end. Also, remote access users do not *necessarily* need address
assignment, but this is often done to simplify windows networking tasks
via the vpn. 
 
> the right tunnels. Maybe some state maintenance at the gateways.

I've never seen this attempted, but that doesn't mean it won't be done.
Obvious issues result if connectivity is lost at renewal time. I have
seen it done in telecommuter scenarios where the user has a small
network behind a personal sgw, but again, there are issues if
connectivity is lost and lease times are small. This can be resolved by
having a lightweight dhcp server on the personal sgw which doles out
short-lived config when the tunnel is down, and forwards dhcp through
the tunnel when it is up. Modecfg doesn't seem to make much sense in
such scenarios.

> Are their any implementations that do not follow this paradigm. Any pointers

I'll leave this one for someone else to answer...

Scott

---

From: Michael Richardson <[email-masked]>
Date: Fri, 07 Feb 2003 17:19:20 -0500

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

>>>>> "BSingh" == BSingh  <[email-masked]> writes:
    BSingh> - This particular debate of Modecfg vs. DHCP relates only to
    BSingh> remote access scenarios or does it extend to address management
    BSingh> for site-to-site VPNs. I would distinguish the 2 using the

  I'd like to restrict the scope to remote access.

    BSingh> - Is it also possible that in a site-to-site VPN the address
    BSingh> allocation is handled by only one of the private networks
    BSingh> (subnets). i.e.. DHCP is tunneled over to this network from all
    BSingh> other private networks and responses tunneled back? Is it a

  Certainly possible. No new technology needed, just deploy a DHCP relay 
agent on the remote subnet. It doesn't even need to know that there is a VPN.

    BSingh> - Typical IPsec implementations. Most of them are bump in the
    BSingh> stack (software ones).. Am I correct? Does it mean that IP

  No.
  Most non-Microsoft Windows ones have no choice but to be.
  Few dedicated gateway boxes are.

  Solaris, KAME (*BSD), OpenBSD, Microsoft, and Linux 2.5 IPsec are certainly
built in. FreeS/WAN is ... strange. It is BITS on 2.0 kernels, kinda not on
2.2, and only so on 2.4 due to hysterical raisins. 

    BSingh> routing is the only way to direct traffic into the right tunnels? 
    BSingh> i.e. destination address based.  Are their any implementations

  It may well be that some non-BITS can only deal with destination address
issues, but I haven't seen any.
  Often, for BITS it is the case that the destination address trick only
directs the traffic into the IPsec machinery, at which more complicated
decisions can be made in accordance with RFC2401.

]       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"); [