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

RE: Modefg considered harmful





> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com 
> [mailto:owner-ipsec@lists.tislabs.com] On Behalf Of Van Aken Dirk
> Sent: Monday, February 03, 2003 2:51 AM
> To: 'ddukes@cisco.com'; Michael Richardson; ipsec@lists.tislabs.com
> Cc: Scott G. Kelly
> Subject: RE: Modefg considered harmful 
> 
> 
> 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.
> 
This is an implementation issue - there's no reason the VPN remote
access
pool must be separate from the dhcp pool.

-g

> Best regards - Dirk
> 
> > -----Original Message-----
> > From: Darren Dukes [mailto:ddukes@cisco.com]
> > Sent: vrijdag 31 januari 2003 22:19
> > To: Michael Richardson; ipsec@lists.tislabs.com
> > 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
> > 
>