RE: dhcp/modecfg summary

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

Excellent summary Scott, I had a few minor disagreements with it but others
have already mentioned them.

You said
> - I could be pummeled into supporting a marriage of modecfg2 and dhcp if
> the modecfg functionality were limited to IP address assignment only.

This is what I support (not necessarily the pummeling part ;), but I think
modecfg should carry what it did in IKEv1 (WINS/DNS/DHCP server).  Beyond
that DHCPINFORM may be sent by the client to the DHCP server address in the
reply CP.  Is this what you had in mind?  In this scenario the SGW may
implement a DHCP proxy, no DHCP relay is needed.

Also, Bernard brought up some IPv6 problems in IKEv2 modecfg that were not
mentioned in this summary which still need to be addressed.

Darren

> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Scott G. Kelly
> Sent: Thursday, February 06, 2003 12:20 PM
> To: ipsec@lists.tislabs.com
> Subject: dhcp/modecfg summary
>
>
> As Scott Fanning pointed out, it has certainly been a spirited debate.
> Below is a summary from my perspective. I intend this to be objective,
> though it probably isn't completely free of bias. As an aside, it seems
> clear that some posters don't have much deployment experience with
> modecfg *or* dhcp relay. While those folks must not be ignored, neither
> should they be primary drivers of this discussion.
>
> - There are three basic models: local address pool, radius server
> assigns addresses, and dhcp; there are two (suggested) models for dhcp:
> over IP, and over IKE
>
> - a local address pool does not scale; while this is sufficient for
> small implementations, it won't work in large deployments. Radius scales
> if a dhcp server is involved somehow, but not very well if per-user
> unique addresses must be preconfigured into radius.
>
> - some folks seem to imply that remote access entails only a pc
> connected to the target network over the internet; in fact, many
> telecommuter applications involve a personal sgw at the remote end, with
> a small network behind it - this should not be ignored in evaluating
> prospective mechanisms.
>
> - the suggested inability of dhcp-based methods to support policy based
> on pre-assigned ip is red herring, as an implemenation may set up
> template policies based on user class and then back-fill the address
> once assigned with either modecfg or dhcp
>
> - quite a few vendors have implemented dhcp, but apparently more have
> implemented modecfg
>
> - even if ike changes, dhcp implementations will remain, so modecfg2 is
> not quite a freebie, while dhcp is for vendors who've already
> implemented it;
> on the other hand, vendors who have not implemented dhcp relay would be
> impacted, but they will be impacted either way if we agree that support
> for dhcp-inform is required.
>
> - the dhcp model provides a great deal of flexibility due to richness of
> options; you have to look at how dhcp is being used in contemporary
> networks to understand this. Clearly, some folks have yet to do this. As
> for
> extensibility, vendor-specific options provide a clear path.
>
> - 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. 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.
>
> - options: support both, support modecfg2 only, or support dhcp only
>
> - 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.
>
> - I prefer dhcp only, because I know it can be done, and that it is not
> rocket science - no advanced calculus, no theoretical physics, just
> plain vanilla software engineering - complaints to the contrary not
> withstanding. Yes, you need to think before you start thrashing around
> in the code. This is not a one-afternoon hack job. No, it does not take
> a genius to find an elegant way to integrate this functionality.
>
> - I could be pummeled into supporting a marriage of modecfg2 and dhcp if
> the modecfg functionality were limited to IP address assignment only.
> 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.
>
>
> Scott