idnits 2.17.1 draft-gont-dhcpv6-stable-privacy-addresses-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 9, 2015) is 3151 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 342, but no explicit reference was found in the text == Unused Reference: 'RFC2460' is defined on line 347, but no explicit reference was found in the text == Unused Reference: 'RFC4291' is defined on line 356, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) == Outdated reference: A later version (-08) exists of draft-ietf-6man-ipv6-address-generation-privacy-07 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Dynamic Host Configuration (dhc) F. Gont 3 Internet-Draft SI6 Networks / UTN-FRH 4 Intended status: Informational W. Liu 5 Expires: March 12, 2016 Huawei Technologies 6 September 9, 2015 8 A Method for Generating Semantically Opaque Interface Identifiers with 9 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 10 draft-gont-dhcpv6-stable-privacy-addresses-00 12 Abstract 14 This document describes a method for selecting IPv6 Interface 15 Identifiers that can be employed by Dynamic Host Configuration 16 Protocol for IPv6 (DHCPv6) servers when leasing non-temporary IPv6 17 addresses to DHCPv6 clients. This method is a DHCPv6 server side 18 algorithm, that does not require any updates to the existing DHCPv6 19 specifications. The aforementioned method results in stable 20 addresses within each subnet, even in the presence of multiple DHCPv6 21 servers or DHCPv6 server reinstallments. It is a DHCPv6-variant of 22 the method specified in RFC 7217 for IPv6 Stateless Address 23 Autoconfiguration. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on March 12, 2016. 42 Copyright Notice 44 Copyright (c) 2015 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Applicability and Design Goals . . . . . . . . . . . . . . . 3 61 3. Method Specification . . . . . . . . . . . . . . . . . . . . 4 62 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 64 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 65 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 67 7.2. Informative References . . . . . . . . . . . . . . . . . 8 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 70 1. Introduction 72 Stable IPv6 addresses tend to simplify event logging, trouble- 73 shooting, enforcement of access controls and quality of service, etc. 74 However, there are a number of scenarios in which a host employing 75 the DHCPv6 protocol [RFC3315] may be assigned different IPv6 76 addresses for the same interface within the same subnet over time. 77 For example, this may happen when multiple servers operate on the 78 same network to provide increased availability, but may also happen 79 as a result of DHCPv6 server reinstallments and other scenarios. 81 This document describes a method for selecting IPv6 Interface 82 Identifiers that can be employed by Dynamic Host Configuration 83 Protocol for IPv6 (DHCPv6) servers when leasing non-temporary IPv6 84 addresses to DHCPv6 clients (i.e., to be employed with IA_NA 85 options). This method is a DHCPv6 server side algorithm, that does 86 not require any updates to the existing DHCPv6 specifications. The 87 aforementioned method has the following properties: 89 o The resulting IPv6 addresses remain stable within each subnet for 90 the same network interface of the same client, even when different 91 DHCPv6 servers (implementing this specification) are employed. 93 o Predicting the IPv6 addresses that will be generated by the method 94 specified in this document, even with knowledge of the IPv6 95 addresses generated for other nodes within the same network, 96 becomes very difficult. 98 The method specified in this document achieves the aforementioned 99 properties by means of a calculated technique as opposed to e.g. 100 state-sharing among DHCPv6 servers. This approach has been already 101 suggested in [RFC7031]. We note that the method described in this 102 document is essentially a DHCPv6-version of the "Method for 103 Generating Semantically Opaque Interface Identifiers with IPv6 104 Stateless Address Autoconfiguration (SLAAC)" specified in [RFC7217]. 106 2. Applicability and Design Goals 108 This document simply describes one possible approach for selecting 109 IPv6 Interface Identifiers to be employed by Dynamic Host 110 Configuration Protocol for IPv6 (DHCPv6) servers when leasing non- 111 temporary IPv6 addresses to DHCPv6 clients, with the following 112 properties: 114 o The resulting IPv6 addresses remain stable within each subnet for 115 the same network interface of the same client. 117 o The resulting IPv6 addresses cannot be predicted by an attacker 118 without knowledge of a secret key. 120 o The resulting IPv6 addresses remain stable across DHCPv6 server 121 re-installations, or even a database of previous DHCPv6 address 122 leases is not available. 124 o The resulting IPv6 addresses remain stable when different DHCPv6 125 servers (implementing this specification) are employed on the same 126 network. 128 The benefits of stable IPv6 addresses are discussed in 129 [I-D.ietf-6man-ipv6-address-generation-privacy]. Providing address 130 stability across server re-installations or when a database of 131 previous DHCPv6 address leases is unavailable is of use not only when 132 a DHCPv6 server must be re-installed or the address-lease database 133 becomes corrupted, but is also of use when implementation constraints 134 (e.g., a DHCPv6 server implementation on an embedded device) make it 135 impossible for a DHCPv6 server implementation to maintain a database 136 of previous DHCPv6 address leases. Finally, [RFC7031] describes 137 scenarios where multiple DHCPv6 servers are required to run in such a 138 way as to provide increased availability in case of server failure; 139 the algorithm specified in this document employs a (lightweight) 140 calculated technique to (as opposed to e.g. state-sharing among 141 DHCPv6 servers) to achieve address stability in such scenarios, 142 without the need of an additional protocol to synchronize the lease 143 databases of DHCPv6 servers. 145 3. Method Specification 147 Implementations should provide the means for a system administrator 148 to enable or disable the use of this algorithm for generating IPv6 149 addresses. 151 A DHCPv6 server implementing this specification must select the IPv6 152 addresses to be leased with the following algorithm: 154 1. Compute a random (but stable) identifier with the expression: 156 RID = F(Prefix | Client_DUID | IAID | Counter | secret_key) 158 Where: 160 RID: 161 Random (but stable) Identifier 163 F(): 164 A pseudorandom function (PRF) that must not be computable from 165 the outside (without knowledge of the secret key). F() must 166 also be difficult to reverse, such that it resists attempts to 167 obtain the secret key, even when given samples of the output 168 of F() and knowledge or control of the other input parameters. 169 F() should produce an output of at least 64 bits. F() could 170 be implemented as a cryptographic hash of the concatenation of 171 each of the function parameters. The default algorithm to be 172 employed for F() should be SHA-1 [FIPS-SHS]. An 173 implementation may provide the means for selecting other other 174 algorithms (e.g., SHA-256) for F(). Note: MD5 [RFC1321] is 175 considered unacceptable for F() [RFC6151]. 177 Prefix: 178 The prefix employed for the local subnet. If multiple servers 179 operate on the same network to provide increased availability, 180 all such DHCPv6 servers must be configured with the same 181 Prefix. It is the administrator's responsibility that the 182 aforementioned requirement is met. 184 |: 185 An operator representing "concatenation". 187 Client_DUID: 188 The DUID value contained in the Client Identifier option 189 received in the DHCPv6 client message. The DUID can be 190 treated as an array of 8-bit unsigned integers. 192 IAID: 194 The IAID value contained in the IA_NA option received in the 195 client message. It must be interpreted as a 32-bit unsigned 196 integer in network byte order. 198 secret_key: 199 A secret key configured by the DHCPv6 server administrator, 200 which must not be known by the attacker. It must be encoded 201 as an array of 8-bit unsigned integers containing the ASCII 202 codes corresponding to the secret key. An implementation of 203 this specification must provide an interface for viewing and 204 changing the secret key. All DHCPv6 servers leasing addresses 205 from the same address range must employ the same secret key. 207 Counter: 208 A 32-bit unsigned integer in network byte order, that is 209 employed to resolve address conflicts. It must be initialized 210 to 0. 212 2. A candidate IPv6 address (IPV6_ADDR) to be leased is obtained by 213 concatenating as many bits as necessary from the RID value 214 computed in the previous step (starting from the least 215 significant bit) to the Prefix employed in the equation above. 217 3. The candidate IPv6 address from the previous step should be 218 adjusted (if necessary) to the IPv6 address range from which the 219 DHCPv6 server is expected to lease IPv6 addresses, as follows: 221 if(IPV6_ADDR < IPV6_ADDR_LOW || IPV6_ADDR > IPV6_ADDR_HI){ 222 IPV6_ADDR = IPV6_ADDR_LOW + IPV6_ADDR % \ 223 (IPV6_ADDR_HI - IPV6_ADDR_LOW + 1); 224 } 226 where: 228 IPV6_ADDR: 229 The candidate IPv6 address generated in the previous step.. 231 IPV6_ADDR_HI: 232 An IPv6 address specifying the upper boundary of the IPv6 233 address pool from which the DHCPv6 server leases IPv6 234 addresses. If an address range is not explicitly selected, 235 IPV6_ADDR_HI must be set to the IPv6 address from Prefix (see 236 the expression above) that has all of the bits of the 237 Interface Identifier set to 1. 239 IPV6_ADDR_LOW: 240 An IPv6 address specifying the lower boundary of the IPv6 241 address pool from which the DHCPv6 server leases IPv6 242 addresses. If an address range is not explicitly selected, 243 IPV6_ADDR_LOW must be set to the IPv6 address from Prefix (see 244 the expression above) that has all of the bits of the 245 Interface Identifier set to 0. 247 4. The Interface Identifier of the selected IPv6 address must be 248 compared against the reserved IPv6 Interface Identifiers 249 [RFC5453] [IANA-RESERVED-IID]. In the event that an unacceptable 250 identifier has been generated, the Counter variable should be 251 incremented by 1, and a new IPv6 address should be computed with 252 the updated Counter value. 254 5. If the resulting address is not available (e.g., there is a 255 conflicting binding), the server should increment the Counter 256 variable, and a new Interface ID and IPv6 address should be 257 computed with the updated Counter value. 259 This document requires that SHA-1 be the default function to be used 260 for F(), such that, all other configuration parameters being the 261 same, different implementations of this specification result in the 262 same IPv6 addresses. 264 Including the Prefix in the PRF computation causes the Interface 265 Identifier to be different for each address from a different prefix 266 assigned to the same client. This mitigates the correlation of 267 activities of multi-homed nodes (since each of the corresponding 268 addresses will employ a different Interface ID), host-tracking (since 269 the network prefix will change as the node moves from one network to 270 another), and any other attacks that benefit from predictable 271 Interface Identifiers 272 [I-D.ietf-6man-ipv6-address-generation-privacy]. 274 As required by [RFC3315], an IAID is associated with each of the 275 client's network interfaces, and is consistent across restarts of the 276 DHCPv6 client. 278 The Counter parameter provides the means to intentionally cause this 279 algorithm to produce different IPv6 addresses (all other parameters 280 being the same). This can be of use to resolve address conflicts 281 (e.g. the resulting address having a conflicting binding). 283 Note that the result of F() in the algorithm above is no more secure 284 than the secret key. If an attacker is aware of the PRF that is 285 being used by the DHCPv6 server (which we should expect), and the 286 attacker can obtain enough material (i.e. addresses generated by the 287 DHCPv6 server), the attacker may simply search the entire secret-key 288 space to find matches. To protect against this, the secret key 289 should be of at least 128 bits. Key lengths of at least 128 bits 290 should be adequate. 292 Providing a mechanism to display and change the secret_key is crucial 293 for having different DHCPv6 servers produce the same IPv6 addresses, 294 and for causing a replacement system to generate the same IPv6 295 addresses as the system being replaced. We note that since the 296 privacy of the scheme specified in this document relies on the 297 secrecy of the secret_key parameter, implementations should constrain 298 access to the secret_key parameter to the extent practicable (e.g., 299 require superuser privileges to access it). Furthermore, in order to 300 prevent leakages of the secret_key parameter, it should not be used 301 for any other purposes than being a parameter to the scheme specified 302 in this document. 304 We note that all of the bits in the resulting Interface IDs are 305 treated as "opaque" bits [RFC7136]. For example, the universal/local 306 bit of Modified EUI-64 format identifiers is treated as any other bit 307 of such identifier. 309 4. IANA Considerations 311 There are no IANA registries within this document. The RFC-Editor 312 can remove this section before publication of this document as an 313 RFC. 315 5. Security Considerations 317 The method specified in this document results in IPv6 Interface 318 Identifiers (and hence IPv6 addresses) that do not follow any 319 specific pattern. Thus, attacks that rely on predictable Interface 320 IDs (such as [I-D.ietf-opsec-ipv6-host-scanning]) are mitigated. 322 The method specified in this document neither mitigates nor 323 exacerbates the security considerations for DHCPv6 discussed in 324 [RFC3315]. 326 6. Acknowledgements 328 This document is based on [RFC7217], authored by Fernando Gont. 330 The authors would like to thank Stephane Bortzmeyer, Tatuya Jinmei, 331 Andre Kostur, Tomek Mrugalski, Hosnieh Rafiee, Jean-Francois 332 Tremblay, Tina Tsou, and Bernie Volz, for providing valuable comments 333 on earlier versions of this documents. 335 The authors would like to thank Ted Lemon, who kindly answered some 336 DHCPv6-related questions. 338 7. References 340 7.1. Normative References 342 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 343 Requirement Levels", BCP 14, RFC 2119, 344 DOI 10.17487/RFC2119, March 1997, 345 . 347 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 348 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 349 December 1998, . 351 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 352 C., and M. Carney, "Dynamic Host Configuration Protocol 353 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 354 2003, . 356 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 357 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 358 2006, . 360 [RFC5453] Krishnan, S., "Reserved IPv6 Interface Identifiers", 361 RFC 5453, DOI 10.17487/RFC5453, February 2009, 362 . 364 [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 365 Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, 366 February 2014, . 368 7.2. Informative References 370 [FIPS-SHS] 371 FIPS, , "Secure Hash Standard (SHS)", Federal Information 372 Processing Standards Publication 180-4, March 2012, 373 . 376 [I-D.ietf-6man-ipv6-address-generation-privacy] 377 Cooper, A., Gont, F., and D. Thaler, "Privacy 378 Considerations for IPv6 Address Generation Mechanisms", 379 draft-ietf-6man-ipv6-address-generation-privacy-07 (work 380 in progress), June 2015. 382 [I-D.ietf-opsec-ipv6-host-scanning] 383 Gont, F. and T. Chown, "Network Reconnaissance in IPv6 384 Networks", draft-ietf-opsec-ipv6-host-scanning-08 (work in 385 progress), August 2015. 387 [IANA-RESERVED-IID] 388 Reserved IPv6 Interface Identifiers, , 389 "http://www.iana.org/assignments/ipv6-interface-ids/ 390 ipv6-interface-ids.xml". 392 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 393 DOI 10.17487/RFC1321, April 1992, 394 . 396 [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations 397 for the MD5 Message-Digest and the HMAC-MD5 Algorithms", 398 RFC 6151, DOI 10.17487/RFC6151, March 2011, 399 . 401 [RFC7031] Mrugalski, T. and K. Kinnear, "DHCPv6 Failover 402 Requirements", RFC 7031, DOI 10.17487/RFC7031, September 403 2013, . 405 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 406 Interface Identifiers with IPv6 Stateless Address 407 Autoconfiguration (SLAAC)", RFC 7217, 408 DOI 10.17487/RFC7217, April 2014, 409 . 411 Authors' Addresses 413 Fernando Gont 414 SI6 Networks / UTN-FRH 415 Evaristo Carriego 2644 416 Haedo, Provincia de Buenos Aires 1706 417 Argentina 419 Phone: +54 11 4650 8472 420 Email: fgont@si6networks.com 421 URI: http://www.si6networks.com 423 Will(Shucheng) Liu 424 Huawei Technologies 425 Bantian, Longgang District 426 Shenzhen 518129 427 P.R. China 429 Email: liushucheng@huawei.com