Subject: RE: dhcp/modecfg summary

From: Gregory Lebovitz <[email-masked]>
Date: Thu, 6 Feb 2003 16:57:54 -0800

within...

> -----Original Message-----
> From: Scott G. Kelly [mailto:[email-masked]]
> Sent: Thursday, February 06, 2003 9:20 AM
> To: [email-masked]
> 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.

---

From: "Darren Dukes" <[email-masked]>
Date: Fri, 7 Feb 2003 11:54:25 -0500

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Gregory Lebovitz
> Sent: Thursday, February 06, 2003 7:58 PM
> Subject: RE: dhcp/modecfg summary
>
>
> within...
>

<snip>

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

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

---

From: Michael Richardson <[email-masked]>
Date: Fri, 07 Feb 2003 19:35:23 -0500

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

>>>>> "Gregory" == Gregory Lebovitz <[email-masked]> writes:
    Gregory> I would strongly vote against modefg2 encompassing all DHCP
    Gregory> options natively. I.E. we should not create additional modecfg2
    Gregory> attributes to cover all the things that DHCP does. In fact we do
    Gregory> not need to, right? modecfg2 could be the delivery mechanism for
    Gregory> DHCP options from a DHCP service external to the responder.

  That's what I keep saying!!!

  Just take a DHCP payload, encapsulate it in an IKE phase 1 structure,
and send it. That avoids reinventing all the DHCP stuff, but maintains all of
the simplicity of modecfg.

  BITS can even, if they want, just take the DHCP payload out of the one
that they would normally tunnel through a phase 2 SA. The IKE phase 1 is just
being used as a DHCP relay. At the gateway end, it either becomes a real DHCP
packet to a real DHCP server, or you implement it internally.

    Gregory> We cannot make the above work (Modecfg2 being the conduit for
    Gregory> initial DHCP) with the attributes currently listed in
    Gregory> ikev2-04. We need two more things: the client needs to send
    Gregory> identity for the DHCP server, and we need to explicitly define
    Gregory> the DHCP relay from the responder to DHCP server. Then we can
    Gregory> use existing modecfg2 responses to communicate the IP, DNS,
    Gregory> WINS.

  Yes.

    Gregory> Doesn't that give us the best of both worlds? We get to keep the
    Gregory> ModeCFG formats that most of us already have. And the

  Yes.

  I would be willing to help write this up.

]       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"); [