idnits 2.17.1 draft-ietf-dnsext-dhcid-rr-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 7 instances of lines with control characters in the document. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 4 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 24, 2003) is 7462 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) -- Looks like a reference, but probably isn't: 'TBD' on line 116 == Unused Reference: '9' is defined on line 336, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 339, but no explicit reference was found in the text -- No information found for draft-ietf-dhc-dns-resolution- - is the name correct? -- Possible downref: Normative reference to a draft: ref. '1' ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. '5') ** Obsolete normative reference: RFC 2434 (ref. '6') (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 2535 (ref. '8') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) -- No information found for draft-ietf-dhc-dhcpv6- - is the name correct? -- Obsolete informational reference (is this intentional?): RFC 2845 (ref. '11') (Obsoleted by RFC 8945) Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSEXT Working Group M. Stapp 3 Internet-Draft Cisco Systems, Inc. 4 Expires: April 23, 2004 T. Lemon 5 A. Gustafsson 6 Nominum, Inc. 7 October 24, 2003 9 A DNS RR for Encoding DHCP Information (DHCID RR) 10 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as 20 Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other documents 24 at any time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April 23, 2004. 35 Copyright Notice 37 Copyright (C) The Internet Society (2003). All Rights Reserved. 39 Abstract 41 It is possible for multiple DHCP clients to attempt to update the 42 same DNS FQDN as they obtain DHCP leases. Whether the DHCP server or 43 the clients themselves perform the DNS updates, conflicts can arise. 44 To resolve such conflicts, "Resolution of DNS Name Conflicts"[1] 45 proposes storing client identifiers in the DNS to unambiguously 46 associate domain names with the DHCP clients to which they refer. 47 This memo defines a distinct RR type for this purpose for use by 48 DHCP clients and servers, the "DHCID" RR. 50 Table of Contents 52 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. The DHCID RR . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3.1 DHCID RDATA format . . . . . . . . . . . . . . . . . . . . . 4 56 3.2 DHCID Presentation Format . . . . . . . . . . . . . . . . . 4 57 3.3 The DHCID RR Type Codes . . . . . . . . . . . . . . . . . . 4 58 3.4 Computation of the RDATA . . . . . . . . . . . . . . . . . . 5 59 3.5 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 3.5.1 Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 3.5.2 Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 4. Use of the DHCID RR . . . . . . . . . . . . . . . . . . . . 6 63 5. Updater Behavior . . . . . . . . . . . . . . . . . . . . . . 6 64 6. Security Considerations . . . . . . . . . . . . . . . . . . 7 65 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7 66 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 67 References . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 References . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 8 70 Full Copyright Statement . . . . . . . . . . . . . . . . . . 10 72 1. Terminology 74 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 75 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 76 document are to be interpreted as described in RFC 2119[2]. 78 2. Introduction 80 A set of procedures to allow DHCP[7] clients and servers to 81 automatically update the DNS (RFC 1034[3], RFC 1035[4]) is proposed 82 in "Resolution of DNS Name Conflicts"[1]. 84 Conflicts can arise if multiple DHCP clients wish to use the same 85 DNS name. To resolve such conflicts, "Resolution of DNS Name 86 Conflicts"[1] proposes storing client identifiers in the DNS to 87 unambiguously associate domain names with the DHCP clients using 88 them. In the interest of clarity, it is preferable for this DHCP 89 information to use a distinct RR type. This memo defines a distinct 90 RR for this purpose for use by DHCP clients or servers, the "DHCID" 91 RR. 93 In order to avoid exposing potentially sensitive identifying 94 information, the data stored is the result of a one-way MD5[5] hash 95 computation. The hash includes information from the DHCP client's 96 REQUEST message as well as the domain name itself, so that the data 97 stored in the DHCID RR will be dependent on both the client 98 identification used in the DHCP protocol interaction and the domain 99 name. This means that the DHCID RDATA will vary if a single client 100 is associated over time with more than one name. This makes it 101 difficult to 'track' a client as it is associated with various 102 domain names. 104 The MD5 hash algorithm has been shown to be weaker than the SHA-1 105 algorithm; it could therefore be argued that SHA-1 is a better 106 choice. However, SHA-1 is significantly slower than MD5. A 107 successful attack of MD5's weakness does not reveal the original 108 data that was used to generate the signature, but rather provides a 109 new set of input data that will produce the same signature. Because 110 we are using the MD5 hash to conceal the original data, the fact 111 that an attacker could produce a different plaintext resulting in 112 the same MD5 output is not significant concern. 114 3. The DHCID RR 116 The DHCID RR is defined with mnemonic DHCID and type code [TBD]. The 117 DHCID RR is only defined in the IN class. DHCID RRs cause no 118 additional section processing. The DHCID RR is not a singleton type. 120 3.1 DHCID RDATA format 122 The RDATA section of a DHCID RR in transmission contains RDLENGTH 123 bytes of binary data. The format of this data and its 124 interpretation by DHCP servers and clients are described below. 126 DNS software should consider the RDATA section to be opaque. DHCP 127 clients or servers use the DHCID RR to associate a DHCP client's 128 identity with a DNS name, so that multiple DHCP clients and servers 129 may deterministically perform dynamic DNS updates to the same zone. 130 From the updater's perspective, the DHCID resource record RDATA 131 consists of a 16-bit identifier type, in network byte order, 132 followed by one or more bytes representing the actual identifier: 134 < 16 bits > DHCP identifier used 135 < n bytes > MD5 digest 137 3.2 DHCID Presentation Format 139 In DNS master files, the RDATA is represented as a single block in 140 base 64 encoding identical to that used for representing binary data 141 in RFC 2535[8]. The data may be divided up into any number of white 142 space separated substrings, down to single base 64 digits, which are 143 concatenated to form the complete RDATA. These substrings can span 144 lines using the standard parentheses. 146 3.3 The DHCID RR Type Codes 148 The DHCID RR Type Code specifies what data from the DHCP client's 149 request was used as input into the hash function. The type codes are 150 defined in a registry maintained by IANA, as specified in Section 7. 151 The initial list of assigned values for the type code is: 153 0x0000 = htype, chaddr from a DHCPv4 client's 154 DHCPREQUEST (RFC 2131) 155 0x0001 = The data portion from a DHCPv4 client's Client 156 Identifier option (RFC 2132) 157 0x0002 = The data portion (i.e., the DUID) from a DHCPv6 158 client's Client Identifier option 159 (draft-ietf-dhc-dhcpv6-*.txt) 161 0x0003 - 0xfffe = Available to be assigned by IANA 163 0xffff = RESERVED 165 3.4 Computation of the RDATA 167 The DHCID RDATA is formed by concatenating the two type bytes with 168 some variable-length identifying data. 170 < type > < data > 172 The RDATA for all type codes other than 0xffff, which is reserved 173 for future expansion, is formed by concatenating the two type bytes 174 and a 16-byte MD5 hash value. The input to the hash function is 175 defined to be: 177 data = MD5(< identifier > < FQDN >) 179 The FQDN is represented in the buffer in unambiguous canonical form 180 as described in RFC 2535[8], section 8.1. The type code and the 181 identifier are related as specified in Section 3.3: the type code 182 describes the source of the identifier. 184 When the updater is using the client's link-layer address as the 185 identifier, the first two bytes of the DHCID RDATA MUST be zero. To 186 generate the rest of the resource record, the updater computes a 187 one-way hash using the MD5 algorithm across a buffer containing the 188 client's network hardware type, link-layer address, and the FQDN 189 data. Specifically, the first byte of the buffer contains the 190 network hardware type as it appeared in the DHCP 'htype' field of 191 the client's DHCPREQUEST message. All of the significant bytes of 192 the chaddr field in the client's DHCPREQUEST message follow, in the 193 same order in which the bytes appear in the DHCPREQUEST message. The 194 number of significant bytes in the 'chaddr' field is specified in 195 the 'hlen' field of the DHCPREQUEST message. The FQDN data, as 196 specified above, follows. 198 When the updater is using the DHCPv4 Client Identifier option sent 199 by the client in its DHCPREQUEST message, the first two bytes of the 200 DHCID RR MUST be 0x0001, in network byte order. The rest of the 201 DHCID RR MUST contain the results of computing an MD5 hash across 202 the payload of the option, followed by the FQDN. The payload of the 203 option consists of the bytes of the option following the option code 204 and length. 206 When the updater is using the DHCPv6 DUID sent by the client in its 207 REQUEST message, the first two bytes of the DHCID RR MUST be 0x0002, 208 in network byte order. The rest of the DHCID RR MUST contain the 209 results of computing an MD5 hash across the payload of the option, 210 followed by the FQDN. The payload of the option consists of the 211 bytes of the option following the option code and length. 213 3.5 Examples 215 3.5.1 Example 1 217 A DHCP server allocating the IPv4 address 10.0.0.1 to a client with 218 Ethernet MAC address 01:02:03:04:05:06 using domain name 219 "client.example.com" uses the client's link-layer address to 220 identify the client. The DHCID RDATA is composed by setting the two 221 type bytes to zero, and performing an MD5 hash computation across a 222 buffer containing the Ethernet MAC type byte, 0x01, the six bytes of 223 MAC address, and the domain name (represented as specified in 224 Section 3.4). 226 client.example.com. A 10.0.0.1 227 client.example.com. DHCID AAAUMru0ZM5OK/PdVAJgZ/HU 229 3.5.2 Example 2 231 A DHCP server allocates the IPv4 address 10.0.12.99 to a client 232 which included the DHCP client-identifier option data 233 01:07:08:09:0a:0b:0c in its DHCP request. The server updates the 234 name "chi.example.com" on the client's behalf, and uses the DHCP 235 client identifier option data as input in forming a DHCID RR. The 236 DHCID RDATA is formed by setting the two type bytes to the value 237 0x0001, and performing an MD5 hash computation across a buffer 238 containing the seven bytes from the client-id option and the FQDN 239 (represented as specified in Section 3.4). 241 chi.example.com. A 10.0.12.99 242 chi.example.com. DHCID AAHdd5jiQ3kEjANDm82cbObk\012 244 4. Use of the DHCID RR 246 This RR MUST NOT be used for any purpose other than that detailed in 247 "Resolution of DNS Name Conflicts"[1]. Although this RR contains 248 data that is opaque to DNS servers, the data must be consistent 249 across all entities that update and interpret this record. 250 Therefore, new data formats may only be defined through actions of 251 the DHC Working Group, as a result of revising [1]. 253 5. Updater Behavior 255 The data in the DHCID RR allows updaters to determine whether more 256 than one DHCP client desires to use a particular FQDN. This allows 257 site administrators to establish policy about DNS updates. The DHCID 258 RR does not establish any policy itself. 260 Updaters use data from a DHCP client's request and the domain name 261 that the client desires to use to compute a client identity hash, 262 and then compare that hash to the data in any DHCID RRs on the name 263 that they wish to associate with the client's IP address. If an 264 updater discovers DHCID RRs whose RDATA does not match the client 265 identity that they have computed, the updater SHOULD conclude that a 266 different client is currently associated with the name in question. 267 The updater SHOULD then proceed according to the site's 268 administrative policy. That policy might dictate that a different 269 name be selected, or it might permit the updater to continue. 271 6. Security Considerations 273 The DHCID record as such does not introduce any new security 274 problems into the DNS. In order to avoid exposing private 275 information about DHCP clients to public scrutiny, a one-way hash is 276 used to obscure all client information. In order to make it 277 difficult to 'track' a client by examining the names associated with 278 a particular hash value, the FQDN is included in the hash 279 computation. Thus, the RDATA is dependent on both the DHCP client 280 identification data and on each FQDN associated with the client. 282 Administrators should be wary of permitting unsecured DNS updates to 283 zones which are exposed to the global Internet. Both DHCP clients 284 and servers SHOULD use some form of update authentication (e.g., 285 TSIG[11]) when performing DNS updates. 287 7. IANA Considerations 289 IANA is requested to allocate an RR type number for the DHCID record 290 type. 292 This specification defines a new number-space for the 16-bit type 293 codes associated with the DHCID RR. IANA is requested to establish a 294 registry of the values for this number-space. 296 Three initial values are assigned in Section 3.3, and the value 297 0xFFFF is reserved for future use. New DHCID RR type codes are 298 tentatively assigned after the specification for the associated type 299 code, published as an Internet Draft, has received expert review by 300 a designated expert. The final assignment of DHCID RR type codes is 301 through Standards Action, as defined in RFC 2434[6]. 303 8. Acknowledgements 305 Many thanks to Josh Littlefield, Olafur Gudmundsson, Bernie Volz, 306 and Ralph Droms for their review and suggestions. 308 Normative References 310 [1] Stapp, M., "Resolution of DNS Name Conflicts Among DHCP Clients 311 (draft-ietf-dhc-dns-resolution-*)", November 2002. 313 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 314 Levels", RFC 2119, March 1997. 316 [3] Mockapetris, P., "Domain names - Concepts and Facilities", RFC 317 1034, Nov 1987. 319 [4] Mockapetris, P., "Domain names - Implementation and 320 Specification", RFC 1035, Nov 1987. 322 [5] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321, April 323 1992. 325 [6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 326 Considerations Section in RFCs", RFC 2434, October 1998. 328 Informative References 330 [7] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 331 Mar 1997. 333 [8] Eastlake, D., "Domain Name System Security Extensions", RFC 334 2535, March 1999. 336 [9] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 337 Extensions", RFC 2132, Mar 1997. 339 [10] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. 340 Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 341 (draft-ietf-dhc-dhcpv6-*.txt)", November 2002. 343 [11] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, 344 "Secret Key Transaction Authentication for DNS (TSIG)", RFC 345 2845, May 2000. 347 Authors' Addresses 349 Mark Stapp 350 Cisco Systems, Inc. 351 1414 Massachusetts Ave. 352 Boxborough, MA 01719 353 USA 355 Phone: 978.936.1535 356 EMail: mjs@cisco.com 357 Ted Lemon 358 Nominum, Inc. 359 950 Charter St. 360 Redwood City, CA 94063 361 USA 363 EMail: mellon@nominum.com 365 Andreas Gustafsson 366 Nominum, Inc. 367 950 Charter St. 368 Redwood City, CA 94063 369 USA 371 EMail: gson@nominum.com 373 Full Copyright Statement 375 Copyright (C) The Internet Society (2003). All Rights Reserved. 377 This document and translations of it may be copied and furnished to 378 others, and derivative works that comment on or otherwise explain it 379 or assist in its implementation may be prepared, copied, published 380 and distributed, in whole or in part, without restriction of any 381 kind, provided that the above copyright notice and this paragraph 382 are included on all such copies and derivative works. However, this 383 document itself may not be modified in any way, such as by removing 384 the copyright notice or references to the Internet Society or other 385 Internet organizations, except as needed for the purpose of 386 developing Internet standards in which case the procedures for 387 copyrights defined in the Internet Standards process must be 388 followed, or as required to translate it into languages other than 389 English. 391 The limited permissions granted above are perpetual and will not be 392 revoked by the Internet Society or its successors or assigns. 394 This document and the information contained herein is provided on an 395 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 396 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 397 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 398 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 399 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 401 Acknowledgement 403 Funding for the RFC editor function is currently provided by the 404 Internet Society.