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

RE: Modefg considered harmful



Bernard you made me read a lot of specs today, something I should have done
weeks ago.  I am no DHCP expert, in fact I haven't looked at RFC2131 for
years (until today).  Hopefully I've retained enough from them to make sense
to you, I know someone (probably many) will tell me if I don't.

I agree with some of what you write but ipsec-DHCP suffers from some of the
same problems as you suggest IKECFG suffers from, plus others.

"Basic Configuration"
   A definite problem for IKECFG but I do think it can be overcome with
DHCPINFORM, 5.6.4 of RFC3118 allows the DHCP server to accept authenticated
or unauthenticated DHCPINFORM and may reply with authenticated or
unauthenticated DHCPINFORM.  Besides if the ipsec client has a shared key
for local DHCP use he can reuse that key for the DHCPINFORM since K =
MAC(MK, opaque unique-id).

  ipsec-DHCP suffers from the opposite problem.  It does not contain the
rich configuration options that vendors have added to IKECFG.  While many
_are_ vendor-specific the ability to move them to DHCP servers and the
OS-specific-DHCP implementation in ipsec clients is no trivial matter and
will likely result in a non-standardized way of distributing non-DHCP,
per-user VPN configuration.

"Address Management Integration"
   Remote access is where IKECFG and ipsec-DHCP is used, and implementations
do retrieve ipsec client user configuration from RADIUS servers.  This
brings up a shortfall of ipsec-DHCP; the SGW, as a DHCP-relay agent, can not
insert options into the OFFER or ACK without breaking RFC3118 so it can not
relay any user-specific configuration from a RADIUS server (or even locally
configured) to the ipsec client.  All user configuration must then reside on
the DHCP server, or be transported via some other method.

"Address Pool Management"
   I'm not sure what you mean here, the identity of the peer is known in
IKECFG so a pool may be selected based on that.

"Reconfiguration"
   You're wrong here.  IKECFG can support reconfiguration of an IP address.
It can either be SET by the SGW to the ipsec client if the client still has
an IKE SA when approaching the time of expiry, or the expiry attribute can
be used and the ipsec client can request the address when it is about to
expire.  The address may also be tied to the IKE SA and be released when
there is no longer an IKE-SA with the client.  The address could be changed
by the SGW on a whim, and cause all sorts of havok to tcp sessions and the
ipsec tunnels, but the same would be true for ipsec-DHCP.

"Failover Support"
  This is simpler for ipsec-DHCP since the SGW _may_ know nothing of the
contents of the ACK.  However if the SGW is sniffing the ACK to glean
configuration it will need to maintain and checkpoint that extra state as
well.  The gain in my opinion is minimal.

"Authentication"
  The SGW has no need to issue an authentication option with the clients ID.
It can use its own.  From a quick glean of RFC3118 the client identifier is
opaque to the server and only serves to uniquely identify a client and
generate or lookup a key for authentication of the DHCP* packet.  Such a
client identifier could (must?) be created by the SGW for any ipsec client
requesting an IP address via modecfg and offer the same shared key
authentication available to ipsec-DHCP clients.

Regarding this...
>    Since RFC 2131 [3] assumes that a DHCPREQUEST will not contain a
>    filled in giaddr field when generated during RENEWING state, the
>    DHCPACK will be sent directly to the client, which will not be
>    expecting it.  As a result, it is either necessary for the security
>    gateway to add special code to avoid forwarding such packets, or to
>    wait until REBINDING state.  Since [3] does not specify that the
>    giaddr field cannot be filled in when in the REBINDING state, the
>    security gateway may put its own address in the giaddr field when in
>    REBINDING state, thereby ensuring that it can receive the renewal
>    response without treating it as a special case.

