RE: dhcp/modecfg summary

[Michael Choung Shieh <mshieh@netscreen.com>]

I would say the address allocation for a group of PC behind the peer gateway
is out of scope of this discussion.  It should be done AFTER IKE is done,
not within IKE.

I like the flexibility of DHCP, but the complexity of implementing RFC3456
(glue IKE/IPSEC/DHCP) scares me.  The states of key exchange will need to
include ike phase 1, phase 2 for dhcp sa, DHCP in IPsec, then phase 2 for
data traffic.  If there are any error occurs, we need to revoke all
established states.  It is doable, but it's hard to maintain and achieve
interoperability. 

I wonder if there is an option for DHCP-over-IKE or DHCP over Modecfg2.  If
I need to pick from modecfg-only and DHCP-only, I will choose modecfg for
its simplicity.

just my 2 cents,

=======================
Michael Shieh


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