idnits 2.17.1 draft-gont-dhcpv6-stable-privacy-addresses-01.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 (March 11, 2016) is 2968 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 349, but no explicit reference was found in the text == Unused Reference: 'RFC2460' is defined on line 354, but no explicit reference was found in the text == Unused Reference: 'RFC4291' is defined on line 363, 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) Summary: 2 errors (**), 0 flaws (~~), 4 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: September 12, 2016 Huawei Technologies 6 March 11, 2016 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-01 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 September 12, 2016. 42 Copyright Notice 44 Copyright (c) 2016 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 The benefits of stable IPv6 addresses are discussed in 73 [I-D.ietf-6man-ipv6-address-generation-privacy]. Providing address 74 stability across server re-installations or when a database of 75 previous DHCPv6 address leases is unavailable is of use not only when 76 a DHCPv6 server must be re-installed or the address-lease database 77 becomes corrupted, but is also of use when implementation constraints 78 (e.g., a DHCPv6 server implementation on an embedded device) make it 79 impossible for a DHCPv6 server implementation to maintain a database 80 of previous DHCPv6 address leases. Additionally, [RFC7031] describes 81 scenarios where multiple DHCPv6 servers are required to run in such a 82 way as to provide increased availability in case of server failure. 84 This document describes a method for selecting IPv6 Interface 85 Identifiers that can be employed by Dynamic Host Configuration 86 Protocol for IPv6 (DHCPv6) servers when leasing non-temporary IPv6 87 addresses to DHCPv6 clients (i.e., to be employed with IA_NA 88 options). This method is a DHCPv6 server side algorithm, that does 89 not require any updates to the existing DHCPv6 specifications. The 90 aforementioned method has the following properties: 92 o The resulting IPv6 addresses remain stable within each subnet for 93 the same network interface of the same client, even when different 94 DHCPv6 servers (implementing this specification) are employed. 96 o Predicting the IPv6 addresses that will be generated by the method 97 specified in this document, even with knowledge of the IPv6 98 addresses generated for other nodes within the same network, 99 becomes very difficult. 101 The method specified in this document achieves the aforementioned 102 properties by means of a calculated technique as opposed to e.g. 103 state-sharing among DHCPv6 servers. This approach has been already 104 suggested in [RFC7031]. We note that the method described in this 105 document is essentially a DHCPv6-version of the "Method for 106 Generating Semantically Opaque Interface Identifiers with IPv6 107 Stateless Address Autoconfiguration (SLAAC)" specified in [RFC7217]. 109 2. Applicability and Design Goals 111 This document simply describes one possible approach for selecting 112 IPv6 Interface Identifiers to be employed by Dynamic Host 113 Configuration Protocol for IPv6 (DHCPv6) servers when leasing non- 114 temporary IPv6 addresses to DHCPv6 clients, with the following 115 properties: 117 o The resulting IPv6 addresses remain stable within each subnet for 118 the same network interface of the same client. 120 o The resulting IPv6 addresses cannot be predicted by an attacker 121 without knowledge of a secret key. 123 o The resulting IPv6 addresses remain stable across DHCPv6 server 124 re-installations, or even a database of previous DHCPv6 address 125 leases is not available. 127 o The resulting IPv6 addresses remain stable when different DHCPv6 128 servers (implementing this specification) are employed on the same 129 network. 131 We note that the algorithm specified in this document employs a 132 (lightweight) calculated technique (as opposed to e.g. state-sharing 133 among DHCPv6 servers) to achieve address stability in scenarios where 134 multiple DHCPv6 servers are required to run in such a way as to 135 provide increased availability, without the need of an additional 136 protocol to synchronize the lease databases of DHCPv6 servers. 138 Finally, we note that the algorithm in this document is only meant to 139 mitigate IPv6 address-based location tracking, device-specific 140 vulnerability exploitation, and host scanning (please see 141 [I-D.ietf-6man-ipv6-address-generation-privacy]). The are a number 142 of ways in which DHCPv6 affects user privacy, which the algorithm 143 speficied in this document does not mitigate (and does not intend 144 to). Please see [I-D.ietf-dhc-anonymity-profile] for a comprehensive 145 discussion of how DHCPv6 may affect user privacy. 147 3. Method Specification 149 Implementations should provide the means for a system administrator 150 to enable or disable the use of this algorithm for generating IPv6 151 addresses. 153 A DHCPv6 server implementing this specification must select the IPv6 154 addresses to be leased with the following algorithm: 156 1. Compute a random (but stable) identifier with the expression: 158 RID = F(Prefix | Client_DUID | IAID | Counter | secret_key) 160 Where: 162 RID: 163 Random (but stable) Identifier 165 F(): 166 A pseudorandom function (PRF) that must not be computable from 167 the outside (without knowledge of the secret key). F() must 168 also be difficult to reverse, such that it resists attempts to 169 obtain the secret key, even when given samples of the output 170 of F() and knowledge or control of the other input parameters. 171 F() should produce an output of at least 64 bits. F() could 172 be implemented as a cryptographic hash of the concatenation of 173 each of the function parameters. The default algorithm to be 174 employed for F() should be SHA-256 [FIPS-SHS]. An 175 implementation may provide the means for selecting other 176 algorithms. Note: MD5 [RFC1321] is considered unacceptable 177 for F() [RFC6151]. 179 Prefix: 180 The prefix employed for the local subnet, as a 128-bit 181 unsigned integer in network byte order (with the unused bits 182 set to 0). If multiple servers operate on the same network to 183 provide increased availability, all such DHCPv6 servers must 184 be configured with the same Prefix. It is the administrator's 185 responsibility that the aforementioned requirement is met. 187 |: 188 An operator representing "concatenation". 190 Client_DUID: 192 The DUID value contained in the Client Identifier option 193 received in the DHCPv6 client message. The DUID can be 194 treated as an array of 8-bit unsigned integers. 196 IAID: 197 The IAID value contained in the IA_NA option received in the 198 client message. It must be interpreted as a 32-bit unsigned 199 integer in network byte order. 201 secret_key: 202 A secret key configured by the DHCPv6 server administrator, 203 which must not be known by the attacker. It must be encoded 204 as an array of 8-bit unsigned integers. An implementation of 205 this specification must provide an interface for viewing and 206 changing the secret key. All DHCPv6 servers leasing addresses 207 from the same address range must employ the same secret key. 209 Counter: 210 A 32-bit unsigned integer in network byte order, that is 211 employed to resolve address conflicts. It must be initialized 212 to 0. 214 2. A candidate IPv6 address (IPV6_ADDR) to be leased is obtained by 215 concatenating as many bits as necessary from the RID value 216 computed in the previous step (starting from the least 217 significant bit) to the Prefix employed in the equation above as 218 follows: 220 IPV6_ADDR = IPV6_ADDR_LOW + 221 RID % (IPV6_ADDR_HI - IPV6_ADDR_LOW + 1) 223 where: 225 IPV6_ADDR: 226 The candidate IPv6 address to be leased. 228 IPV6_ADDR_HI: 229 An IPv6 address specifying the upper boundary of the IPv6 230 address pool from which the DHCPv6 server leases IPv6 231 addresses. If an address range is not explicitly selected, 232 IPV6_ADDR_HI must be set to the IPv6 address from Prefix (see 233 the expression above) that has all of the bits of the 234 Interface Identifier set to 1. 236 IPV6_ADDR_LOW: 237 An IPv6 address specifying the lower boundary of the IPv6 238 address pool from which the DHCPv6 server leases IPv6 239 addresses. If an address range is not explicitly selected, 240 IPV6_ADDR_LOW must be set to the IPv6 address from Prefix (see 241 the expression above) that has all of the bits of the 242 Interface Identifier set to 0. 244 3. The Interface Identifier of the selected IPv6 address must be 245 compared against the reserved IPv6 Interface Identifiers 246 [RFC5453] [IANA-RESERVED-IID]. In the event that an unacceptable 247 identifier has been generated, the Counter variable should be 248 incremented by 1, and a new IPv6 address should be computed with 249 the updated Counter value. 251 4. If the resulting address is not available (e.g., there is a 252 conflicting binding), the server should increment the Counter 253 variable, and a new Interface ID and IPv6 address should be 254 computed with the updated Counter value. 256 This document requires that SHA-256 be the default function to be 257 used for F(), such that, all other configuration parameters being the 258 same, different implementations of this specification result in the 259 same IPv6 addresses. 261 Including the Prefix in the PRF computation causes the Interface 262 Identifier to be different for each address from a different prefix 263 assigned to the same client. This mitigates the correlation of 264 activities of multi-homed nodes (since each of the corresponding 265 addresses will employ a different Interface ID), host-tracking (since 266 the network prefix will change as the node moves from one network to 267 another), and any other attacks that benefit from predictable 268 Interface Identifiers 269 [I-D.ietf-6man-ipv6-address-generation-privacy]. 271 As required by [RFC3315], an IAID is associated with each of the 272 client's network interfaces, and is consistent across restarts of the 273 DHCPv6 client. 275 The Counter parameter provides the means to intentionally cause this 276 algorithm to produce different IPv6 addresses (all other parameters 277 being the same). This can be of use to resolve address conflicts 278 (e.g. the resulting address having a conflicting binding). 280 Note that the result of F() in the algorithm above is no more secure 281 than the secret key. If an attacker is aware of the PRF that is 282 being used by the DHCPv6 server (which we should expect), and the 283 attacker can obtain enough material (i.e. addresses generated by the 284 DHCPv6 server), the attacker may simply search the entire secret-key 285 space to find matches. To protect against this, the secret key 286 should be of at least 128 bits. Key lengths of at least 128 bits 287 should be adequate. 289 Providing a mechanism to display and change the secret_key is crucial 290 for having different DHCPv6 servers produce the same IPv6 addresses, 291 and for causing a replacement system to generate the same IPv6 292 addresses as the system being replaced. We note that since the 293 privacy of the scheme specified in this document relies on the 294 secrecy of the secret_key parameter, implementations should constrain 295 access to the secret_key parameter to the extent practicable (e.g., 296 require superuser privileges to access it). Furthermore, in order to 297 prevent leakages of the secret_key parameter, it should not be used 298 for any other purposes than being a parameter to the scheme specified 299 in this document. 301 We note that all of the bits in the resulting Interface IDs are 302 treated as "opaque" bits [RFC7136]. For example, the universal/local 303 bit of Modified EUI-64 format identifiers is treated as any other bit 304 of such identifier. 306 4. IANA Considerations 308 There are no IANA registries within this document. The RFC-Editor 309 can remove this section before publication of this document as an 310 RFC. 312 5. Security Considerations 314 The method specified in this document results in IPv6 Interface 315 Identifiers (and hence IPv6 addresses) that do not follow any 316 specific pattern. Thus, attacks that rely on predictable Interface 317 IDs (such as [I-D.ietf-opsec-ipv6-host-scanning]) are mitigated. 319 The method specified in this document neither mitigates nor 320 exacerbates the security considerations for DHCPv6 discussed in 321 [RFC3315], and does not mitigate a range of other privacy 322 implications associated with DHCPv6. Please read 323 [I-D.ietf-dhc-anonymity-profile] for a comprehensive assessment of 324 the privacy implications of DHCPv6. 326 Finally, we note that an attacker that is able to attach to each of 327 the links to which the victim attaches would still be able to 328 correlate the activities of the victim across networks. 330 6. Acknowledgements 332 This document is based on [RFC7217], authored by Fernando Gont. 334 The authors would like to thank Marc Blanchet, Stephane Bortzmeyer, 335 Tatuya Jinmei, Andre Kostur, Tomek Mrugalski, Hosnieh Rafiee, Jim 336 Schaad, Jean-Francois Tremblay, Tina Tsou, and Bernie Volz, for 337 providing valuable comments on earlier versions of this documents. 339 The authors would like to thank Ted Lemon, who kindly answered some 340 DHCPv6-related questions. 342 Finally, the authors would like to thank Nevil Brownlee for his 343 guidance while pursuing this document. 345 7. References 347 7.1. Normative References 349 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 350 Requirement Levels", BCP 14, RFC 2119, 351 DOI 10.17487/RFC2119, March 1997, 352 . 354 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 355 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 356 December 1998, . 358 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 359 C., and M. Carney, "Dynamic Host Configuration Protocol 360 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 361 2003, . 363 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 364 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 365 2006, . 367 [RFC5453] Krishnan, S., "Reserved IPv6 Interface Identifiers", 368 RFC 5453, DOI 10.17487/RFC5453, February 2009, 369 . 371 [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 372 Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, 373 February 2014, . 375 7.2. Informative References 377 [FIPS-SHS] 378 FIPS, , "Secure Hash Standard (SHS)", Federal Information 379 Processing Standards Publication 180-4, March 2012, 380 . 383 [I-D.ietf-6man-ipv6-address-generation-privacy] 384 Cooper, A., Gont, F., and D. Thaler, "Privacy 385 Considerations for IPv6 Address Generation Mechanisms", 386 draft-ietf-6man-ipv6-address-generation-privacy-08 (work 387 in progress), September 2015. 389 [I-D.ietf-dhc-anonymity-profile] 390 Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity 391 profile for DHCP clients", draft-ietf-dhc-anonymity- 392 profile-08 (work in progress), February 2016. 394 [I-D.ietf-opsec-ipv6-host-scanning] 395 Gont, F. and T. Chown, "Network Reconnaissance in IPv6 396 Networks", draft-ietf-opsec-ipv6-host-scanning-08 (work in 397 progress), August 2015. 399 [IANA-RESERVED-IID] 400 Reserved IPv6 Interface Identifiers, , 401 "http://www.iana.org/assignments/ipv6-interface-ids/ 402 ipv6-interface-ids.xml". 404 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 405 DOI 10.17487/RFC1321, April 1992, 406 . 408 [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations 409 for the MD5 Message-Digest and the HMAC-MD5 Algorithms", 410 RFC 6151, DOI 10.17487/RFC6151, March 2011, 411 . 413 [RFC7031] Mrugalski, T. and K. Kinnear, "DHCPv6 Failover 414 Requirements", RFC 7031, DOI 10.17487/RFC7031, September 415 2013, . 417 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 418 Interface Identifiers with IPv6 Stateless Address 419 Autoconfiguration (SLAAC)", RFC 7217, 420 DOI 10.17487/RFC7217, April 2014, 421 . 423 Authors' Addresses 424 Fernando Gont 425 SI6 Networks / UTN-FRH 426 Evaristo Carriego 2644 427 Haedo, Provincia de Buenos Aires 1706 428 Argentina 430 Phone: +54 11 4650 8472 431 Email: fgont@si6networks.com 432 URI: http://www.si6networks.com 434 Will(Shucheng) Liu 435 Huawei Technologies 436 Bantian, Longgang District 437 Shenzhen 518129 438 P.R. China 440 Email: liushucheng@huawei.com