RE: dhcp/modecfg summary

[Van Aken Dirk <VanAkenD@thmulti.com>]

I agree with Scott's (G. Kelly) summary and what I will remember most from
the discussion is that at least a few people are now looking into DHCP
related RFC's and beginning to realize that beside IKEModeCfg that there are
other solutions available.

Anyway I propose following changes to section 5.15:

1)
5.15 Configuration Payload

The Configuration payload, denoted CP in this document, is used to exchange
configuration information between IKE peers. Implementations MAY use other
methods such as the one described in [x1].

10 References

[x1] B. Patel, B. Aboba, S. Kelly, V. Gupta, "Dynamic Host Configuration
Protocol (DHCPv4)- Configuration of IPsec Tunnel Mode.

2) I would prefer that attribute type INTERNAL_IP4_DHCP becomes a MUST
support attribute.

The rational behind this request is that at least I can rely upon this
attribute as a way out if I can't fulfil more advanced scenario's with
IKEModeCfg.


Thanks in advance - Dirk


> -----Original Message-----
> From: Scott G. Kelly [mailto:scott@bstormnetworks.com]
> Sent: donderdag 6 februari 2003 18:20
> 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
>