Subject: Re: [dhcwg] fwd: A question about rfc5739

From: Alfred Hönes <[email-masked]>
Date: Mon, 20 Dec 2010 18:49:22 +0100 (MEZ)

Hello,
Julien is right; at the time of bootstrapping access to its home
network, an IRAC (IPsec Remote Access Client, per the IPsec/IKE
terminology) acts as an IKEv2 initiator (VPN client building an
IPsec tunnel) and is not capable of sending multicast DHCPv6 requests
over the point-to-point link provided by the first IPsec-SA between
the IRAC and the IRAS.
This is precisely the use case for which the IKEv2 Configuration
paylaod has been designed.

Although I wasn't "on board" when RFC 4306 was written, I fear the
trouble that has been described on this thread was initiated by early
promises in RFC 3315:

Section 1.1, last paragraph:

   Once the client has determined the address of a server, it may under
   some circumstances send messages directly to the server using
   unicast.

It is not clear here whether such circumstances can be specified in
other documents -- like IKE specs, and I assume that the IKEv2 spec
wanted to just do that.

Section 5.3 of RFC 3315 says:

      INFORMATION-REQUEST (11) A client sends an Information-request
                         message to a server to request configuration
                                 ^^^^^^^^^^^
                         parameters without the assignment of any IP
                         addresses to the client.

... "to a server" -- that sounds equivalent to "to a specific server",
which would only be possible using a unicast address of the server.
Section 5.3 uses verbiage like "to any available server" in the cases
of Confirm and Rebind messages, which is clearly different.

Section 13, last paragraph:

   A client may send some messages directly to a server using unicast,
   as described in section 22.12.

Section 22.12 says:

   The server sends this option to a client to indicate to the client
   that it is allowed to unicast messages to the server.

I suspect that a DHCPv6 server [near-]co-located with a VPN gateway,
whose unicast IPv6 address is being distributed in IKEv2 Configuration
payloads, should behave as if it already had sent to all potential
clients the Server Unicast Option described in Section 22.12.
Conceptionally, the IKEv2 Configuration payload DHCP server attribute
takes over the role of the DHCPv6 server sending this option.

Note that IPv6 addresses for the tunnel cannot be assigned via DHCPv6
because the tunnel needs to be configured with closely restricted SA
parameters for both directions of traffic in order to carry initial
traffic securely restricted to its home link.
Thus, only Information-request exchanges are possible.
>From an IPsec/IKEv2 perspective, it is important that behavior in the
IPv6 case is as similar as possible to the IPv4 case.

I fear that the 2nd para of Section 15 is too strict for newer
scenarios:

   A server MUST discard any Solicit, Confirm, Rebind or
|  Information-request messages it receives with a unicast destination
   address.

Maybe Information-request messages should better never undergo this
check, at least if the client's address is not managed by the
respective DHCPv6 server (the client uses a unicast source address
assigned by a different method than DHCPv6).

It is not unlikely that in VPN remote access scenarios the DHCPv6
server is co-located with the VPN gateway.  Having the need (as
indicated in this thread) to also have a DHCPv6 relay agent (on the
same node!) in order to allow strict conformance to the above clause
does not make much sense, IMHO.

IIRC, in modern scenarios for Mobile IPv6 (split scenario) and mobile
ad-hoc networks, there arised requirements for clients (mobile nodes),
or even wireless access points, to direct DHCPv6 Information requests
to either a DHCP server maintained at the mobility service provider
*or* in its Home administrative domain, depending on the kind of
specific parameters.  This entails the same requirement to allow
unicast-addressing of the DHCPv6 server by the client for Information-
request exchanges.

My impression is that RFC 3315 was written with (almost) only the
scenario in mind where the DHCPv6 server assigns IPv6 addresses and
manages the leases, and it did not consider enough use cases where
DHCPv6 is employed to distribute various *above-IP* layer configuration
information only, because addresses are managed/assigned by other means
(SLAAC, manual configuration, link-layer specific protocols in wireless
environments, etc.)

So, before considering Errata for IKEv2 (and Mobile IP, and some 3GPP
protocols as well?), could we please reconsider *why* in RFC 3315,
Section 15, "Information-request" is listed at all?

Kind regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

---

From: Ted Lemon <[email-masked]>
Date: Tue, 21 Dec 2010 15:20:41 -0500

> |  Information-request messages it receives with a unicast destination

The other text that you quoted is dependent on context.   For instance, "once the client has determined the IP address of the DHCP server" implies that the client has already communicated with the DHCP server, and that that is how it got the server's IP address.

> assigned by a different method than DHCPv6).

This is not how the protocol was designed, nor how it was intended to work.   Unicasting information-request messages results in the server not having complete information about the client's connectivity, so that the client may get a different answer to an information-request than it would to a regular request.   This is why we put the restriction into the spec that servers are supposed to drop unicast packets from clients--otherwise people who didn't read the standard carefully would implement clients that unicast without permission, and we would lose substantial functionality.

> does not make much sense, IMHO.

This is because in the case we are talking about, IKE is using DHCP outside of its intended scope.

> unicast-addressing of the DHCPv6 server by the client for Information-

What's the use case here?   Why is DHCP the right solution to this problem?

> (SLAAC, manual configuration, link-layer specific protocols in wireless

We did consider SLAAC.   We did not consider tunnel endpoints, because the assumption is that if you have a tunnel, you have already configured the network stack atop which the tunnel is running, and hence DHCP is not required to configure the tunnel.

If in fact the DHCP protocol needs to support this new use case, it needs to support it in a way that does not simply give carte blanche to client implementors to ignore the restriction on the use of unicast at their discretion.

> Section 15, "Information-request" is listed at all?

I hope I've answered this question adequately... :}