RE: Modefg considered harmful

["Darren Dukes" <ddukes@cisco.com>]

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.


> -----Original Message-----
> From: Van Aken Dirk [mailto:VanAkenD@thmulti.com]
> Sent: Monday, February 03, 2003 5: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.
>
>
> 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
> >