RE: dhcp/modecfg summary

["Stephane Beaulieu" <stephane@cisco.com>]

The bias shines through a little, but a good effort at restraint none the
less ;)  I'll try to do the same...

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

Agreed.  Though, this can be done via either method, so I'm not sure if you
were trying to make a point...

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

The ability to combine the phase 1 ID, and/or the SLA user and/or group info
with your VPN policy to determine which users are permitted to do what, and
on which networks is possible with mode-cfg, and is a popular method of
deployment.  This is especially popular used in conjunction with RADIUS and
even LDAP.  Though it is possible with DHCP, it is definitely not as
straight-forward, nor as easy to administer.

>
> - quite a few vendors have implemented dhcp, but apparently more have
> implemented modecfg

I'm curious to know who the dhcp vendors are? and on what operating systems
they've done it? Trying to figure out if any OS's are trickier than others.
Were there problems in implementations that had IPsec in the stack? Do they
actually use the existing DHCP code, or did it require "special cases" or a
whole new implementation for VPN?  I realize that it's not rocket science,
or advanced calculus, or, etc, etc, etc....  I'm just trying to get a handle
on how much real experience there is here.

I know that we've done mode-cfg (Client side) on all MS platforms, Linux,
Solaris, Mac, as well as all our homegrown OSs (IOS, PIX, VPN3000), and all
have been quick and pain free


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

You're now putting some of your vendor-specific VPN policy on your dhcp
server.  VPN policy long-term belongs in the IPSP (if that ever ends up
being deployed).  In the short term though, I definitely feel better using
mode-cfg, and having the policy stored in the VPN head-end (or RADIUS
server, or LDAP), than in a DHCP server.

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

I think the main goal was to increase security and interoperability.

>
> - options: support both, support modecfg2 only, or support dhcp only

May I add an option?  Support mode-cfg with DHCP-inform for those who
absolutely must speak to a DHCP server for whatever feature-rich feature
which is so important.  Those who don't want / need anything other than
basic bootstrapping don't need intercept, modify?, snoop? DHCP packets.

>
> - 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 vote mode-cfg w/ DHCP-inform.

My reasoning is that I haven't seen a need for the other features of DHCP in
my 6 years or so of deploying mode-cfg (though I'm not in denial that it
won't happen, eventually). I have however seen MANY customers feature
requests for VPN policy provisioning that can VERY easily be done securely
via mode-cfg.  Ease of use = deployment, and I think that is the end goal
here.  Mode-cfg is lightweight and handles 95% of the cases.  We can use
DHCP-inform for the rest.

>
> - 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 attempt to dig a 6 inch hole with a back-hoe too.  But I'd much
rather use a shovel ;)


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

This works for me !  A very lightweight method of obtaining an IP address
that still allows us to do our user based policy provisioning, and gives you
the feature-richness of DHCP if you need it.  All for the low, low price of
5 years of bickering...  Done !  Where do I sign?  Seriously, it's time to
bring this to an end, and this option, I think, both camps can live with.


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

What you fail to realize is that there are 2 reasons why vendors have chosen
to use mode-cfg in the past, and are reluctant to part with it.
1 - Ease of implementation  (yeah, yeah, dhcp not rocket science, yada yada
yada...).  At my last count, which was quite a while ago...(bakeoff in San
Diego, 2000?) there were something like 25 different implementations of
mode-cfg w/IKEv1 by about 20 different vendors.  Why mode-cfg and not DHCP?
Use a small hammer for a small nail....
2 - Extensibility
This is the stuff you don't know about, because it's not public.  There's
more to bootstrapping a VPN RA Client than IP, WINS, DNS.  There's "value
add" stuff you can do too.  This is a little taboo because *some* of it
overlaps with IPSP.  When IPSP is done and deployed, we might pull some
stuff out of our mode-cfg extensions and use IPSP.  But we'll never be able
to do it all in IPSP, because some of it is crazy customer features (which
will never be standardized...) and some of it is very implementation
dependant.  The point here is that though you'd like to believe we're just
lazy and don't want to spend a couple of days hooking into the various DHCP
implementations in the various stacks and OSs that we need to deal with (OK,
I'd rather not to tell you the honest truth :), we just plain can't
completely switch to *just* DHCP, because it can't do everyting we need it
to do.

So, we're not just pig-headed.  We have real customer needs that we've
solved with mode-cfg, and we can't drop those features in the upgrade to
IKEv2.

Stephane.

>
>
> Scott