Dynamic Host Configuration Working D. Hankins Group Google Internet-Draft October 1, 2011 Updates: 2131 (if approved) Intended status: Standards Track Expires: April 3, 2012 Dynamic Host Configuration Protocol DHCPINFORM Message Clarifications draft-ietf-dhc-dhcpinform-clarify-06 Abstract The DHCPINFORM message within the DHCPv4 protocol has in operation diverged incompatibly from the current defined standard. This document seeks to provide clarification of actual behaviour and guidance for some situations that were previously omitted. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 3, 2012. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as Hankins Expires April 3, 2012 [Page 1] Internet-Draft DHCPINFORM Clarify October 2011 described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . . 4 3. Client Behaviour . . . . . . . . . . . . . . . . . . . . . . . 4 4. Server Behaviour . . . . . . . . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 Hankins Expires April 3, 2012 [Page 2] Internet-Draft DHCPINFORM Clarify October 2011 1. Introduction The most recent DHCPv4 Standard [RFC2131] added a new DHCPv4 message: DHCPINFORM. The intent of the DHCPINFORM message was for clients that used manually entered fixed IPv4 addresses to still be able to get some configuration state dynamically. Since that time, however, we have seen this message used by normal DHCPv4 dynamically addressed clients; clients that have previously succeeded in receiving configuration through DHCPDISCOVER, DHCPOFFER, DHCPREQUEST, and finally DHCPACK messages. These clients are attempting DHCPINFORM messages in order to obtain additional configuration state that was not present in their lease binding. The discovery is that DHCPINFORM can be used to reach extra DHCP servers, other than the one that gave an address, which may have more configuration options available but aren't in a position to give addresses. This extra configuration state is often required by applications that were not running at system startup, when the DHCP client was initialized, and supplied by servers or services bundled with a product that cannot easily be integrated with the network's existing DHCP infrastructure and so are provided separately. Some of these DHCPINFORM clients have surfaced which run with stripped down user priveleges, but still perform some network related functions. This software does not have the capacity to determine its IPv4 address(es), nor does it know what interface(s) are present on the system, or their hardware addresses. But it can send and receive DHCP packets. Consequently, the 'ciaddr' and 'chaddr' fields have been witnessed to be empty, even though they appear to be required to be filled by RFC 2131. Clarification is sought for server behaviour when ciaddr is zero. Another set of DHCP clients set the 'chaddr' field to a fixed magic value, rather than the client's hardware address, identifying them as part of a vendor's product. Although the 'chaddr' contents were never defined by any IETF RFC to be a valid place to store 'Vendor Identifying Information', their implementors believed this field was unused by the DHCP protocol in specific regards to DHCPINFORM because a server would determine the client's hardware address through normal UDP unicast methods; IP forwarding leading to ARP [RFC0826] processing or similar. We also wish to clarify a DHCPv4 server's behaviour when it receives a DHCPINFORM via a relay (when 'giaddr' is non-zero). Section 4.1 of the DHCPv4 specification [RFC2131] seems to include DHCPINFORM->DHCPACK exchanges by describing generic behaviour for all DHCPOFFER and DHCPACK replies, and it requires that if 'giaddr' is non-zero that it "MUST" be used. But this advice does not work in Hankins Expires April 3, 2012 [Page 3] Internet-Draft DHCPINFORM Clarify October 2011 practice (due to BOOTP Relay Agent [RFC1542] requirements to use 'yiaddr' field contents, which MUST be zero as also per [RFC2131]). Furthermore, this guidance conflicts with [RFC2131] Section 4.3.5, which directs that the server replies directly to the 'ciaddr' contents when responding to DHCPINFORM, and makes no other directions for other header fields. As a result, it also does not adequately describe current operational deployments of the DHCPINFORM message exchange which definitely direct replies directly to 'ciaddr' and may (it has not been concretely determined) direct replies to the 'giaddr' first. 2. Requirements Language In this document, the key words "MAY", "MUST", "SHALL", "MUST NOT", "SHOULD", and "SHOULD NOT", are to be interpreted as described in BCP 14, RFC 2119 [RFC2119]. 3. Client Behaviour Clients are still required to fulfill the DHCPv4 requirements for DHCPINFORM messages ([RFC2131], Sections 4.4.1 and 4.4.3). But the following are clarified as in addition, or to overlay those requirements: o Clients MUST set 'ciaddr' to a working IPv4 address which they can use to receive replies. This address SHOULD be an address that is currently assigned to the interface upon which the client is transmitting its DHCPINFORM, except in the condition where the DHCP client is unable to determine a valid IP address for its host, in which case the client MUST set 'ciaddr' to all-zero. o Clients MUST set 'chaddr', 'htype', and 'hlen' to the hardware address of the interface upon which the DHCPINFORM message is being transmitted, except in the condition where the DHCP client is unable to determine this address, in which case all three fields MUST be set all-zero. o Clients MUST set the 'flags' field to zero. This means that the client MUST NOT set the 'BROADCAST' flag, and MUST be capable of receiving IP unicasts. o Clients SHOULD direct their DHCPINFORM via unicast UDP to the IPv4 address contained in the Server Identifier [RFC2132] option, if they have a currently active binding from previous DHCPREQUEST message exchanges. It MAY be unicast to a known DHCP server, or otherwise broadcast to the appropriate IPv4 broadcast address on Hankins Expires April 3, 2012 [Page 4] Internet-Draft DHCPINFORM Clarify October 2011 the interface being configured. 4. Server Behaviour DHCPv4 server behaviour in processing DHCPINFORM messages is a more difficult question to answer, due to inconsistent client behaviour and conflicting directions in RFC 2131. The following is intended to be a more complete reference. First, upon receiving a DHCPINFORM, a DHCPv4 Server MUST determine the client's "relevant IPv4 address" according to the following in order of priority: 1. The Subnet Selection Option [RFC3011], if it is present. 2. The 'ciaddr' field, if it is non-zero. 3. The Relay Agent Link Selection Sub-Option [RFC3527], if it is present in a Relay Agent Information Option [RFC3046]. 4. The 'giaddr' field, if it is non-zero. 5. The IPv4 source address field, if it is non-zero. 6. The DHCPv4 Server's address on the interface on which the DHCPINFORM was received. The DHCPv4 server checks to see if the "relevant IPv4 address" is within a range or subnet over which it holds authority, or if it is configured to respond. It will manufacture a DHCPACK response with configuration values appropriate for the "relevant IPv4 address". If the "relevant IPv4 address" is from the 'ciaddr' field (because the Subnet Selection Option was not provided, and the 'ciaddr' field is non-zero), the server MAY also inspect that address's current lease in order to source configuration specific to the host, but MUST NOT modify the lease in any way. In the DHCPACK reply: o The 'htype', 'hlen', 'chaddr', 'ciaddr', 'xid', 'flags' (with the exception noted below), and 'giaddr' fields MUST be copied from the client's DHCPINFORM. o The 'hops' field MUST be zero. o The 'secs' field MUST be zero. Hankins Expires April 3, 2012 [Page 5] Internet-Draft DHCPINFORM Clarify October 2011 o The 'yiaddr' field MUST be zero. o The 'siaddr' field MUST be zero. o The 'sname' and 'file' fields MAY be used exclusively for 'option overloading', but MUST be all-zero otherwise. o The 'options' field MUST be filled as described in RFC 2131 Section 4.3.1. Next, the DHCPv4 server MUST determine the "reply address and port" according to the first of the following conditions it finds a valid reply address for, in order: 1. If the 'ciaddr' field is non-zero, the server selects its contents as an IPv4 address and port 68 ('DHCP client'). 2. If the 'giaddr' field is non-zero, the server selects its contents as an IPv4 address and port 67 ('DHCP server'). 3. If the IPv4 source address field is non-zero, the server selects its contents as an IPv4 address and port 68 ('DHCP client') 4. The server selects the limited broadcast address (all-ones) and port 68 ('DHCP client'). At this point, the DHCPv4 server verifies that it holds configuration authority over the reply address (or link in case of limited broadcast address) it has selected to transmit the reply to. If the server has not been configured to hold authority over this address, it MUST NOT reply. It SHOULD increment a counter visible to the operator but SHOULD NOT log an error (unless a mechanism is used to suppress repeated log messages). See the Security section (Section 5) for the rationale behind this direction. Note very carefully that a DHCPv4 server will send replies directly to a DHCPv4 client by way of 'ciaddr' even if the DHCPINFORM message was relayed. Note that this means DHCPINFORM processing is intentionally broken in deployments where the client's address space is unreachable by the DHCPv4 server. In such cases, the server should probably be configured not to reply to DHCPINFORMs. Now, the server performs an exception to assist relay agents. If it selected the 'giaddr' as the destination address and port, then it MUST set the 'BROADCAST' bit in the flags field true, no matter what its value was in the client's DHCPINFORM message, without altering the other bits of the flag field. Otherwise, the response could not be delivered; a BOOTP Relay Agent [RFC1542] is required to direct Hankins Expires April 3, 2012 [Page 6] Internet-Draft DHCPINFORM Clarify October 2011 unicast server replies to the 'chaddr' and 'yiaddr' field contents, but 'chaddr' is not reliably filled, and 'yiaddr' is required to be all-zero. Setting the broadcast flag assists the relay agent in locating the client by informing it to perform a local limited broadcast. Having selected a destination IPv4 address and port number, the last step is to select a destination link layer address. For the all-ones limited broadcast address, the DHCPv4 server MUST use the all-ones broadcast hardware address. For all other (unicast) destination selections, the DHCPv4 server MUST use its host operating system's usual methods to determine hardware addressing, as by IP forwarding and subsequent address resolution (such as through ARP [RFC0826]). Note that the DHCPv4 server MAY have seeded its ARP cache from a previous stateful exchange with the client (from 'chaddr' contents while processing a DHCPREQUEST message, due to the requirement of DHCPv4 servers to unicast some replies before clients will process ARP), and some DHCPv4 software MAY still use 'chaddr' contents to direct replies to directly connected clients. Consequently, DHCPINFORM can not be reasonably expected to instigate an immediate ARP broadcast, nor can 'chaddr' contents be used for any purpose other than to carry the unicast hardware address with which a client might reasonably be reached. 5. Security Considerations As with all DHCP messages, DHCPINFORM and DHCPACK replies contain no capacity for encryption, and all packet contents must be presumed readable in the clear. In particular, and as outlined above, in some circumstances the packets may be broadcast and so more easily intercepted than most other messages. Authentication for DHCPv4 Messages [RFC3118] does exist, but is not well deployed. Care should be taken in the degree to which configuration parameters provided by DHCPv4 are trusted, as the replies can be easily spoofed by any eavesdropper. Again noting that packets may be broadcast under some circumstances, the BOOTP header Transaction Id field ("XID") is insufficient protection from man-in- the-middle attacks. A relay agent receives replies via unicast UDP messages from a DHCP server, and may broadcast these packets on the inside-facing network. If an outside attacker was aware of this relay agent and its unicast address, this facility could be used to produce broadcast storms on Hankins Expires April 3, 2012 [Page 7] Internet-Draft DHCPINFORM Clarify October 2011 the network. Care should be taken to ensure that the relay agent is not open to this kind of attack, possibly making use of Relay Agent Authentication [RFC4030] to ensure that a DHCPv4 server can not be induced to sending bogus replies to the relay. This protocol uses the 'ciaddr' field contents to direct replies, which may be set blindly by the client to any value, regardless of IP source address validation or related filter restrictions. If an attacker were to identify a number of DHCPv4 servers which reply to addresses not under their authority to configure, and those servers had enough large DHCPv4 options in configuration to request, it could represent a significant amplification vector in straight packet-load Denial-of-Service attacks. For this reason, servers MUST NOT make replies to addresses not explicitly configured under their authority to configure. 6. IANA Considerations This document has no action for IANA. 7. Acknowledgements This document has been reviewed and improved by the comments of several people, but the author would like to take a moment to thank Alfred Hoenes, who has submitted revised text for this document. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997. [RFC3011] Waters, G., "The IPv4 Subnet Selection Option for DHCP", RFC 3011, November 2000. [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, January 2001. Hankins Expires April 3, 2012 [Page 8] Internet-Draft DHCPINFORM Clarify October 2011 [RFC3527] Kinnear, K., Stapp, M., Johnson, R., and J. Kumarasamy, "Link Selection sub-option for the Relay Agent Information Option for DHCPv4", RFC 3527, April 2003. 8.2. Informative References [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware", STD 37, RFC 826, November 1982. [RFC1542] Wimer, W., "Clarifications and Extensions for the Bootstrap Protocol", RFC 1542, October 1993. [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001. [RFC4030] Stapp, M. and T. Lemon, "The Authentication Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option", RFC 4030, March 2005. Author's Address David W. Hankins Google, Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 USA Email: dhankins@google.com Hankins Expires April 3, 2012 [Page 9]