SI6 Networks

Segurola y Habana 4310, 7mo Piso Villa Devoto Ciudad Autonoma de Buenos Aires Argentina fgont@si6networks.com https://www.si6networks.com

Internet Dynamic Host Configuration (dhc) securityprivacy resiliencyattack scanningtracking This document describes a method for selecting IPv6 Interface Identifiers that can be employed by Dynamic Host Configuration Protocol for IPv6 (DHCPv6) servers when leasing non-temporary IPv6 addresses to DHCPv6 clients. This method is a DHCPv6 server-side algorithm that does not require any updates to the existing DHCPv6 specifications. The aforementioned method results in stable addresses within each subnet, even in the presence of multiple DHCPv6 servers or DHCPv6 server reinstallments. It is a DHCPv6 variant of the method specified in RFC 7217 for IPv6 Stateless Address Autoconfiguration (SLAAC).

A number of DHCPv6 implementations are known generate predictable IPv6 addressess, such as those resulting from generating addresses as a result of global counter. Additionally, many implementations are known to select IPv6 addresses from a small address pool as opposed to using the entire IPv6 prefix assigned to the local subnet. The security and privacy implications resulting from predictable IPv6 addresses have been discussed in great detail in , and contains specific advice for protocol specifications regarding the generation of transient numeric identifiers such as IPv6 addresses. While a DHCPv6 server implementation could mitigate the issues discussed in by using a simple randomization scheme for the selection of IPv6 addresses, such a scheme would usually result in non-stable IPv6 addresses. The benefits of stable IPv6 addresses are discussed in . Providing address stability across server reinstallations or when a database of previous DHCPv6 address leases is unavailable is of use not only when a DHCPv6 server must be reinstalled or the address-lease database becomes corrupted, but is also of use when implementation constraints (e.g., a DHCPv6 server implementation on an embedded device) make it impossible for a DHCPv6 server implementation to maintain a database of previous DHCPv6 address leases. Additionally, describes scenarios where multiple DHCPv6 servers are required to run in such a way as to provide increased availability in case of server failures. This document describes a method for selecting IPv6 Interface Identifiers that can be employed by DHCPv6 servers when leasing non-temporary IPv6 addresses to DHCPv6 clients (i.e., to be employed with IA_NA options). This method is a DHCPv6 server-side algorithm that does not require any updates to the existing DHCPv6 specifications. The aforementioned method has the following properties: The resulting IPv6 addresses remain stable within each subnet for the same network interface of the same client, even when different DHCPv6 servers (implementing this specification) are employed, or a database of previous DHCPv6 address leases is not available. Predicting the IPv6 addresses that will be generated by the method specified in this document, even with knowledge of the IPv6 addresses generated for other nodes within the same network, becomes very difficult. The method specified in this document achieves the aforementioned properties by means of a calculated technique as opposed to, e.g., state sharing among DHCPv6 servers. This approach has already been suggested in . We note that the method described in this document is essentially a DHCPv6 version of the "Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)" specified in . This document aims to produce a Standards Track specification of the algorithm originally specified in .

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

This document specifies one possible approach for selecting IPv6 Interface Identifiers to be employed by DHCPv6 servers when leasing non-temporary IPv6 addresses to DHCPv6 clients, with the following properties: The resulting IPv6 addresses remain stable within each subnet for the same network interface of the same client. The resulting IPv6 addresses cannot be predicted by an attacker without knowledge of a secret key. The resulting IPv6 addresses remain stable across DHCPv6 server reinstallations, or even if a database of previous DHCPv6 address leases is not available. The resulting IPv6 addresses remain stable when different DHCPv6 servers (implementing this specification) are employed on the same network. The interoperability properties required for stable IPv6 addressess generated by DHCPv6 servers are those specified as "Category #3: Uniqueness, stable within context (soft failure)" in Section 6 of . We note that the algorithm specified in this document employs a (lightweight) calculated technique (as opposed to, e.g., state sharing among DHCPv6 servers) to achieve address stability in scenarios where multiple DHCPv6 servers are required to run in such a way as to provide increased availability, without the need of an additional protocol to synchronize the lease databases of DHCPv6 servers. The algorithm specified in this document is essentially the algorithm specified in Section "7.3. Category #3: Uniqueness, Stable within Context (Soft Failure)" of where each of the algorithm parameters have been selected according to our use case. Finally, we note that the algorithm in this document is only meant to mitigate IPv6 address-based location tracking, device-specific vulnerability exploitation, and host scanning (please see ). There are a number of ways in which DHCPv6 affects user privacy, which the algorithm specified in this document does not mitigate (and does not intend to). Please see for a comprehensive discussion of how DHCPv6 may affect user privacy.

