idnits 2.17.1 draft-ietf-dhc-dhcpinform-clarify-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC2131, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). (Using the creation date from RFC2131, updated by this document, for RFC5378 checks: 1994-11-15) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 1, 2011) is 4591 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Dynamic Host Configuration Working D. Hankins 3 Group Google 4 Internet-Draft October 1, 2011 5 Updates: 2131 (if approved) 6 Intended status: Standards Track 7 Expires: April 3, 2012 9 Dynamic Host Configuration Protocol DHCPINFORM Message Clarifications 10 draft-ietf-dhc-dhcpinform-clarify-06 12 Abstract 14 The DHCPINFORM message within the DHCPv4 protocol has in operation 15 diverged incompatibly from the current defined standard. This 16 document seeks to provide clarification of actual behaviour and 17 guidance for some situations that were previously omitted. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on April 3, 2012. 36 Copyright Notice 38 Copyright (c) 2011 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Requirements Language . . . . . . . . . . . . . . . . . . . . . 4 55 3. Client Behaviour . . . . . . . . . . . . . . . . . . . . . . . 4 56 4. Server Behaviour . . . . . . . . . . . . . . . . . . . . . . . 5 57 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 58 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 59 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 60 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 61 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 62 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 65 1. Introduction 67 The most recent DHCPv4 Standard [RFC2131] added a new DHCPv4 message: 68 DHCPINFORM. The intent of the DHCPINFORM message was for clients 69 that used manually entered fixed IPv4 addresses to still be able to 70 get some configuration state dynamically. Since that time, however, 71 we have seen this message used by normal DHCPv4 dynamically addressed 72 clients; clients that have previously succeeded in receiving 73 configuration through DHCPDISCOVER, DHCPOFFER, DHCPREQUEST, and 74 finally DHCPACK messages. 76 These clients are attempting DHCPINFORM messages in order to obtain 77 additional configuration state that was not present in their lease 78 binding. The discovery is that DHCPINFORM can be used to reach extra 79 DHCP servers, other than the one that gave an address, which may have 80 more configuration options available but aren't in a position to give 81 addresses. This extra configuration state is often required by 82 applications that were not running at system startup, when the DHCP 83 client was initialized, and supplied by servers or services bundled 84 with a product that cannot easily be integrated with the network's 85 existing DHCP infrastructure and so are provided separately. 87 Some of these DHCPINFORM clients have surfaced which run with 88 stripped down user priveleges, but still perform some network related 89 functions. This software does not have the capacity to determine its 90 IPv4 address(es), nor does it know what interface(s) are present on 91 the system, or their hardware addresses. But it can send and receive 92 DHCP packets. Consequently, the 'ciaddr' and 'chaddr' fields have 93 been witnessed to be empty, even though they appear to be required to 94 be filled by RFC 2131. Clarification is sought for server behaviour 95 when ciaddr is zero. 97 Another set of DHCP clients set the 'chaddr' field to a fixed magic 98 value, rather than the client's hardware address, identifying them as 99 part of a vendor's product. Although the 'chaddr' contents were 100 never defined by any IETF RFC to be a valid place to store 'Vendor 101 Identifying Information', their implementors believed this field was 102 unused by the DHCP protocol in specific regards to DHCPINFORM because 103 a server would determine the client's hardware address through normal 104 UDP unicast methods; IP forwarding leading to ARP [RFC0826] 105 processing or similar. 107 We also wish to clarify a DHCPv4 server's behaviour when it receives 108 a DHCPINFORM via a relay (when 'giaddr' is non-zero). Section 4.1 of 109 the DHCPv4 specification [RFC2131] seems to include 110 DHCPINFORM->DHCPACK exchanges by describing generic behaviour for all 111 DHCPOFFER and DHCPACK replies, and it requires that if 'giaddr' is 112 non-zero that it "MUST" be used. But this advice does not work in 113 practice (due to BOOTP Relay Agent [RFC1542] requirements to use 114 'yiaddr' field contents, which MUST be zero as also per [RFC2131]). 115 Furthermore, this guidance conflicts with [RFC2131] Section 4.3.5, 116 which directs that the server replies directly to the 'ciaddr' 117 contents when responding to DHCPINFORM, and makes no other directions 118 for other header fields. As a result, it also does not adequately 119 describe current operational deployments of the DHCPINFORM message 120 exchange which definitely direct replies directly to 'ciaddr' and may 121 (it has not been concretely determined) direct replies to the 122 'giaddr' first. 124 2. Requirements Language 126 In this document, the key words "MAY", "MUST", "SHALL", "MUST NOT", 127 "SHOULD", and "SHOULD NOT", are to be interpreted as described in BCP 128 14, RFC 2119 [RFC2119]. 130 3. Client Behaviour 132 Clients are still required to fulfill the DHCPv4 requirements for 133 DHCPINFORM messages ([RFC2131], Sections 4.4.1 and 4.4.3). But the 134 following are clarified as in addition, or to overlay those 135 requirements: 137 o Clients MUST set 'ciaddr' to a working IPv4 address which they can 138 use to receive replies. This address SHOULD be an address that is 139 currently assigned to the interface upon which the client is 140 transmitting its DHCPINFORM, except in the condition where the 141 DHCP client is unable to determine a valid IP address for its 142 host, in which case the client MUST set 'ciaddr' to all-zero. 144 o Clients MUST set 'chaddr', 'htype', and 'hlen' to the hardware 145 address of the interface upon which the DHCPINFORM message is 146 being transmitted, except in the condition where the DHCP client 147 is unable to determine this address, in which case all three 148 fields MUST be set all-zero. 150 o Clients MUST set the 'flags' field to zero. This means that the 151 client MUST NOT set the 'BROADCAST' flag, and MUST be capable of 152 receiving IP unicasts. 154 o Clients SHOULD direct their DHCPINFORM via unicast UDP to the IPv4 155 address contained in the Server Identifier [RFC2132] option, if 156 they have a currently active binding from previous DHCPREQUEST 157 message exchanges. It MAY be unicast to a known DHCP server, or 158 otherwise broadcast to the appropriate IPv4 broadcast address on 159 the interface being configured. 161 4. Server Behaviour 163 DHCPv4 server behaviour in processing DHCPINFORM messages is a more 164 difficult question to answer, due to inconsistent client behaviour 165 and conflicting directions in RFC 2131. The following is intended to 166 be a more complete reference. 168 First, upon receiving a DHCPINFORM, a DHCPv4 Server MUST determine 169 the client's "relevant IPv4 address" according to the following in 170 order of priority: 172 1. The Subnet Selection Option [RFC3011], if it is present. 174 2. The 'ciaddr' field, if it is non-zero. 176 3. The Relay Agent Link Selection Sub-Option [RFC3527], if it is 177 present in a Relay Agent Information Option [RFC3046]. 179 4. The 'giaddr' field, if it is non-zero. 181 5. The IPv4 source address field, if it is non-zero. 183 6. The DHCPv4 Server's address on the interface on which the 184 DHCPINFORM was received. 186 The DHCPv4 server checks to see if the "relevant IPv4 address" is 187 within a range or subnet over which it holds authority, or if it is 188 configured to respond. It will manufacture a DHCPACK response with 189 configuration values appropriate for the "relevant IPv4 address". If 190 the "relevant IPv4 address" is from the 'ciaddr' field (because the 191 Subnet Selection Option was not provided, and the 'ciaddr' field is 192 non-zero), the server MAY also inspect that address's current lease 193 in order to source configuration specific to the host, but MUST NOT 194 modify the lease in any way. 196 In the DHCPACK reply: 198 o The 'htype', 'hlen', 'chaddr', 'ciaddr', 'xid', 'flags' (with the 199 exception noted below), and 'giaddr' fields MUST be copied from 200 the client's DHCPINFORM. 202 o The 'hops' field MUST be zero. 204 o The 'secs' field MUST be zero. 206 o The 'yiaddr' field MUST be zero. 208 o The 'siaddr' field MUST be zero. 210 o The 'sname' and 'file' fields MAY be used exclusively for 'option 211 overloading', but MUST be all-zero otherwise. 213 o The 'options' field MUST be filled as described in RFC 2131 214 Section 4.3.1. 216 Next, the DHCPv4 server MUST determine the "reply address and port" 217 according to the first of the following conditions it finds a valid 218 reply address for, in order: 220 1. If the 'ciaddr' field is non-zero, the server selects its 221 contents as an IPv4 address and port 68 ('DHCP client'). 223 2. If the 'giaddr' field is non-zero, the server selects its 224 contents as an IPv4 address and port 67 ('DHCP server'). 226 3. If the IPv4 source address field is non-zero, the server selects 227 its contents as an IPv4 address and port 68 ('DHCP client') 229 4. The server selects the limited broadcast address (all-ones) and 230 port 68 ('DHCP client'). 232 At this point, the DHCPv4 server verifies that it holds configuration 233 authority over the reply address (or link in case of limited 234 broadcast address) it has selected to transmit the reply to. If the 235 server has not been configured to hold authority over this address, 236 it MUST NOT reply. It SHOULD increment a counter visible to the 237 operator but SHOULD NOT log an error (unless a mechanism is used to 238 suppress repeated log messages). See the Security section 239 (Section 5) for the rationale behind this direction. 241 Note very carefully that a DHCPv4 server will send replies directly 242 to a DHCPv4 client by way of 'ciaddr' even if the DHCPINFORM message 243 was relayed. Note that this means DHCPINFORM processing is 244 intentionally broken in deployments where the client's address space 245 is unreachable by the DHCPv4 server. In such cases, the server 246 should probably be configured not to reply to DHCPINFORMs. 248 Now, the server performs an exception to assist relay agents. If it 249 selected the 'giaddr' as the destination address and port, then it 250 MUST set the 'BROADCAST' bit in the flags field true, no matter what 251 its value was in the client's DHCPINFORM message, without altering 252 the other bits of the flag field. Otherwise, the response could not 253 be delivered; a BOOTP Relay Agent [RFC1542] is required to direct 254 unicast server replies to the 'chaddr' and 'yiaddr' field contents, 255 but 'chaddr' is not reliably filled, and 'yiaddr' is required to be 256 all-zero. Setting the broadcast flag assists the relay agent in 257 locating the client by informing it to perform a local limited 258 broadcast. 260 Having selected a destination IPv4 address and port number, the last 261 step is to select a destination link layer address. 263 For the all-ones limited broadcast address, the DHCPv4 server MUST 264 use the all-ones broadcast hardware address. 266 For all other (unicast) destination selections, the DHCPv4 server 267 MUST use its host operating system's usual methods to determine 268 hardware addressing, as by IP forwarding and subsequent address 269 resolution (such as through ARP [RFC0826]). Note that the DHCPv4 270 server MAY have seeded its ARP cache from a previous stateful 271 exchange with the client (from 'chaddr' contents while processing a 272 DHCPREQUEST message, due to the requirement of DHCPv4 servers to 273 unicast some replies before clients will process ARP), and some 274 DHCPv4 software MAY still use 'chaddr' contents to direct replies to 275 directly connected clients. Consequently, DHCPINFORM can not be 276 reasonably expected to instigate an immediate ARP broadcast, nor can 277 'chaddr' contents be used for any purpose other than to carry the 278 unicast hardware address with which a client might reasonably be 279 reached. 281 5. Security Considerations 283 As with all DHCP messages, DHCPINFORM and DHCPACK replies contain no 284 capacity for encryption, and all packet contents must be presumed 285 readable in the clear. In particular, and as outlined above, in some 286 circumstances the packets may be broadcast and so more easily 287 intercepted than most other messages. 289 Authentication for DHCPv4 Messages [RFC3118] does exist, but is not 290 well deployed. Care should be taken in the degree to which 291 configuration parameters provided by DHCPv4 are trusted, as the 292 replies can be easily spoofed by any eavesdropper. Again noting that 293 packets may be broadcast under some circumstances, the BOOTP header 294 Transaction Id field ("XID") is insufficient protection from man-in- 295 the-middle attacks. 297 A relay agent receives replies via unicast UDP messages from a DHCP 298 server, and may broadcast these packets on the inside-facing network. 299 If an outside attacker was aware of this relay agent and its unicast 300 address, this facility could be used to produce broadcast storms on 301 the network. Care should be taken to ensure that the relay agent is 302 not open to this kind of attack, possibly making use of Relay Agent 303 Authentication [RFC4030] to ensure that a DHCPv4 server can not be 304 induced to sending bogus replies to the relay. 306 This protocol uses the 'ciaddr' field contents to direct replies, 307 which may be set blindly by the client to any value, regardless of IP 308 source address validation or related filter restrictions. If an 309 attacker were to identify a number of DHCPv4 servers which reply to 310 addresses not under their authority to configure, and those servers 311 had enough large DHCPv4 options in configuration to request, it could 312 represent a significant amplification vector in straight packet-load 313 Denial-of-Service attacks. For this reason, servers MUST NOT make 314 replies to addresses not explicitly configured under their authority 315 to configure. 317 6. IANA Considerations 319 This document has no action for IANA. 321 7. Acknowledgements 323 This document has been reviewed and improved by the comments of 324 several people, but the author would like to take a moment to thank 325 Alfred Hoenes, who has submitted revised text for this document. 327 8. References 329 8.1. Normative References 331 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 332 Requirement Levels", BCP 14, RFC 2119, March 1997. 334 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 335 RFC 2131, March 1997. 337 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 338 Extensions", RFC 2132, March 1997. 340 [RFC3011] Waters, G., "The IPv4 Subnet Selection Option for DHCP", 341 RFC 3011, November 2000. 343 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", 344 RFC 3046, January 2001. 346 [RFC3527] Kinnear, K., Stapp, M., Johnson, R., and J. Kumarasamy, 347 "Link Selection sub-option for the Relay Agent Information 348 Option for DHCPv4", RFC 3527, April 2003. 350 8.2. Informative References 352 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 353 converting network protocol addresses to 48.bit Ethernet 354 address for transmission on Ethernet hardware", STD 37, 355 RFC 826, November 1982. 357 [RFC1542] Wimer, W., "Clarifications and Extensions for the 358 Bootstrap Protocol", RFC 1542, October 1993. 360 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 361 Messages", RFC 3118, June 2001. 363 [RFC4030] Stapp, M. and T. Lemon, "The Authentication Suboption for 364 the Dynamic Host Configuration Protocol (DHCP) Relay Agent 365 Option", RFC 4030, March 2005. 367 Author's Address 369 David W. Hankins 370 Google, Inc. 371 1600 Amphitheatre Parkway 372 Mountain View, CA 94043 373 USA 375 Email: dhankins@google.com