It's really implementation specific but the IKECFG SGW could implement the
special code you mention (I'm sure some do now).  It could also fill in the
giaddr and act as its own relay agent for the renew request.  Ensuring it
will receive the ACK or NACK and processing and dropping it when it does.
Any other relay agents that may be between it and the DHCP server are
required to forward the packet unmodified.

Darren



> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Bernard Aboba
> Sent: Thursday, January 30, 2003 6:09 PM
> To: ipsec@lists.tislabs.com
> Subject: Modefg considered harmful
>
>
> OK, I'll speak up.
>
> One of the major requirements for IPSRA in choosing DHCP-based
> configuration was so that we could move towards a single configuration
> model for both real and virtual interfaces -- and one which supported the
> security features that have been under development over the last few years
> -- such as RFC 3118 and was compatible with both IPv4 and IPv6.
>
> Among other things, Modecfg does not satisfy those requirements,
> as outlined in RFC 3456. In particular, were Modecfg to be extended to
> IPv6, it would constitute an alternative to RS/RA, complicating the IPv6
> architecture.
>
> In addition, Modecfg is incompatible with DHCP security as
> described in RFC 3118, so that contrary to your statements below, it is
> *not* easy to integrate it correctly with DHCP.
>
> There are lots of other reasons why Modecfg is a bad idea -- and why the
> IPSRA WG chose not to select it. In fact, there are so many that an entire
> appendix in RFC 3456 had to be devoted to listing them all (and I left out
> quite a few). Here is the text:
>
> ======================================================================
> Appendix - IKECFG evaluation
>
>    Alternatives to DHCPv4, such as ISAKMP CFG, described in [13], do not
>    meet the basic requirements described in [21], nor do they provide
>    the additional capabilities of DHCPv4.
>
>    Basic configuration
>          While ISAKMP CFG can provide for IP address assignment as well
>          as configuration of a few additional parameters such as the DNS
>          server and WINS server addresses, the rich configuration
>          facilities of DHCPv4 are not supported.  Past experience with
>          similar configuration mechanisms within PPP IPCP [11] has
>          taught us that it is not viable merely to support minimal
>          configuration.  Eventually, either much of the functionality
>          embodied in the DHCPv4 options [4] is duplicated or support for
>          DHCPINFORM [3] will be required.
>
>    Address management integration
>          Since IKECFG is not integrated with existing IP address
>          management facilities, it is difficult to integrate it with
>          policy management services that may be dependent on the user to
>          IP address binding.
>
>    Address pool management
>          IKECFG does not provide a mechanism for the remote host to
>          indicate a preference for a particular address pool.  This
>          makes it difficult to support address pool management.
>
>    Reconfiguration
>          IKECFG does not support the concept of configuration leases or
>          reconfiguration.
>
>    Fail-over support
>          Since IKECFG creates a separate pool of address state, it
>          complicates the provisioning of network utility-class
>          reliability, both in the IP address management system and in
>          the security gateways themselves.
>
>    Security and simplicity
>          As past history with PPP IPCP demonstrates, once it is decided
>          to provide non-integrated address management and configuration
>          facilities within IKE, it will be difficult to limit the
>          duplication of effort to address assignment.  Instead, it will
>          be tempting to also duplicate the configuration, authentication
>          and fail-over facilities of DHCPv4.  This duplication will
>          greatly increase the scope of work, eventually compromising the
>          security of IKE.
>
>    Authentication
>          While IKECFG can support mutual authentication of the IPsec
>          tunnel endpoints, it is difficult to integrate IKECFG with
>          DHCPv4 authentication [5].  This is because the security
>          gateway will not typically have access to the client
>          credentials necessary to issue an DHCPv4 authentication option
>          on the client's behalf.
>
>    As a result, security gateways implementing IKECFG typically request
>    allocation of an IP address on their own behalf, and then assign this
>    to the client via IKECFG.  Since IKECFG does not support the concept
>    of an address lease, the security gateway will need to do the renewal
>    itself.  This complicates the renewal process.
>
>    Since RFC 2131 [3] assumes that a DHCPREQUEST will not contain a
>    filled in giaddr field when generated during RENEWING state, the
>    DHCPACK will be sent directly to the client, which will not be
>    expecting it.  As a result, it is either necessary for the security
>    gateway to add special code to avoid forwarding such packets, or to
>    wait until REBINDING state.  Since [3] does not specify that the
>    giaddr field cannot be filled in when in the REBINDING state, the
>    security gateway may put its own address in the giaddr field when in
>    REBINDING state, thereby ensuring that it can receive the renewal
>    response without treating it as a special case.

[ddukes] This is really implementation specific but the IKECFG SGW could
implement the special code you mention.  It could also fill in the giaddr
and act as its own relay agent for the renew request.  Ensuring it will
receive the ACK or NACK and dropping it when it does.  Any other relay
agents that may be between it and the DHCP server are required to forward
the packet unmodified.


> ======================================================================
> B) DHCP-based vs. MODECFG style remote access configuration
> -----------------------------------------------------------
>
> Currently, draft-ietf-ipsec-ikev2-04.txt handles remote access via a
> Configuration payload with defined attributes.  An alternate mechanism
> involves using tunneled DHCP requests.  The latter approach is about to be
> published as an RFC by the IPSRA working group.  Proponents of this method
> argue that it is more powerful than modecfg (because of the extensibility
> and large number of options already specified for DHCP; for example, being
> able to specify DNS, time, print, or WINS servers, and so on.)  It is also
> argued that it requires less code on the server/firewall, since an
> existing DHCP server can be used.
>
> Proponents of the modecfg approach argue that many implementation already
> have support for modecfg, and that setting up sort-lived specialized
> tunnels to allow the DHCP packets to flow through the gateway is kludgy,
> and requires multiple special case entries into packet forwarding tables.
> Modecfg proponents also argue that it is also possible to transform
> modecfg requests into DHCP requests, so there are implementation choices
> that do not require reimplementation of the DHCP's address assignment
> function.  They also point out that it certainly is possible --- and in
> some ways easier --- to obtain the time, print, WINS server information by
> using DHCP (via the DHCPINFORM
> request) after the IPSEC tunnel is setup and the client address is
> assigned.
>
> Either approach seems to be workable.  It is certainly true that most of
> the people in Atlanta were implementors who were already familiar with
> modecfg, representing a large implementation community.  That being said,
> there is also some number of working group members that are in favor of an
> approach similar to draft-ietf-ipsec-dhcp-13, including Van
> Aken Dirk, Michael Richardson, and Scott G. Kelley.   One way or
> another, however we need to make a choice and move forward.
>
> Given that we have a fully specified solution in the ikev2-04 draft, and
> it would seem that while there is a sizeable minority in favor of the
> ipsec-dhcp-13 approach, the majority are comfortable with the modecfg
> based approach.  So at this point, we, as working group chairs, judge that
> the consensus is with the current approach.
>
> If there are those who feel otherwise, or who see fatal problems with the
> current approach, please speak now.
>
> 					Ted and Barabara
> 					IPSEC wg chairs
>