Implementations SHOULD provide the means for a system administrator to enable or disable the use of this algorithm for generating IPv6 addresses. A DHCPv6 server implementing this specification MUST select the IPv6 addresses to be leased with the following algorithm: Compute a random (but stable) identifier with the expression: RID = F(Prefix | Client_DUID | IAID | Counter | secret_key) Where: Random (but stable) Identifier A Pseudorandom Function (PRF) that MUST NOT be computable from the outside (without knowledge of the secret key). F() MUST also be difficult to reverse, such that it resists attempts to obtain the secret key, even when given samples of the output of F() and knowledge or control of the other input parameters. F() MUST produce an output of at least 64 bits. F() could be implemented as a cryptographic hash of the concatenation of each of the function parameters. The default algorithm to be employed for F() SHOULD be SHA-256 . An implementation MAY provide the means for selecting other algorithms. Note: Message Digest 5 (MD5) is considered unacceptable for F() . The prefix employed for the local subnet, as a 128-bit unsigned integer in network byte order (with the unused bits set to 0). If multiple servers operate on the same network to provide increased availability, all such DHCPv6 servers must be configured with the same Prefix. It is the administrator's responsibility that the aforementioned requirement is met. An operator representing "concatenation". The DHCPv6 Unique Identifier (DUID) value contained in the Client Identifier option received in the DHCPv6 client message. The DUID can be treated as an array of 8-bit unsigned integers. The Identity Association Identifier (IAID) value contained in the IA_NA option received in the client message. It must be interpreted as a 32-bit unsigned integer in network byte order. A secret key that is not known by the attacker. The secret key SHOULD be of at least 128 bits, and MUST be encoded as an array of 8-bit unsigned integers. Unless explicitly configured by the system administrator, it MUST be initialized to a pseudo-random number (see [RFC4086] for randomness requirements for security) when the DHCPv6 server is installed or "bootstrapped" for the first time. An implementation of this specification MUST provide an interface for viewing and changing the secret key. All DHCPv6 servers leasing addresses from the same address range MUST employ the same secret key. A 32-bit unsigned integer in network byte order that is employed to resolve address conflicts. It must be initialized to 0. A candidate IPv6 address (IPV6_ADDR) to be leased is obtained by concatenating as many bits as necessary from the RID value computed in the previous step (starting from the least significant bit) to the Prefix employed in the equation above, as follows:

where: The candidate IPv6 address to be leased. An IPv6 address specifying the upper boundary of the IPv6 address pool from which the DHCPv6 server leases IPv6 addresses. If an address range is not explicitly selected, IPV6_ADDR_HI must be set to the IPv6 address from the Prefix (see the expression above) that has all of the bits of the Interface Identifier set to 1. An IPv6 address specifying the lower boundary of the IPv6 address pool from which the DHCPv6 server leases IPv6 addresses. If an address range is not explicitly selected, IPV6_ADDR_LOW must be set to the IPv6 address from the Prefix (see the expression above) that has all of the bits of the Interface Identifier set to 0. The Interface Identifier of the selected IPv6 address MUST be compared against the reserved IPv6 Interface Identifiers . In the event that an unacceptable identifier has been generated, the Counter variable SHOULD be incremented by 1, and a new IPv6 address SHOULD be computed with the updated Counter value. If the resulting address is not available (e.g., there is a conflicting binding or the address has been marked as "decliend"), the DHCPv6 server SHOULD increment the Counter variable, and a new Interface Identifier and IPv6 address SHOULD be computed with the updated Counter value. This document requires that SHA-256 be the default function to be used for F(), such that (all other configuration parameters being the same) different implementations of this specification result in the same IPv6 addresses. Including the Prefix in the PRF computation causes the Interface Identifier to be different for each address from a different prefix leased to the same client. This mitigates the correlation of activities of multihomed nodes (since each of the corresponding addresses will employ a different Interface Identifier), host tracking (since the network prefix, and therefore the resulting Interface Identifier, will change as the node moves from one network to another), and any other attacks that benefit from predictable Interface Identifiers . As required by , an IAID is associated with each of the client's network interfaces and is consistent across restarts of the DHCPv6 client. The Counter parameter provides the means to intentionally cause this algorithm to produce different IPv6 addresses (all other parameters being the same). This can be of use to resolve address conflicts (e.g., the resulting address having a conflicting binding). Note that the result of F() in the algorithm above is no more secure than the secret key. If an attacker is aware of the PRF that is being used by the DHCPv6 server (which we should expect), and the attacker can obtain enough material (i.e., addresses generated by the DHCPv6 server), the attacker may simply search the entire secret-key space to find matches. To protect against this, the secret key should be of at least 128 bits. Key lengths of at least 128 bits should be adequate. Providing a mechanism to display and change the secret_key is crucial for having different DHCPv6 servers produce the same IPv6 addresses and for causing a replacement system to generate the same IPv6 addresses as the system being replaced. We note that since the privacy of the scheme specified in this document relies on the secrecy of the secret_key parameter, implementations should constrain access to the secret_key parameter to the extent practicable (e.g., require superuser privileges to access it). Furthermore, in order to prevent leakages of the secret_key parameter, it should not be used for any other purposes than being a parameter to the scheme specified in this document. We note that all of the bits in the resulting Interface Identifiers are treated as "opaque" bits . For example, the universal/local bit of Modified EUI-64 format identifiers is treated as any other bit of such identifier.

This document follows the guidance in for specifying an algorithm for the selection of IPv6 addresses by DHCPv6 servers. The method specified in this document results in IPv6 Interface Identifiers (and hence IPv6 addresses) that do not follow any specific pattern. Thus, attacks that rely on predictable Interface Identifiers (such as ) are mitigated. The method specified in this document neither mitigates nor exacerbates the security considerations for DHCPv6 discussed in and does not mitigate a range of other privacy implications associated with DHCPv6. Please read for a comprehensive assessment of the privacy implications of DHCPv6. Finally, we note that an attacker that is able to attach to each of the links to which the victim attaches may still be able to correlate the activities of the victim across networks. In scenarios where attacks based on DHCPv6-server packets are a concern, usage of operational mitigations such as should be considered.

IANA Federal Information Processing Standards (FIPS)

This document is based on , authored by Fernando Gont and Will Liu. The authors would like to thank Marc Blanchet, Stephane Bortzmeyer, Tatuya Jinmei, Andre Kostur, Ted Lemon, Tomek Mrugalski, Hosnieh Rafiee, Jim Schaad, Jean-Francois Tremblay, Tina Tsou, and Bernie Volz for providing valuable comments on that document. Fernando Gont would like to thank Nelida Garcia and Jorge Gont for their love and support, and Diego Armando Maradona for his magic and inspiration.