Subject: dhcp/modecfg summary

From: "Scott G. Kelly" <[email-masked]>
Date: Thu, 06 Feb 2003 09:20:18 -0800

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

---

From: "Stephane Beaulieu" <[email-masked]>
Date: Thu, 6 Feb 2003 16:37:47 -0500

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

> a small network behind it - this should not be ignored in evaluating

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

> 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

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

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

> policy config, along with "other things". This wg must decide if this is

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.

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

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

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

> prefer we not weigh too heavily, but which we (unfortunately) cannot

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.

---

From: "Geoffrey Huang" <[email-masked]>
Date: Thu, 6 Feb 2003 19:03:37 -0800

<snip>

> server, or LDAP), than in a DHCP server.

Stephane, I think this is well-put.  We're used to using Radius/LDAP for
policy - not so used to using DHCP.

<snip again>

> solved with mode-cfg, and we can't drop those features in the 

Again, I think this is well-stated.  We have experience with mode config
- we've seen it solve problems we have.

-g

---

From: Francis Dupont <[email-masked]>
Date: Fri, 07 Feb 2003 11:11:00 +0100

In your previous mail you wrote:

=> this is especially true in an IPv6 environment. In fact, if DHCPv6
is not the prefered address allocation mechanism (stateless autoconf
is used nearly everywhere), it is the mechanism of choice for
prefix allocation.
I won't complain if the modecfg for IPv6 can handle only prefix
allocations (note this is easier than the current option :-).

Regards

[email-masked]

---

From: "Darren Dukes" <[email-masked]>
Date: Fri, 7 Feb 2003 11:44:43 -0500

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

You said
> 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: [email-masked]
> [mailto:[email-masked]]On Behalf Of Scott G. Kelly
> Sent: Thursday, February 06, 2003 12:20 PM
> To: [email-masked]
> Subject: dhcp/modecfg summary
>
>

---

From: Michael Richardson <[email-masked]>
Date: Fri, 07 Feb 2003 20:22:29 -0500

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Scott" == Scott G Kelly <[email-masked]> writes:
    Scott> - some folks seem to imply that remote access entails only a pc
    Scott> connected to the target network over the internet; in fact, many
    Scott> telecommuter applications involve a personal sgw at the remote
    Scott> end, with a small network behind it - this should not be ignored
    Scott> in evaluating prospective mechanisms.

  This is small office VPN to me, not a road warrior. 
  Unless you claim that it moves around, it is really a different situation
than RW. If you claim that it is in scope, then so are all "VPN"s.

    Scott> - one stated aim of this wg in redesigning IKE has been to
    Scott> minimize impact on ike, to not add anything which is not

  I want to emphasis that while we want to minimize impact on ike, we are
changing that piece. We want *ZERO* impact on RFC2401 if possible. We may add
(i.e. AES being a MUST) to 2401bis, but I think that IKEv2 should assume that
IPsec is implemented in some piece of silicon and can't be changed.

    Scott> required. If we stick to this position, this seems to imply that
    Scott> dhcp support will be required regardless (via dhcp inform and
    Scott> relay), unless we actually intend to expand modecfg2 to encompass

  I agree.

  To me, the only question is: DHCP over IPsec vs DHCP over IKE.
  DHCP over IKE basically looks just like modecfg.

  Thank you very much for the summary.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

---

From: "Scott G. Kelly" <[email-masked]>
Date: Fri, 07 Feb 2003 18:00:28 -0800

Hi Michael,

> than RW. If you claim that it is in scope, then so are all "VPN"s.

I agree that the line is sometimes a little fuzzy, but what
differentiates these scenarios is that the IP address of the remote
user's personal sgw is not fixed, and so it cannot be preconfigured on
the headend. In some cases, the small network behind gw consists of a
single system:

+-------+   +------------++              
| user  |---|personal sgw||=[internet]==
+-------+   +------------++

The fact that the ipsec implementation is BITW instead of a BITS does
not invalidate this as a remote access scenario. It can be implemented
in such a manner as to be indistinguishable from a software
implementation from the other end of the connection. I've personally
worked on an implementation where the remote sgw does a ULA exchange
with the user (similar to xauth) through the tunnel. This *is* a remote
access scenario.

Scott

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.7 (GNU/Linux)
> Comment: Finger me for keys
> 
> iQCVAwUBPkRb1IqHRg3pndX9AQE4ngP9HiXgkhtrT930DSuLWYVAXpUVTLsgEv3A
> Ec5jlFtONC7xbFToVqVPMtLSuaxDJ91KE/ntA7q9X3T48c+lUCNxSoAzeSKnGW9h
> MrSVNARAhGVqXtziTqAKNO6Ni0NQbHg595Xp5CyjZVzFYJFCclMjt9in7GVt4/Hz
> Sc7cWsTdVl8=
> =Q82N
> -----END PGP SIGNATURE-----

-- 
-------------------------------------
BlackStorm Networks is now airespace
-------------------------------------