Subject: IKEV2: Issue #3: DHCP vs. Configuration Payload

From: "Theodore Ts'o" <[email-masked]>
Date: Fri, 07 Feb 2003 22:36:40 -0500

This issue has raised perhaps the most comment on the IPSEC mailing
list.  Most of the arguments against the Configuration payload are
that it does not support a rich enough feature set.  Some of the
features which it does not support include:

* Support for the responder to provide a subnet to the initiator, and
not just a single address.  Supporters of a DHCP 3456-style exchange
point to the case where a VPN might be used to provision a small
remote office requiring multiple IP addresses.  Supporters of
the Configuration payload scheme would argue that in such as case, the
addresses for a remote subnet connected via a VPN would either be
likely statically, not dynamically configured, or that such
information is IP Security Policy information that should not be
stored in ones DHCP server, but provided via some other service.
Supporters of the Configuration payload would also argue that in the
vast majority of cases, such as the scenario of the road warrior with
a laptop needing VPN access to connect to his or her corporate
intranet, only a single address is needed, and a Configuration
payload-style scheme is working very well and widely deployed today.

* Support for end-to-end authentication to the DHCP server.  As used
to today, the Configuration payload requires either that the DHCP
server provide allocation of addresses out of its own address pool, or
that it contact a DHCP server (on the inside of the firewall), using
either no security, or via some kind of proxy authentication based on
the identity of the IPSEC gateway, and not the requesting client.  If
in the future, support for end-to-end authentication of address
allocation is required, the a RFC-3456 based solution would be
preferable.

* Support for forcible reassignment of IP address.  DHCP allows IP
address leases to be arbitrarily and without warning yanked from
underneath the client.  This is considered rude and will cause client
applications to break, but the DHCP server has this power.  If the
configuration payload method is used to hand out an address, this can
not be easily achieved.  The IPSEC gateway can send a DELETE SA
payload, which will force the client to stop
using a particular address, but there is no good way to force the
IPSEC client to stop using one address and start using another
address.  It can be argued, however, that most VPN client applications
do not require this functionality.

For some applications, it is clear that the Configuration Payload is
sufficient; the large deployed base of implementations using modecfg
today is testimony to this.  The question, however, is whether or not
it will continue to be sufficient for future applications.

We note that the Configuration payload is substantially simpler than
modecfg in ikev1.  In particular, there is no need for a "Phase 1.5";
the Configuration payload is sent as part of messages 3 and 4.
Furthermore, it is legitimate for the responder to respond with an
empty CFG_REPLY message, indicating that it does not support (or is
not configured) to hand out IP addresses.  

Hence, we suggest that as a path forward, that the Configuration payload
be left in ikev2-04.txt, and that people who believe that a richer
feature set is necessary should be encouraged to update RFC 3456 for use
with IKEv2 as an alternative mechanism.  Since an implementation is
allowed to respond with an empty CFG_REPLY packet, this should not prove
to be an onerous implementation burden for those who are determined to
only support DHCP 3456-style configuration.  While this could
potentially cause interoperability problems, the fact that most deployed
implementations already support modecfg suggests that for the simple
(common?) case where only a single IP address needs to be returned by
the IPSEC gateway, it is extremely likely that most VPN-style
implementations will support the Configuration payload.

If we choose this path, the question of which working group should
pick up the task of updating to RFC 3456 for use with IKEv2, must
ultimately be answered by the Security Area Directors.  However, we
suggest that since RFC 3456 was worked on by the ipsra working group,
and presumably the advocates and experts of this approach are in the
ipsra wg, that they be given the responsibility of authoring the
revision to RFC 3456.

					Barbara Fraser
					Ted Ts'o
					IPSEC working group chairs

---

From: Michael Richardson <[email-masked]>
Date: Fri, 07 Feb 2003 23:48:10 -0500

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

>>>>> "Theodore" == Theodore Ts'o <[email-masked]> writes:
    Theodore> * Support for forcible reassignment of IP address.  DHCP allows
    Theodore> IP address leases to be arbitrarily and without warning yanked
    Theodore> from underneath the client.  This is considered rude and will
    Theodore> cause client applications to break, but the DHCP server has
    Theodore> this power.  If the configuration payload method is used to

  I do not think that this isn't quite correct.

  It can refuse to renew a lease.
  As such, the phase 2 lifetime should be bounded by the DHCP lease time.

  The IPv6/DNS folks are currently discussing whether DHCPv6 or another
mechanism should be used for information discovery. I believe that the IAB
may express a clear opinion at some point. I suggest that IKE has less reason
than IPv6 to diverge from DHCP.

]       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: Tero Kivinen <[email-masked]>
Date: 13 Feb 2003 02:34:26 +0200

> with IKEv2 as an alternative mechanism.  Since an implementation is

I do not really think it is good idea to force everybody to implement
both RFC 3456 and configuration payload. The client will need to
implement both, because if the server replies with empty CFG_REPLY
then it needs to retry with RFC 3456 or similar. 

