RE: dhcp/modecfg summary

[Gregory Lebovitz <Gregory@netscreen.com>]

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--

> - one stated aim of this wg in redesigning IKE has been to minimize
> impact on ike, to not add anything which is not required. If 
> we stick to
> this position, this seems to imply that dhcp support will be required
> regardless (via dhcp inform and relay), unless we actually intend to
> expand modecfg2 to encompass all dhcp options plus some new
> ipsec-specific options. 

I would strongly vote against modefg2 encompassing all DHCP options
natively. I.E. we should not create additional modecfg2 attributes to cover
all the things that DHCP does. In fact we do not need to, right? modecfg2
could be the delivery mechanism for DHCP options from a DHCP service
external to the responder. 

Here I must confess that I should have paid more attention earlier, and
spoken up sooner... and please don't hit me if I've repeated a previously
proposed idea... but here goes anyway ...

(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.

(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. 

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.