idnits 2.17.1 draft-ietf-dhc-stable-privacy-addresses-02.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 (April 8, 2015) is 3300 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) == Unused Reference: 'RFC2460' is defined on line 364, but no explicit reference was found in the text == Unused Reference: 'RFC4291' is defined on line 371, 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-04 == Outdated reference: A later version (-08) exists of draft-ietf-opsec-ipv6-host-scanning-06 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: Standards Track W. Liu 5 Expires: October 10, 2015 Huawei Technologies 6 April 8, 2015 8 A Method for Generating Semantically Opaque Interface Identifiers with 9 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 10 draft-ietf-dhc-stable-privacy-addresses-02 12 Abstract 14 This document specifies a method for selecting IPv6 Interface 15 Identifiers, to be employed by Dynamic Host Configuration Protocol 16 for IPv6 (DHCPv6) servers when leasing non-temporary IPv6 addresses 17 to DHCPv6 clients. This method is a DHCPv6 server side algorithm, 18 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 October 10, 2015. 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Applicability and Design Goals . . . . . . . . . . . . . . . 3 62 4. Method Specification . . . . . . . . . . . . . . . . . . . . 4 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 65 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 68 8.2. Informative References . . . . . . . . . . . . . . . . . 9 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 71 1. Introduction 73 Stable IPv6 addresses tend to simplify event logging, trouble- 74 shooting, enforcement of access controls and quality of service, etc. 75 However, there are a number of scenarios in which a host employing 76 the DHCPv6 protocol [RFC3315] may be assigned different IPv6 77 addresses for the same interface within the same subnet over time. 78 For example, this may happen when multiple servers operate on the 79 same network to provide increased availability, but may also happen 80 as a result of DHCPv6 server reinstallments and other scenarios. 82 This document specifies a method for selecting IPv6 Interface 83 Identifiers, to be employed by Dynamic Host Configuration Protocol 84 for IPv6 (DHCPv6) servers when leasing non-temporary IPv6 addresses 85 to DHCPv6 clients (i.e., to be employed with IA_NA options). This 86 method is a DHCPv6 server side algorithm, that does not require any 87 updates to the existing DHCPv6 specifications. The aforementioned 88 method has the following properties: 90 o The resulting IPv6 addresses remain stable within each subnet for 91 the same network interface of the same client, even when different 92 DHCPv6 servers (implementing this specification) are employed. 94 o Predicting the IPv6 addresses that will be generated by the method 95 specified in this document, even with knowledge of the IPv6 96 addresses generated for other nodes within the same network, 97 becomes very difficult. 99 The method specified in this document achieves the aforementioned 100 properties by means of a calculated technique as opposed to e.g. 101 state-sharing among DHCPv6 servers. This approach has been already 102 suggested in [RFC7031]. We note that the method specified in this 103 document is essentially a DHCPv6-version of the "Method for 104 Generating Semantically Opaque Interface Identifiers with IPv6 105 Stateless Address Autoconfiguration (SLAAC)" specified in [RFC7217]. 107 2. Terminology 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in RFC 2119 [RFC2119]. 113 3. Applicability and Design Goals 115 This document does not update the DHCPv6 protocol [RFC3315]. DHCPv6 116 implementations are NOT required to implement/support the mechanism 117 specified in this document. It is up to each DHCPv6 server 118 implementation whether the scheme specified in this document is 119 implemented and/or enabled. 121 This document simply specifies one possible approach for selecting 122 IPv6 Interface Identifiers to be employed by Dynamic Host 123 Configuration Protocol for IPv6 (DHCPv6) servers when leasing non- 124 temporary IPv6 addresses to DHCPv6 clients, with the following 125 properties: 127 o The resulting IPv6 addresses remain stable within each subnet for 128 the same network interface of the same client. 130 o The resulting IPv6 addresses cannot be predicted by an attacker 131 without knowledge of a secret key. 133 o The resulting IPv6 addresses remain stable across DHCPv6 server 134 re-installations, or even a database of previous DHCPv6 address 135 leases is not available. 137 o The resulting IPv6 addresses remain stable when different DHCPv6 138 servers (implementing this specification) are employed on the same 139 network. 141 The benefits of stable IPv6 addresses are discussed in 142 [I-D.ietf-6man-ipv6-address-generation-privacy]. Providing address 143 stability across server re-installations or when a database of 144 previous DHCPv6 address leases is unavailable is of use not only when 145 a DHCPv6 server must be re-installed or the address-lease database 146 becomes corrupted, but is also of use when implementation constraints 147 (e.g., a DHCPv6 server implementation on an embedded device) make it 148 impossible for a DHCPv6 server implementation to maintain a database 149 of previous DHCPv6 address leases. Finally, [RFC7031] describes 150 scenarios where multiple DHCPv6 servers are required to run in such a 151 way as to provide increased availability in case of server failure; 152 the algorithm specified in this document employs a (lightweight) 153 calculated technique to (as opposed to e.g. state-sharing among 154 DHCPv6 servers) to achieve address stability in such scenarios, 155 without the need of an additional protocol to synchronize the lease 156 databases of DHCPv6 servers. 158 4. Method Specification 160 DHCPv6 server implementations conforming to this specification MUST 161 generate non-temporary IPv6 addresses using the algorithm specified 162 in this section. 164 Implementations conforming to this specification SHOULD provide the 165 means for a system administrator to enable or disable the use of this 166 algorithm for generating IPv6 addresses. 168 All of the parameters included in the expression below MUST be 169 included when generating an IPv6 address. 171 A DHCPv6 server implementing this specification must select the IPv6 172 addresses to be leased with the following algorithm: 174 1. Compute a random (but stable) identifier with the expression: 176 RID = F(Prefix | Client_DUID | IAID | Counter | secret_key) 178 Where: 180 RID: 181 Random (but stable) Identifier 183 F(): 184 A pseudorandom function (PRF) that MUST NOT be computable from 185 the outside (without knowledge of the secret key). F() MUST 186 also be difficult to reverse, such that it resists attempts to 187 obtain the secret key, even when given samples of the output 188 of F() and knowledge or control of the other input parameters. 189 F() SHOULD produce an output of at least 64 bits. F() could 190 be implemented as a cryptographic hash of the concatenation of 191 each of the function parameters. The default algorithm to be 192 employed for F() SHOULD be SHA-1 [FIPS-SHS]. An 193 implementation MAY provide the means for selecting other other 194 algorithms (e.g., SHA-256) for F(). Note: MD5 [RFC1321] is 195 considered unacceptable for F() [RFC6151]. 197 Prefix: 198 The prefix employed for the local subnet. If multiple servers 199 operate on the same network to provide increased availability, 200 all such DHCPv6 servers MUST be configured with the same 201 Prefix. It is the administrator's responsibility that the 202 aforementioned requirement is met. 204 |: 205 An operator representing "concatenation". 207 Client_DUID: 208 The DUID value contained in the Client Identifier option 209 received in the DHCPv6 client message. The DUID can be 210 treated as an array of 8-bit unsigned integers. 212 IAID: 213 The IAID value contained in the IA_NA option received in the 214 client message. It MUST be interpreted as a 32-bit unsigned 215 integer in network byte order. 217 secret_key: 218 A secret key configured by the DHCPv6 server administrator, 219 which MUST NOT be known by the attacker. It MUST be encoded 220 as an array of 8-bit unsigned integers containing the ASCII 221 codes corresponding to the secret key. An implementation of 222 this specification MUST provide an interface for viewing and 223 changing the secret key. All DHCPv6 servers leasing addresses 224 from the same address range MUST employ the same secret key. 226 Counter: 227 A 32-bit unsigned integer in network byte order, that is 228 employed to resolve address conflicts. It MUST be initialized 229 to 0. 231 2. A candidate IPv6 address (IPV6_ADDR) to be leased is obtained by 232 concatenating as many bits as necessary from the RID value 233 computed in the previous step (starting from the least 234 significant bit) to the Prefix employed in the equation above. 236 3. The candidate IPv6 address from the previous step should be 237 adjusted (if necessary) to the IPv6 address range from which the 238 DHCPv6 server is expected to lease IPv6 addresses, as follows: 240 if(IPV6_ADDR < IPV6_ADDR_LOW || IPV6_ADDR > IPV6_ADDR_HI){ 241 IPV6_ADDR = IPV6_ADDR_LOW + IPV6_ADDR % \ 242 (IPV6_ADDR_HI - IPV6_ADDR_LOW + 1); 243 } 245 where: 247 IPV6_ADDR: 248 The candidate IPv6 address generated in the previous step.. 250 IPV6_ADDR_HI: 251 An IPv6 address specifying the upper boundary of the IPv6 252 address pool from which the DHCPv6 server leases IPv6 253 addresses. If an address range is not explicitly selected, 254 IPV6_ADDR_HI MUST be set to the IPv6 address from Prefix (see 255 the expression above) that has all of the bits of the 256 Interface Identifier set to 1. 258 IPV6_ADDR_LOW: 259 An IPv6 address specifying the lower boundary of the IPv6 260 address pool from which the DHCPv6 server leases IPv6 261 addresses. If an address range is not explicitly selected, 262 IPV6_ADDR_LOW MUST be set to the IPv6 address from Prefix (see 263 the expression above) that has all of the bits of the 264 Interface Identifier set to 0. 266 4. The Interface Identifier of the selected IPv6 address MUST be 267 compared against the reserved IPv6 Interface Identifiers 268 [RFC5453] [IANA-RESERVED-IID]. In the event that an unacceptable 269 identifier has been generated, the Counter variable should be 270 incremented by 1, and a new IPv6 address should be computed with 271 the updated Counter value. 273 5. If the resulting address is not available (e.g., there is a 274 conflicting binding), the server should increment the Counter 275 variable, and a new Interface ID and IPv6 address should be 276 computed with the updated Counter value. 278 This document requires that SHA-1 be the default function to be used 279 for F(), such that, all other configuration parameters being the 280 same, different implementations of this specification result in the 281 same IPv6 addresses. 283 Including the Prefix in the PRF computation causes the Interface 284 Identifier to be different for each address from a different prefix 285 assigned to the same client. This mitigates the correlation of 286 activities of multi-homed nodes (since each of the corresponding 287 addresses will employ a different Interface ID), host-tracking (since 288 the network prefix will change as the node moves from one network to 289 another), and any other attacks that benefit from predictable 290 Interface Identifiers 291 [I-D.ietf-6man-ipv6-address-generation-privacy]. 293 As required by [RFC3315], an IAID is associated with each of the 294 client's network interfaces, and is consistent across restarts of the 295 DHCPv6 client. 297 The Counter parameter provides the means to intentionally cause this 298 algorithm to produce different IPv6 addresses (all other parameters 299 being the same). This can be of use to resolve address conflicts 300 (e.g. the resulting address having a conflicting binding). 302 Note that the result of F() in the algorithm above is no more secure 303 than the secret key. If an attacker is aware of the PRF that is 304 being used by the DHCPv6 server (which we should expect), and the 305 attacker can obtain enough material (i.e. addresses generated by the 306 DHCPv6 server), the attacker may simply search the entire secret-key 307 space to find matches. To protect against this, the secret key 308 SHOULD be of at least 128 bits. Key lengths of at least 128 bits 309 should be adequate. 311 Providing a mechanism to display and change the secret_key is crucial 312 for having different DHCPv6 servers produce the same IPv6 addresses, 313 and for causing a replacement system to generate the same IPv6 314 addresses as the system being replaced. We note that since the 315 privacy of the scheme specified in this document relies on the 316 secrecy of the secret_key parameter, implementations should constrain 317 access to the secret_key parameter to the extent practicable (e.g., 318 require superuser privileges to access it). Furthermore, in order to 319 prevent leakages of the secret_key parameter, it should not be used 320 for any other purposes than being a parameter to the scheme specified 321 in this document. 323 We note that all of the bits in the resulting Interface IDs are 324 treated as "opaque" bits [RFC7136]. For example, the universal/local 325 bit of Modified EUI-64 format identifiers is treated as any other bit 326 of such identifier. 328 5. IANA Considerations 330 There are no IANA registries within this document. The RFC-Editor 331 can remove this section before publication of this document as an 332 RFC. 334 6. Security Considerations 336 The method specified in this document results in IPv6 Interface 337 Identifiers (and hence IPv6 addresses) that do not follow any 338 specific pattern. Thus, attacks that rely on predictable Interface 339 IDs (such as [I-D.ietf-opsec-ipv6-host-scanning]) are mitigated. 341 The method specified in this document neither mitigates nor 342 exacerbates the security considerations for DHCPv6 discussed in 343 [RFC3315]. 345 7. Acknowledgements 347 This document is based on [RFC7217], authored by Fernando Gont. 349 The authors would like to thank Stephane Bortzmeyer, Tatuya Jinmei, 350 Andre Kostur, Tomek Mrugalski, Hosnieh Rafiee, Jean-Francois 351 Tremblay, Tina Tsou, and Bernie Volz, for providing valuable comments 352 on earlier versions of this documents. 354 The authors would like to thank Ted Lemon, who kindly answered some 355 DHCPv6-related questions. 357 8. References 359 8.1. Normative References 361 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 362 Requirement Levels", BCP 14, RFC 2119, March 1997. 364 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 365 (IPv6) Specification", RFC 2460, December 1998. 367 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 368 and M. Carney, "Dynamic Host Configuration Protocol for 369 IPv6 (DHCPv6)", RFC 3315, July 2003. 371 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 372 Architecture", RFC 4291, February 2006. 374 [RFC5453] Krishnan, S., "Reserved IPv6 Interface Identifiers", RFC 375 5453, February 2009. 377 [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 378 Interface Identifiers", RFC 7136, February 2014. 380 8.2. Informative References 382 [FIPS-SHS] 383 FIPS, , "Secure Hash Standard (SHS)", Federal Information 384 Processing Standards Publication 180-4, March 2012, 385 . 388 [I-D.ietf-6man-ipv6-address-generation-privacy] 389 Cooper, A., Gont, F., and D. Thaler, "Privacy 390 Considerations for IPv6 Address Generation Mechanisms", 391 draft-ietf-6man-ipv6-address-generation-privacy-04 (work 392 in progress), February 2015. 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-06 (work in 397 progress), February 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 April 1992. 407 [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations 408 for the MD5 Message-Digest and the HMAC-MD5 Algorithms", 409 RFC 6151, March 2011. 411 [RFC7031] Mrugalski, T. and K. Kinnear, "DHCPv6 Failover 412 Requirements", RFC 7031, September 2013. 414 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 415 Interface Identifiers with IPv6 Stateless Address 416 Autoconfiguration (SLAAC)", RFC 7217, April 2014. 418 Authors' Addresses 419 Fernando Gont 420 SI6 Networks / UTN-FRH 421 Evaristo Carriego 2644 422 Haedo, Provincia de Buenos Aires 1706 423 Argentina 425 Phone: +54 11 4650 8472 426 Email: fgont@si6networks.com 427 URI: http://www.si6networks.com 429 Will(Shucheng) Liu 430 Huawei Technologies 431 Bantian, Longgang District 432 Shenzhen 518129 433 P.R. China 435 Email: liushucheng@huawei.com