> implementations will support the Configuration payload.

Allowing two things to do the same thing is bad. 

How about the mcr's proposal of having dhcp over IKE, i.e take dhcp
payload and put it inside the some IKE payload (we can name it to be
configuration payload, so the configuration payload people will be
happy too, just change the format to follow the dhcp packet). 
-- 
[email-masked]
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/

---

From: Derek Atkins <[email-masked]>
Date: 13 Feb 2003 22:25:30 -0500

> Allowing two things to do the same thing is bad. 

I agree...

> happy too, just change the format to follow the dhcp packet). 

I see this as one of two reasonable approaches.  I'm happy with the
"tunnel DHCP in IKE" approach.  The other approach with which I'm also
happy is "use ModeCfg for IP address, then use DHCP later for
additional configuration".  The one benefit of the latter approach is
that IKE with ModeCfg is guaranteed to complete in 4/6 messages,
whereas IKE with tunneled DHCP is not.  However, I can live with
either approach.

> SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/

-derek

-- 
       Derek Atkins
       Computer and Internet Security Consultant
       [email-masked]             www.ihtfp.com

---

From: Tylor Allison <[email-masked]>
Date: Fri, 14 Feb 2003 07:07:20 -0600 (CST)

> then it needs to retry with RFC 3456 or similar.

I absolutely agree with this statement... if we don't move forward with a
single selection, we'll end up having to support both... and most likely
not just in the client.  I can see SGW's needing to implement both to work
with the popular clients.

> happy too, just change the format to follow the dhcp packet).

This is about the third or fourth proposal to use IKE as the DHCP
transport, but I haven't seen much discussion as to whether or not this is
a viable option.  Personally, I believe this has merit, any other opinions?

=====================================================================
= Tylor Allison         Secure Computing Corporation        =========
=====================================================================

---

From: "Scott G. Kelly" <[email-masked]>
Date: Fri, 14 Feb 2003 08:33:19 -0800

Tylor Allison wrote:
<trimmed...> 
> a viable option.  Personally, I believe this has merit, any other opinions?

I agree with Tylor on this point: we really should discuss this before
proceeding. Personally, I have not been too fond of this approach, but
it has been suggested by a number of long-time wg participants, and
seems to have some significant amount of vendor support. It deserves
examination.

In considering this approach, the things I dislike are these:

- it requires the dhcp daemon/application to interface with IKE rather
than sit on a native socket; this may be no big deal for implementations
which cannot use a native dhcp client, but for those which can, this may
be significant.

- it increases the complexity of the ike implementation significantly
more than the other two proposals, as an indeterminate amount of dhcp
traffic must now be tunneled over ike, and ike must provide a dhcp
interface for both the dhcp client (IRAC) and the dhcp proxy/relay
(IRAS).

What I like is this:

- it is a single mechanism which provides modecfg-style support *and*
dhcp support

I'd be very interested to hear the assessments of both modecfg and
rfc3456 implementers.

Scott

---

From: Pekka Riikonen <[email-masked]>
Date: Fri, 14 Feb 2003 18:03:01 +0100 (CET)

: > How about the mcr's proposal of having dhcp over IKE, i.e take dhcp
: > payload and put it inside the some IKE payload (we can name it to be
: > configuration payload, so the configuration payload people will be
: > happy too, just change the format to follow the dhcp packet).
:
: This is about the third or fourth proposal to use IKE as the DHCP
: transport, but I haven't seen much discussion as to whether or not this is
: a viable option.  Personally, I believe this has merit, any other opinions?
:
It would be nice to have as short IKE exchange as possible.  I do however
like DHCP over IPSEC because it's simple and easy to implement.  In IKE
DHCP would cause one extra round trip because client and server need to
ack each other.  However, if the client knows previous configuration it
may attempt a shorter DHCP exchange by directly sending DHCP REQUEST.  In
this case the length would be equal to cfgmode.  OTOH, if that fails then
it's again long exchange (plus the first REQUEST, making it even longer).

There are plenty of implementations of cfgmode for sure, but there are
plenty more DHCP servers out there (ie. everywhere) so using DHCP in IKEv2
is very tempting.

	Pekka
___________________________________________________________________________
 Pekka Riikonen                    | Email: [email-masked]
 SILC - http://silcnet.org/        | http://iki.fi/priikone/
 Tel. +358 (0)40 580 6673          | Snellmanninkatu 34 A 15, 70100 Kuopio
 PGP KeyID A924ED4F: http://iki.fi/~priikone/pubkey.asc

---

From: Bill Sommerfeld <[email-masked]>
Date: Fri, 14 Feb 2003 13:40:46 -0500

> a viable option.  Personally, I believe this has merit, any other opinions?

I agree.

I'd rather see something DHCP-derived than modecfg-like.

While i'd prefer just treating the tunnel like a regular interface and
doing IPsec-protected DHCP, encapsulating DHCP inside IKE is
acceptable to me.

					- Bill