RE: dhcp/modecfg summary

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

> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Gregory Lebovitz
> Sent: Thursday, February 06, 2003 7:58 PM
> To: ipsec@lists.tislabs.com
> Subject: RE: dhcp/modecfg summary
>
>
> within...
>
> > -----Original Message-----
> > From: Scott G. Kelly [mailto:scott@bstormnetworks.com]
> > Sent: Thursday, February 06, 2003 9:20 AM
> > To: ipsec@lists.tislabs.com
> > Subject: dhcp/modecfg summary
> >
> --SNIP--

<snip>

> (1) we want to do only the things that absolutely have to be
> accomplished in
> IKE for basic client config in IKE. This means IP and DNS server, and
> *MAYBE* DNS, WINS. All else that DHCP might do can happen through a native
> DHCP request, protected by a CHILD_SA.
>
> (2) So we need a way for the client to communicate something of a
> DHCP-Acceptable identity (like MAC) to the responder.

No hitting here, but if DHCPINFORM only is used by the client the chaddr and
client identifier is supposed to be ignored by the DHCP server, so they're
not needed.  If you want more than DHCPINFORM from the client then I think
you will need "DHCP-Acceptable identity" on the client (i.e., chaddr and the
client identifier used by the SGW for the initial lease).

>
> (3) then the responder can send a DHCP relay to the actual DHCP
> server, and
> provide back, through modecfg2 the appropriate IP and DHCP server
> (and maybe
> DNS, WINS). This gives us the scalability of having the IP
> assigned from the
> off-responder DHCP server form the start, and gets us away from only the
> responder having the pool of addresses.
>
> (4) the remainder of the DHCP attributes can be assigned directly between
> the client and DHCP server once the CHILD_SA gets established.
>
> We cannot make the above work (Modecfg2 being the conduit for
> initial DHCP)
> with the attributes currently listed in ikev2-04. We need two more things:
> the client needs to send identity for the DHCP server, and we need to
> explicitly define the DHCP relay from the responder to DHCP
> server. Then we
> can use existing modecfg2 responses to communicate the IP, DNS, WINS.

You suggest the SGW needs to be a DHCP relay, if the client has an IP
address and knows the address of the DHCP server then I don't think a relay
is needed.  Correct?

>
> Doesn't that give us the best of both worlds? We get to keep the ModeCFG
> formats that most of us already have. And the responder/gateway does not
> need to be the address POOL holder for the initial IP assignments (thought
> it could), so we get the scalability and control/flexibility of
> on-board or
> off-board DHCP, right?
>
> > This is a critical point: some modecfg2
> > proponents do not just want address assignment - they seem to want
> > policy config, along with "other things". This wg must decide
> > if this is
> > acceptable.
>
> Implementors and vendors have all learned that we must have client
> configuration, extending to IP related configuration (e.g. IP, mask, DNS,
> WINS, expiry), as such are necessary to get the client's internal traffic
> flowing correctly through the remote gateway to the internal network.
>
> However, POLICY is a different matter, and I believe out of
> scope. But since
> we can send the DHCP server name/address in modecfg2, such a more robust
> DHCP exchange could occur once the CHILD_SA is established.
>
> > - options: support both, support modecfg2 only, or support dhcp only
>
> Or, as I explained, we support DHCP through modecfg2.
>
> > - I would vote no on modecfg2 only, as this will forego the
> > flexibility
> > and power of dhcp-based methods, duplicate much of the functionality,
> > and significantly increase the complexity of the ike
> > implementation - a
> > huge step backward, in my view.
>
> Unless "modecfgw only" means increased clarity of the INTERNAL_IP4_DHCP
>
> > - I could be pummeled into supporting a marriage of modecfg2
> > and dhcp if
> > the modecfg functionality were limited to IP address assignment only.
>
> As proposed above?
>
> > But I
> > would be a reluctant supporter at best, since this requires an
> > implementation to carry both mechanisms, and I don't think it's been
> > demonstrated that IKE should accommodate this. What I *do* think has
> > been demonstrated is that some vendors who chose modecfg in ikev1 are
> > reluctant to modify their implementations - a political reality I'd
> > prefer we not weigh too heavily, but which we (unfortunately) cannot
> > ignore.
>
> I confess, we have modecfg1 already done. But I also have both DHCP client
> and server in my code, as well as DHCP relay. And all considered,
> I'd rather
> do as I've proposed above.
>
> Gregory.