Subject: RE: Modefg considered harmful

From: Van Aken Dirk <[email-masked]>
Date: Mon, 3 Feb 2003 11:51:13 +0100

Hi Darren,

Have you thought about following situation ?

RemoteOfficeLAN-----SmallIPSecGW-----LargeIPSecGW-----CentralOfficeLAN

Following parameters are configured on the SmallIPSecGW:

- LAN port (connected to the remote office Ethernetsegment): 20.0.0.254/24
- DHCP Relay: enabled on this LAN port; giaddr= 20.0.0.254; DHCP Server=
30.0.0.1
- IPSec policy: protect 30.0.0.0/24 and IKE peer= Large IPSecGW
or
- IPSec policy: protect 0.0.0.0/0 and IKE peer= Large IPSecGW

A PC is booting on the RemoteOfficeLAN, its broadcast DHCP requests arrive
in the SmallIPSecGW and are converted via the DHCP relay into unicast DHCP
request. Subsequently these request hit IPSec policy 30.0.0.0/24 or
0.0.0.0/0 and are tunneled to the remote LargeIPSecGW. The LargeIPSecGW
processes these DHCP request as ordinary unicast packets; all that is needed
is policy rules. The DHCP server picks an IP address based on giaddr or more
advanced criteria.
Actually from the moment that the DHCP Relay makes the broadcast/unicast
conversion everything is "standard" IPSec. Packets follow routes and obey
policy rules; no IKECFG nor IPSec-DHCP specific functionality required. 

Appart from configuring policy rules there are no new skill that must be
learned by the network administrator because in the CentralOfficeLAN he uses
these same techniques to manage his/her network.

If Remote Access VPN users are based on RFC3456 I have a DHCP solution for
my complete network infrastructure more specific:
- my centreal office LAN
- my remote office VPN's
- my remote access VPN users.

In case of Remote Access VPN users based on IKECfg I have to train my
network admin for this special case and address pools are located in two
devices: the DHCP server and the Large VPNGW.

Best regards - Dirk

> -----Original Message-----
> From: Darren Dukes [mailto:[email-masked]]
> Sent: vrijdag 31 januari 2003 22:19
> To: Michael Richardson; [email-masked]
> Cc: Scott G. Kelly
> Subject: RE: Modefg considered harmful 
> 
> 
> I think any mature implementations that will be trying to use DHCP for
> complete configuration of the ipsec client (beyond network 
> addresses, as is
> possible with modecfg today) will need to implement their own 
> DHCP client
> and server in order to include their user-specific ipsec-VPN 
> configuration.
> So what we'll end up with is as follows.
> 
> OS-DHCP-client(optional) <-> ipsec-DHCP-client <TUNNEL> 
> SGW-DHCP-server
> 
> Reusing the OS DHCP client (if possible at all) will not give enough
> flexibility.
> 
> Darren
>

---

From: Michael Richardson <[email-masked]>
Date: Mon, 03 Feb 2003 15:41:41 -0500

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

>>>>> "Van" == Van Aken Dirk <[email-masked]> writes:
    Van> Have you thought about following situation ?

    Van> RemoteOfficeLAN-----SmallIPSecGW-----LargeIPSecGW-----CentralOfficeLAN

    Van> Following parameters are configured on the SmallIPSecGW:

  This is out of scope.

  SmallIPsecGW should run a DHCP relay, and tunnel the packets through the
VPN to the CentralOfficeLAN's DHCP server.

  The only "difficulty" is that the IP addresses provided to the
RemoteOfficeLAN will need to either fit into the existing tunnel that
SmallIPsecGW has, or that SmallIPsecGW should have a somewhat "wide" policy
for all communication from RemoteOfficeLAN<->CentralOfficeLAN, and use
per-host keying to create new LANs.

]       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: "Scott G. Kelly" <[email-masked]>
Date: Mon, 03 Feb 2003 15:08:03 -0800

>     Van> Following parameters are configured on the SmallIPSecGW:

Why is this out of scope? This is a common remote access scenario for
deployments utilizing personal sgw's at the remote end.

> VPN to the CentralOfficeLAN's DHCP server.

Yes, a la RFC3456. This is one of the remote access applications which
makes the dhcp approach so attractive.

Scott

---

From: Michael Richardson <[email-masked]>
Date: Mon, 03 Feb 2003 18:40:22 -0500

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

>>>>> "Scott" == Scott G Kelly <[email-masked]> writes:
    >> This is out of scope.

    Scott> Why is this out of scope? This is a common remote access scenario for
    Scott> deployments utilizing personal sgw's at the remote end.

  Because a) it is solveable already using existing specifications.
	  b) it has nothing to do with configuring an IPsec client. It is
	  about configuring clients that are behind IPsec gateways.

---

From: "Darren Dukes" <[email-masked]>
Date: Tue, 4 Feb 2003 10:42:23 -0500

Actually with this scenario a DHCP relay within the RemoteOfficeLAN instead
of on the SmallIPsecGW would likely be the implementation of choice.
RFC3456 does not say anything about the relay being on the inside LAN
interface, only the interface terminating IKE-SAs so I don't think it could
be applied to this scenario.

Regarding your comments about modecfg, there is no need for an address pool
on the LargeIPsecGW since it could act as a DHCP-client when it receives
modecfg requests from an IRAC instead of having its ipsec engine sniffing
for inbound DHCP packets and forwarding them to the internal DHCP relay.

Darren.

PS - I know you don't like the idea of dhcp to modecfg conversion by the
LargeIPsecGW.

> From: Van Aken Dirk [mailto:[email-masked]]
> Sent: Monday, February 03, 2003 5:51 AM
> To: [email-masked]'; Michael Richardson; [email-masked]
> Cc: Scott G. Kelly

---

From: "Scott G. Kelly" <[email-masked]>
Date: Tue, 04 Feb 2003 09:00:26 -0800

Hi Darren,

> be applied to this scenario.

Actually, you could either relay from the inside of the remote lan
alone, or from there *and* from the head-end sgw. The benefit of the
second configuration would be that in such cases, the remote lan need
not be aware of the IP address of the dhcp relay destination. In any
event, the tunnel must either support 0/0 selectors, or there must be a
separate tunnel for the dhcp packets. 

You are correct that the rfc does not explicitly call out this
configuration. It probably should.

Scott

---

From: "Geoffrey Huang" <[email-masked]>
Date: Wed, 5 Feb 2003 10:03:25 -0800

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Van Aken Dirk
> Sent: Monday, February 03, 2003 2:51 AM
This is an implementation issue - there's no reason the VPN remote
access
pool must be separate from the dhcp pool.

-g