idnits 2.17.1 draft-ietf-dhc-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 (February 18, 2015) is 3356 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 313, 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-03 == Outdated reference: A later version (-08) exists of draft-ietf-opsec-ipv6-host-scanning-06 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: Standards Track W. Liu 5 Expires: August 22, 2015 Huawei Technologies 6 February 18, 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-01 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 August 22, 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. Method Specification . . . . . . . . . . . . . . . . . . . . 3 62 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 64 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 65 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 67 7.2. Informative References . . . . . . . . . . . . . . . . . 7 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 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 specifies a method for selecting IPv6 Interface 82 Identifiers, to be employed by Dynamic Host Configuration Protocol 83 for IPv6 (DHCPv6) servers when leasing non-temporary IPv6 addresses 84 to DHCPv6 clients (i.e., to be employed with IA_NA options). This 85 method is a DHCPv6 server side algorithm, that does not require any 86 updates to the existing DHCPv6 specifications. The aforementioned 87 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 specified 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. Terminology 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in RFC 2119 [RFC2119]. 112 3. Method Specification 114 DHCPv6 server implementations conforming to this specification MUST 115 generate non-temporary IPv6 addresses using the algorithm specified 116 in this section. 118 Implementations conforming to this specification SHOULD provide the 119 means for a system administrator to enable or disable the use of this 120 algorithm for generating IPv6 addresses. 122 All of the parameters included in the expression below MUST be 123 included when generating an IPv6 address. 125 A DHCPv6 server implementing this specification must select the IPv6 126 addresses to be leased with the following algorithm: 128 1. Compute a random (but stable) identifier with the expression: 130 RID = F(IPV6_ADDR_HI | IPV6_ADDR_LOW | Client_DUID | IAID | 131 Counter | secret_key) 133 Where: 135 RID: 136 Random (but stable) Identifier 138 F(): 139 A pseudorandom function (PRF) that MUST NOT be computable from 140 the outside (without knowledge of the secret key). F() MUST 141 also be difficult to reverse, such that it resists attempts to 142 obtain the secret_key, even when given samples of the output 143 of F() and knowledge or control of the other input parameters. 144 F() SHOULD produce an output of at least 64 bits. F() could 145 be implemented as a cryptographic hash of the concatenation of 146 each of the function parameters. The default algorithm to be 147 employed for F() SHOULD be SHA-1 [FIPS-SHS]. An 148 implementation MAY provide the means for selecting other other 149 algorithms (e.g., SHA-256) for F(). Note: MD5 [RFC1321] is 150 considered unacceptable for F() [RFC6151]. 152 |: 153 An operator representing "concatenation". 155 IPV6_ADDR_HI: 156 An IPv6 address specifying the upper boundary of the IPv6 157 address pool from which the DHCPv6 server leases IPv6 158 addresses. It MUST be represented as a 128-bit unsigned 159 integer in network byte order. If multiple servers operate on 160 the same network to provide increased availability, all such 161 DHCPv6 servers MUST be configured with the address range 162 (i.e., the same IPV6_ADDR_HI and IPV6_ADDR_LOW parameters). 163 It is the administrator's responsibility that the 164 aforementioned requirement is met. 166 IPV6_ADDR_LOW: 167 An IPv6 address specifying the lower boundary of the IPv6 168 address pool from which the DHCPv6 server leases IPv6 169 addresses. It MUST be represented as a 128-bit unsigned 170 integer in network byte order. If multiple servers operate on 171 the same network to provide increased availability, all such 172 DHCPv6 servers MUST be configured with the address range 173 (i.e., the same IPV6_ADDR_HI and IPV6_ADDR_LOW parameters). 174 It is the administrator's responsibility that the 175 aforementioned requirement is met. 177 Client_DUID: 178 The DUID value contained in the Client Identifier option 179 received in the DHCPv6 client message. The DUID can be 180 treated as an array of 8-bit unsigned integers. 182 IAID: 183 The IAID value contained in the IA_NA option received in the 184 client message. It MUST be interpreted as a 32-bit unsigned 185 integer in network byte order. 187 Counter: 188 A 32-bit unsigned integer in network byte order, that is 189 employed to resolve address conflicts. It MUST be initialized 190 to 0. 192 secret_key: 194 A secret key configured by the DHCPv6 server administrator, 195 which MUST NOT be known by the attacker. It MUST be encoded 196 as an array of 8-bit unsigned integers containing the ASCII 197 codes corresponding to the secret key. An implementation of 198 this specification MUST provide an interface for viewing and 199 changing the secret key. All DHCPv6 servers leasing addresses 200 from the same address range MUST employ the same secret key. 202 2. A candidate IPv6 address to be leased is obtained as follows: 204 IPV6_ADDRESS = IPV6_ADDR_LOW + RID % (IPV6_ADDR_HI - 205 IPV6_ADDR_LOW + 1) 207 We note that [RFC4291] requires that, the Interface IDs of all 208 unicast addresses (except those that start with the binary 209 value 000) be 64-bit long. The method discussed in this 210 document can be employed for generating IPv6 addresses for any 211 address range (e.g., smaller than 2**64 bits), albeit at the 212 expense of reduced entropy (when the address range is smaller 213 than than of a full 64-bit subnet). 215 3. The Interface Identifier of the selected IPv6 address MUST be 216 compared against the reserved IPv6 Interface Identifiers 217 [RFC5453] [IANA-RESERVED-IID]. In the event that an unacceptable 218 identifier has been generated, the Counter variable should be 219 incremented by 1, and a new IPv6 address (RID and subsequent 220 IPV6_ADDRESS) should be computed with the updated Counter value. 222 4. If the resulting address is not available (e.g., there is a 223 conflicting binding), the server should increment the Counter 224 variable, and a new Interface ID and IPv6 address should be 225 computed with the updated Counter value. 227 This document requires that SHA-1 be the default function to be used 228 for F(), such that, all other configuration parameters being the 229 same, different implementations of this specification result in the 230 same IPv6 addresses. 232 Including the address range in the PRF computation causes the 233 Interface Identifier to be different for each IPv6 address leased 234 from a different address range to the same client. This mitigates 235 the correlation of activities of multi-homed nodes (since each of the 236 corresponding addresses will employ a different Interface ID), host- 237 tracking (since the network prefix will change as the node moves from 238 one network to another), and any other attacks that benefit from 239 predictable Interface Identifiers (such as IPv6 address scanning 240 attacks) [I-D.ietf-6man-ipv6-address-generation-privacy]. 242 As required by [RFC3315], an IAID is associated with each of the 243 client's network interfaces, and is consistent across restarts of the 244 DHCPv6 client. 246 The Counter parameter provides the means to intentionally cause this 247 algorithm to produce different IPv6 addresses (all other parameters 248 being the same). This could be necessary to resolve address 249 conflicts (e.g. the resulting address having a conflicting binding). 251 Note that the result of F() in the algorithm above is no more secure 252 than the secret key. If an attacker is aware of the PRF that is 253 being used by the DHCPv6 server (which we should expect), and the 254 attacker can obtain enough material (i.e. addresses generated by the 255 DHCPv6 server), the attacker may simply search the entire secret-key 256 space to find matches. To protect against this, the secret key 257 SHOULD be of at least 128 bits. Key lengths of at least 128 bits 258 should be adequate. 260 Providing a mechanism to display and change the secret_key is crucial 261 for having different DHCPv6 servers produce the same IPv6 addresses, 262 and for causing a replacement system to generate the same IPv6 263 addresses as the system being replaced. We note that since the 264 privacy of the scheme specified in this document relies on the 265 secrecy of the secret_key parameter, implementations should constrain 266 access to the secret_key parameter to the extent practicable (e.g., 267 require superuser privileges to access it). Furthermore, in order to 268 prevent leakages of the secret_key parameter, it should not be used 269 for any other purposes than being a parameter to the scheme specified 270 in this document. 272 We note that all of the bits in the resulting Interface IDs are 273 treated as "opaque" bits [RFC7136]. For example, the universal/local 274 bit of Modified EUI-64 format identifiers is treated as any other bit 275 of such identifier. 277 4. IANA Considerations 279 There are no IANA registries within this document. The RFC-Editor 280 can remove this section before publication of this document as an 281 RFC. 283 5. Security Considerations 285 The method specified in this document results in IPv6 Interface 286 Identifiers (and hence IPv6 addresses) that do not follow any 287 specific pattern. Thus, address-scanning attacks 288 [I-D.ietf-opsec-ipv6-host-scanning] are mitigated. 290 The method specified in this document neither mitigates nor 291 exacerbates the security considerations for DHCPv6 discussed in 292 [RFC3315]. 294 6. Acknowledgements 296 This document is based on [RFC7217], authored by Fernando Gont. 298 The authors would like to thank Stephane Bortzmeyer, Tatuya Jinmei, 299 Andre Kostur, Tomek Mrugalski, Hosnieh Rafiee, Jean-Francois 300 Tremblay, Tina Tsou, and Bernie Volz, for providing valuable comments 301 on earlier versions of this documents. 303 The authors would like to thank Ted Lemon, who kindly answered some 304 DHCPv6-related questions. 306 7. References 308 7.1. Normative References 310 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 311 Requirement Levels", BCP 14, RFC 2119, March 1997. 313 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 314 (IPv6) Specification", RFC 2460, December 1998. 316 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 317 and M. Carney, "Dynamic Host Configuration Protocol for 318 IPv6 (DHCPv6)", RFC 3315, July 2003. 320 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 321 Architecture", RFC 4291, February 2006. 323 [RFC5453] Krishnan, S., "Reserved IPv6 Interface Identifiers", RFC 324 5453, February 2009. 326 [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 327 Interface Identifiers", RFC 7136, February 2014. 329 7.2. Informative References 331 [FIPS-SHS] 332 FIPS, , "Secure Hash Standard (SHS)", Federal Information 333 Processing Standards Publication 180-4, March 2012, 334 . 337 [I-D.ietf-6man-ipv6-address-generation-privacy] 338 Cooper, A., Gont, F., and D. Thaler, "Privacy 339 Considerations for IPv6 Address Generation Mechanisms", 340 draft-ietf-6man-ipv6-address-generation-privacy-03 (work 341 in progress), January 2015. 343 [I-D.ietf-opsec-ipv6-host-scanning] 344 Gont, F. and T. Chown, "Network Reconnaissance in IPv6 345 Networks", draft-ietf-opsec-ipv6-host-scanning-06 (work in 346 progress), February 2015. 348 [IANA-RESERVED-IID] 349 Reserved IPv6 Interface Identifiers, , 350 "http://www.iana.org/assignments/ipv6-interface-ids/ 351 ipv6-interface-ids.xml", . 353 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 354 April 1992. 356 [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations 357 for the MD5 Message-Digest and the HMAC-MD5 Algorithms", 358 RFC 6151, March 2011. 360 [RFC7031] Mrugalski, T. and K. Kinnear, "DHCPv6 Failover 361 Requirements", RFC 7031, September 2013. 363 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 364 Interface Identifiers with IPv6 Stateless Address 365 Autoconfiguration (SLAAC)", RFC 7217, April 2014. 367 Authors' Addresses 369 Fernando Gont 370 SI6 Networks / UTN-FRH 371 Evaristo Carriego 2644 372 Haedo, Provincia de Buenos Aires 1706 373 Argentina 375 Phone: +54 11 4650 8472 376 Email: fgont@si6networks.com 377 URI: http://www.si6networks.com 378 Will(Shucheng) Liu 379 Huawei Technologies 380 Bantian, Longgang District 381 Shenzhen 518129 382 P.R. China 384 Email: liushucheng@huawei.com