Dynamic Host Configuration Working D. Hankins Group ISC Internet-Draft August 22, 2008 Updates: 2131 (if approved) Intended status: Standards Track Expires: February 23, 2009 Dynamic Host Configuration Protocol DHCPINFORM Message Clarifications draft-dhankins-dhcpinform-clarify-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on February 23, 2009. Abstract The DHCPINFORM message within the DHCPv4 protocol has in operation diverged incompatibly from the previously defined standard, and some questions about DHCPv4 server behaviour remain unclear. Hankins Expires February 23, 2009 [Page 1]
Internet-Draft DHCPINFORM Clarify August 2008 Table of Contents 1. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Client Behaviour . . . . . . . . . . . . . . . . . . . . . . . 4 4. Server Behaviour . . . . . . . . . . . . . . . . . . . . . . . 4 5. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . . . 10 Hankins Expires February 23, 2009 [Page 2]
Internet-Draft DHCPINFORM Clarify August 2008 1. Requirements Language In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL", "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as described in BCP 14, RFC 2119 [RFC2119]. 2. 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 dynamic addressing 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 isn't in a position to give addresses. Some of these DHCPINFORM clients have surfaced which run with stripped down user priveleges, but still performs 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 (MAC) addresses. But it can send and receive DHCP packets. Consequently, the 'ciaddr' and 'chaddr' fields have been witnessed to be empty, even though they are required to be filled by RFC2131. Another set of DHCP clients set the 'chaddr' field to a fixed magic value, rather than the client's MAC address, identifying them as part of a vendor's product. This is resulting from confusion about where a DHCPv4 server should source the destination MAC address in any replies it makes; from ARP [RFC0826], from the packet source field, or from the chaddr contents. We also wish to clarify the DHCPv4 server's behaviour when it receives a DHCPINFORM via a relay - when 'giaddr' is set nonzero, especially when the ciaddr and chaddr fields are zero or garbage. Hankins Expires February 23, 2009 [Page 3]
Internet-Draft DHCPINFORM Clarify August 2008 3. Client Behaviour Clients are still required to fulfill DHCPv4 Requirements [RFC2131] for DHCPINFORM messages. But the following are clarified as in addition, or to overlay those requirements: o Clients SHOULD set 'ciaddr' to a working IPv4 address they can receive replies on. Having done so, the client WILL receive replies at this address. No other value is valid, but clients MAY set the field zero if their IPv4 address is unknown. o Clients SHOULD set 'chaddr', 'htype', and 'hlen' to the actual L2 address of the interface being used, and expect to receive replies to. No other value is valid, but clients MAY set the fields all zero if the hardware address is unknown. o Clients MUST NOT set the 'BROADCAST' flag, unless the client is not capable of receiving IPv4 unciasts, in which case it MUST set the 'BROADCAST' flag. o Clients SHOULD direct their DHCPINFORM via unicast UDP to the IPv4 address contained in the Server Identifier [RFC2132] option, if they have an active binding. 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 RFC2131. 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 and supported. 2. The 'ciaddr' field, if it is nonzero. 3. The Relay Agent Link Selection Sub-Option [RFC3046], if it is present in a Relay Agent Information Option [RFC3046] in the DHCPINFORM packet (never cached from a previous exchange). 4. The 'giaddr' field, if it is nonzero. Hankins Expires February 23, 2009 [Page 4]
Internet-Draft DHCPINFORM Clarify August 2008 5. The IPv4 source address field, if it is nonzero. 6. The DHCPv4 Server's address on the interface the packet was received upon. The DHCPv4 server checks to see if the "relevant IPv4 address" is within a range or subnet over which it holds authority, and is configured to respond. It will manufacture a DHCPACK response with configuration values appropriate for the "relevant IPv4 address". In the manufactured response: o The 'htype', 'hlen', 'chaddr', 'ciaddr', 'xid', 'flags' (with the excpetion 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. o The 'yiaddr' field MUST be zero. o The 'siaddr' field MUST be zero. o The 'sname' field MUST be all-zeroes. o The 'file' field MUST be all-zeroes. o The 'options' field MUST be filled as described in RFC2131 Section 4.3.1. Next, the DHCPv4 server MUST determine the "reply IPv4 address and port" according to the following priority list: 1. The 'ciaddr' field and port 68 ('DHCP client'), if it is nonzero. 2. The 'giaddr' field and port 67 ('DHCP server'), if it is nonzero. 3. The IPv4 source address field and port 68 ('DHCP client'), if it is nonzero. 4. The limited broadcast address (all ones) and port 68 ('DHCP client'). Note very carefully that a DHCPv4 server will send replies directly to a DHCPv4 client by way of 'ciaddr' even if the message is relayed. Note that this means DHCPINFORM processing is intentionally broken in deployments where the client's address space is unreachable by the Hankins Expires February 23, 2009 [Page 5]
Internet-Draft DHCPINFORM Clarify August 2008 DHCPv4 server. In such cases, the server should probably be configured not to reply to DHCPINFORMs. Now, the server performs an exception to assist in 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. Having selected a destination IPv4 address and port number, the last step is to select a destination link layer address. Here's where it gets hard to figure out what order to put things in, the following are what the author thinks needs to be covered. The server is going to use a BSD socket probably to send the unicast reply to any of the 'ciaddr', 'giaddr', or IP source address versions. But it's advantageous to permit a server to send to the chaddr contents or source MAC address when the client is directly attached to avoid ARP broadcasts (and on some IP stacks, the ARP table would have been filled on packet reception anyway). Obviously the server is going to use the broadcast (all ones) MAC address when the BROADCAST bit is set, or the limited broadcast address is selected. Under construction. 5. Notes This section will self-destruct as (if) we near last-call. It is a list of RFC2131 notations I've used as a guide to navigate this maze. o Section 4.1: "If the BROADCAST bit is cleared to 0, the message SHOULD be sent as an IP unicast to the IP address specified in the 'yiaddr' field and the link-layer address specified in the 'chaddr' field." But in other sections we say that 'yiaddr' is set zero. So any message via a relay has to be broadcast in response. I don't know if relays check for 'yiaddr' equal zero and downgrade to broadcast, so I think it's best to set this bit just to help them out (this is like DHCPNAK replies, where 'yiaddr' is also zero). o Section 4.4.1, Table 5, uses the same column for both DHCPINFORM and DHCPDISCOVER. It is clear that both DHCPINFORM and DHCPDISCOVER make the same use of chaddr/htype/hlen. It is also clear that 'ciaddr' is zero on DHCPDISCOVER - but very clearly nonzero ("the client's network address") on DHCPINFORM. Since this is in the same column, and uses a wording that is similar to Hankins Expires February 23, 2009 [Page 6]
Internet-Draft DHCPINFORM Clarify August 2008 other columns (which have an "or" in them), it may be overlooked if you weren't looking closely enough. In any case, 'ciaddr' very clearly must not be zero as far as RFC2131 is concerned. o Section 3.4: "Servers receiving a DHCPINFORM message construct a DHCPACK message with any local configuration parameters appropriate for the client without: allocating a new address, checking for an existing binding, filling in 'yiaddr' or including lease time parameters." ...snip... "The server SHOULD check the network address in a DHCPINFORM message for consistency, but MUST NOT check for an existing lease. The server forms a DHCPACK message containing the configuration parameters for the requesting client and sends the DHCPACK message directly to the client." This is kind of problematic. Our DHCP software lets you scope configuration parameters in a tree hierarchy, and ths includes right on the lease itself. So the MUST NOT (and the non-normative language before) that keeps us from checking for an existing lease (very vague language) also means we may give different answers to the same client at DORA time versus DHCPINFORM time. The client actually over-writes its config with the DHCPINFORM values and becomes broken. I think these two validations in RFC2131 can be simplified to one validation, which is even simpler: The server validates that the client's address is one which it is responsible for configuring. o Again Section 3.4: "The servers SHOULD unicast the DHCPACK reply to the address given in the 'ciaddr' field of the DHCPINFORM message." That 'SHOULD' kind of makes you wonder what /else/ you would do. o Section 4.3.5: "The server responds to a DHCPINFORM message by sending a DHCPACK message directly to the address given in the 'ciaddr' field of the DHCPINFORM message. The server MUST NOT send a lease expiration time to the client and SHOULD NOT fill in 'yiaddr'." So, a non-normative indication for 'ciaddr', followed by a normative SHOULD NOT for 'yiaddr' (conflicts with non- normative language in 3.4 above which makes it sound like yiaddr is zeroed). Curious. Section 4.3.1 Table 3 seems to indicate 'yiaddr' is always set on DHCPACK to the "IP address assigned to client", with no reservation for message type (other fields in this table make distinctions for DHCPINFORM). o Section 4.3.1 Table 3 lists in the DHCPACK column a lot of strange values when processing a DHCPINFORM packet. Namely, "'xid' from client DHCPREQUEST message". That is a strange thing to hang on to from the previous DORA exchange, and it's supposed that a client might not even do the DORA exchange (or might do it with a different server). Obviously this was just overlooked, but it Hankins Expires February 23, 2009 [Page 7]
Internet-Draft DHCPINFORM Clarify August 2008 brings everything in this table into question. We should remove those questions. 6. 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 messges. 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 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. 7. IANA Considerations This document has no action for IANA. 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. Hankins Expires February 23, 2009 [Page 8]
Internet-Draft DHCPINFORM Clarify August 2008 [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. 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. [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 Internet Systems Consortium, Inc. 950 Charter Street Redwood City, CA 94063 US Phone: +1 650 423 1307 Email: David_Hankins@isc.org Hankins Expires February 23, 2009 [Page 9]
Internet-Draft DHCPINFORM Clarify August 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Hankins Expires February 23, 2009 [Page 10]