dhcp/modecfg summary

["Scott G. Kelly" <scott@bstormnetworks.com>]

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