[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

IKEV2: Issue #3: DHCP vs. Configuration Payload




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