idnits 2.17.1 draft-ietf-dnsext-dhcid-rr-03.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 : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 6 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 non-RFC2606-compliant FQDNs in the document. == 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 (July 20, 2001) is 8309 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 114 -- 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. '6') ** Obsolete normative reference: RFC 2535 (ref. '7') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) ** Obsolete normative reference: RFC 2845 (ref. '9') (Obsoleted by RFC 8945) Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 5 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: January 18, 2002 T. Lemon 5 A. Gustafsson 6 Nominum, Inc. 7 July 20, 2001 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 January 18, 2002. 35 Copyright Notice 37 Copyright (C) The Internet Society (2001). 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 . . . . . . . . . . . . . . . . . . . . . 3 56 3.2 DHCID Presentation Format . . . . . . . . . . . . . . . . . 4 57 3.3 The DHCID RR Type Codes . . . . . . . . . . . . . . . . . . 4 58 3.4 Computation of the RDATA . . . . . . . . . . . . . . . . . . 4 59 3.5 Use of the DHCID RR . . . . . . . . . . . . . . . . . . . . 5 60 3.6 Updater Behavior . . . . . . . . . . . . . . . . . . . . . . 5 61 3.7 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 3.7.1 Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 3.7.2 Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 4. Security Considerations . . . . . . . . . . . . . . . . . . 6 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7 66 References . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 8 68 Full Copyright Statement . . . . . . . . . . . . . . . . . . 9 70 1. Terminology 72 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 73 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 74 document are to be interpreted as described in RFC 2119[2]. 76 2. Introduction 78 A set of procedures to allow DHCP[3] clients and servers to 79 automatically update the DNS (RFC1034[4], RFC1035[5]) is proposed in 80 "Resolution of DNS Name Conflicts"[1]. 82 Conflicts can arise if multiple DHCP clients wish to use the same 83 DNS name. To resolve such conflicts, "Resolution of DNS Name 84 Conflicts"[1] proposes storing client identifiers in the DNS to 85 unambiguously associate domain names with the DHCP clients using 86 them. In the interest of clarity, it is preferable for this DHCP 87 information to use a distinct RR type. This memo defines a distinct 88 RR for this purpose for use by DHCP clients or servers, the "DHCID" 89 RR. 91 In order to avoid exposing potentially sensitive identifying 92 information, the data stored is the result of a one-way MD5[6] hash 93 computation. The hash includes information from the DHCP client's 94 REQUEST message as well as the domain name itself, so that the data 95 stored in the DHCID RR will be dependent on both the client 96 identification used in the DHCP protocol interaction and the domain 97 name. This means that the DHCID RDATA will vary if a single client 98 is associated over time with more than one name. This makes it 99 difficult to 'track' a client as it is associated with various 100 domain names. 102 The MD5 hash algorithm has been shown to be weaker than the SHA-1 103 algorithm; it could therefore be argued that SHA-1 is a better 104 choice. However, SHA-1 is significantly slower than MD5. A 105 successful attack of MD5's weakness does not reveal the original 106 data that was used to generate the signature, but rather provides a 107 new set of input data that will produce the same signature. Because 108 we are using the MD5 hash to conceal the original data, the fact 109 that an attacker could produce a different plaintext resulting in 110 the same MD5 output is not significant concern. 112 3. The DHCID RR 114 The DHCID RR is defined with mnemonic DHCID and type code [TBD]. 116 3.1 DHCID RDATA format 118 The RDATA section of a DHCID RR in transmission contains RDLENGTH 119 bytes of binary data. The format of this data and its 120 interpretation by DHCP servers and clients are described below. 122 DNS software should consider the RDATA section to be opaque. DHCP 123 clients or servers use the DHCID RR to associate a DHCP client's 124 identity with a DNS name, so that multiple DHCP clients and servers 125 may deterministically perform dynamic DNS updates to the same zone. 126 From the updater's perspective, the DHCID resource record RDATA 127 consists of a 16-bit identifier type, in network byte order, 128 followed by one or more bytes representing the actual identifier: 130 < 16 bits > DHCP identifier used 131 < n bytes > MD5 digest 133 3.2 DHCID Presentation Format 135 In DNS master files, the RDATA is represented as a single block in 136 base 64 encoding and may be divided up into any number of white 137 space separated substrings, down to single base 64 digits, which are 138 concatenated to form the complete RDATA. These substrings can span 139 lines using the standard parentheses. This format is identical to 140 that used for representing binary data in RFC2535[7]. 142 3.3 The DHCID RR Type Codes 144 The type code can have one of three classes of values. The first 145 class contains just the value zero. This type indicates that the 146 remaining contents of the DHCID record encode an identifier that is 147 based on the client's link-layer network address. 149 The second class of types contains just the value 0xFFFF. This type 150 code is reserved for future extensibility. 152 The third class of types contains all the values not included in the 153 first two - that is, every value other than zero or 0xFFFF. Types in 154 this class indicate that the remaining contents of the DHCID record 155 encode an identifier that is based on the DHCP option whose code is 156 the same as the specified type. The most common value in this class 157 at the time of the writing of this specification is 0x3d (61 158 decimal), which is the DHCP option code for the Client Identifier 159 option [8]. 161 3.4 Computation of the RDATA 163 The data following the type code (for type codes other than 0xFFFF) 164 is derived by running the MD5 hash algorithm across a buffer 165 containing the identifying information. The identifying information 166 includes some data from the DHCP client's DHCPREQUEST message, and 167 the FQDN which is the target of the update. 169 The domain name is represented in the buffer in dns wire-format as 170 described in RFC1035[5], section 3.1. The domain name MUST NOT be 171 compressed as described in RFC1035[5], section 4.1.4. Any uppercase 172 alphabetic ASCII character in a label MUST be converted to lowercase 173 before being used to compute the hash. 175 When the updater is using the client's link-layer address as the 176 identifier, the first two bytes of the DHCID RDATA MUST be zero. To 177 generate the rest of the resource record, the updater computes a 178 one-way hash using the MD5 algorithm across a buffer containing the 179 client's network hardware type, link-layer address, and the FQDN 180 data. Specifically, the first byte of the buffer contains the 181 network hardware type as it appeared in the DHCP 'htype' field of 182 the client's DHCPREQUEST message. All of the significant bytes of 183 the chaddr field in the client's DHCPREQUEST message follow, in the 184 same order in which the bytes appear in the DHCPREQUEST message. The 185 number of significant bytes in the 'chaddr' field is specified in 186 the 'hlen' field of the DHCPREQUEST message. The FQDN data, as 187 specified above, follows. 189 When the updater is using a DHCP option sent by the client in its 190 DHCPREQUEST message, the first two bytes of the DHCID RR MUST be the 191 option code of that option, in network byte order. For example, if 192 the DHCP client identifier option is being used, the first byte of 193 the DHCID RR should be zero, and the second byte should be 61 194 decimal. The rest of the DHCID RR MUST contain the results of 195 computing an MD5 hash across the payload of the option being used, 196 followed by the FQDN. The payload of a DHCP option consists of the 197 bytes of the option following the option code and length. 199 The "Resolution of DNS Name Conflicts"[1] specification describes 200 the selection process that updaters follow to choose an identifier 201 from the information presented in a client's DHCPREQUEST message. 203 3.5 Use of the DHCID RR 205 This RR MUST NOT be used for any purpose other than that detailed in 206 "Resolution of DNS Name Conflicts"[1]. Although this RR contains 207 data that is opaque to DNS servers, the data must be consistent 208 across all entities that update and interpret this record. 209 Therefore, new data formats may only be defined through actions of 210 the DHC Working Group, as a result of revising [1]. 212 3.6 Updater Behavior 214 The data in the DHCID RR allows updaters to determine whether more 215 than one DHCP client desires to use a particular FQDN. This allows 216 site administrators to establish policy about DNS updates. The DHCID 217 RR does not establish any policy itself. 219 Updaters use data from a DHCP client's request and the domain name 220 that the client desires to use to compute a client identity hash, 221 and then compare that hash to the data in any DHCID RRs on the name 222 that they wish to associate with the client's IP address. If an 223 updater discovers DHCID RRs whose RDATA does not match the client 224 identity that they have computed, the updater SHOULD conclude that a 225 different client is currently associated with the name in question. 226 The updater SHOULD then proceed according to the site's 227 administrative policy. That policy might dictate that a different 228 name be selected, or it might permit the updater to continue. 230 3.7 Examples 232 3.7.1 Example 1 234 A DHCP server allocating the IPv4 address 10.0.0.1 to a client with 235 Ethernet MAC address 01:02:03:04:05:06 using domain name 236 "client.org.nil" uses the client's link-layer address to identify 237 the client. The DHCID RDATA is composed by setting the two type 238 bytes to zero, and performing an MD5 hash computation across a 239 buffer containing the Ethernet MAC type byte, 0x01, the six bytes of 240 MAC address, and the domain name (represented as specified in 241 Section 3.4). 243 client.org.nil. A 10.0.0.1 244 client.org.nil. DHCID AAAUMru0ZM5OK/PdVAJgZ/HU 246 3.7.2 Example 2 248 A DHCP server allocates the IPv4 address 10.0.12.99 to a client 249 which included the DHCP client-identifier option data 250 01:07:08:09:0a:0b:0c in its DHCP request. The server updates the 251 name "chi.org.nil" on the client's behalf, and uses the DHCP client 252 identifier option data as input in forming a DHCID RR. The DHCID 253 RDATA is formed by setting the two type bytes to the option code, 254 0x003d, and performing an MD5 hash computation across a buffer 255 containing the seven bytes from the client-id option and the FQDN 256 (represented as specified in Section 3.4). 258 chi.org.nil. A 10.0.12.99 259 chi.org.nil. DHCID AD3dquu0xNqYn/4zw2FXy8X3 261 4. Security Considerations 263 The DHCID record as such does not introduce any new security 264 problems into the DNS. In order to avoid exposing private 265 information about DHCP clients to public scrutiny, a one-way hash is 266 used to obscure all client information. In order to make it 267 difficult to 'track' a client by examining the names associated with 268 a particular hash value, the FQDN is included in the hash 269 computation. Thus, the RDATA is dependent on both the DHCP client 270 identification data and on each FQDN associated with the client. 272 Administrators should be wary of permitting unsecured DNS updates to 273 zones which are exposed to the global Internet. Both DHCP clients 274 and servers SHOULD use some form of update authentication (e.g., 275 TSIG[9]) when performing DNS updates. 277 5. IANA Considerations 279 IANA is requested to allocate an RR type number for the DHCID record 280 type. 282 References 284 [1] Stapp, M., "Resolution of DNS Name Conflicts Among DHCP Clients 285 (draft-ietf-dhc-dns-resolution-*)", March 2001. 287 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 288 Levels", RFC 2119, March 1997. 290 [3] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, Mar 291 1997. 293 [4] Mockapetris, P., "Domain names - Concepts and Facilities", RFC 294 1034, Nov 1987. 296 [5] Mockapetris, P., "Domain names - Implementation and 297 Specification", RFC 1035, Nov 1987. 299 [6] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321, April 300 1992. 302 [7] Eastlake, D., "Domain Name System Security Extensions", RFC 303 2535, March 1999. 305 [8] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 306 Extensions", RFC 2132, Mar 1997. 308 [9] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, 309 "Secret Key Transaction Authentication for DNS (TSIG)", RFC 310 2845, May 2000. 312 Authors' Addresses 314 Mark Stapp 315 Cisco Systems, Inc. 316 250 Apollo Dr. 317 Chelmsford, MA 01824 318 USA 320 Phone: 978.244.8498 321 EMail: mjs@cisco.com 323 Ted Lemon 324 Nominum, Inc. 325 950 Charter St. 326 Redwood City, CA 94063 327 USA 329 EMail: mellon@nominum.com 331 Andreas Gustafsson 332 Nominum, Inc. 333 950 Charter St. 334 Redwood City, CA 94063 335 USA 337 EMail: gson@nominum.com 339 Full Copyright Statement 341 Copyright (C) The Internet Society (2001). All Rights Reserved. 343 This document and translations of it may be copied and furnished to 344 others, and derivative works that comment on or otherwise explain it 345 or assist in its implementation may be prepared, copied, published 346 and distributed, in whole or in part, without restriction of any 347 kind, provided that the above copyright notice and this paragraph 348 are included on all such copies and derivative works. However, this 349 document itself may not be modified in any way, such as by removing 350 the copyright notice or references to the Internet Society or other 351 Internet organizations, except as needed for the purpose of 352 developing Internet standards in which case the procedures for 353 copyrights defined in the Internet Standards process must be 354 followed, or as required to translate it into languages other than 355 English. 357 The limited permissions granted above are perpetual and will not be 358 revoked by the Internet Society or its successors or assigns. 360 This document and the information contained herein is provided on an 361 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 362 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 363 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 364 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 365 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 367 Acknowledgement 369 Funding for the RFC editor function is currently provided by the 370 Internet Society.