Opaque IIDs with DHCPv6: A Method for Generating Semantically Opaque Interface Identifiers (IIDs) with the Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
Generate unpredictable IPv6 addresses on the server side
Gont, F. and W. Liu, "A Method for Generating Semantically Opaque Interface Identifiers (IIDs) with the Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 7943, DOI 10.17487/RFC7943, September 2016, <https://www.rfc-editor.org/info/rfc7943>.
@misc{rfc7943,
series = {Request for Comments},
number = 7943,
howpublished = {RFC 7943},
publisher = {RFC Editor},
doi = {10.17487/RFC7943},
url = {https://www.rfc-editor.org/info/rfc7943},
author = {F. Gont and W. Liu},
title = {{A Method for Generating Semantically Opaque Interface Identifiers (IIDs) with the Dynamic Host Configuration Protocol for IPv6 (DHCPv6)}},
pagetotal = 10,
year = 2016,
month = sep,
} RFC text
Contents
Independent Submission F. Gont
Request for Comments: 7943 SI6 Networks / UTN-FRH
Category: Informational W. Liu
ISSN: 2070-1721 Huawei Technologies
September 2016
A Method for Generating Semantically Opaque Interface Identifiers (IIDs)
with the Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
Abstract
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.
IESG Note
A predecessor to this document was earlier a working group document
in the DHC WG. The WG decided to stop further work in this area
because such work was not considered useful.
The proposal described in this document has an unaddressed failure
case that makes it unsuitable for use as the mechanism to provide the
claimed failover features for DHCPv6 servers. Specifically, when a
DHCPv6 client DECLINEs a provided address there is no recovery
mechanism described that will result in the DHCPv6 client obtaining a
working IPv6 address.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This is a contribution to the RFC Series, independently of any other
RFC stream. The RFC Editor has chosen to publish this document at
its discretion and makes no statement about its value for
implementation or deployment. Documents approved for publication by
the RFC Editor are not a candidate for any level of Internet
Standard; see Section 2 of RFC 7841.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7943.
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Applicability and Design Goals . . . . . . . . . . . . . . . 3
3. Method Specification . . . . . . . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Normative References . . . . . . . . . . . . . . . . . . 8
5.2. Informative References . . . . . . . . . . . . . . . . . 8
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
The benefits of stable IPv6 addresses are discussed in [RFC7721].
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, [RFC7031] 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:
o 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.
o 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 [RFC7031]. 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 [RFC7217].
2. Applicability and Design Goals
This document simply describes 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:
o The resulting IPv6 addresses remain stable within each subnet for
the same network interface of the same client.
o The resulting IPv6 addresses cannot be predicted by an attacker
without knowledge of a secret key.
o The resulting IPv6 addresses remain stable across DHCPv6 server
reinstallations, or even if a database of previous DHCPv6 address
leases is not available.
o The resulting IPv6 addresses remain stable when different DHCPv6
servers (implementing this specification) are employed on the same
network.
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.
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 [RFC7721]).
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 [RFC7844] for a comprehensive
discussion of how DHCPv6 may affect user privacy.
3. Method Specification
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:
1. Compute a random (but stable) identifier with the expression:
RID = F(Prefix | Client_DUID | IAID | Counter | secret_key)
Where:
RID:
Random (but stable) Identifier
F():
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() should 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 [FIPS-SHS]. An
implementation may provide the means for selecting other
algorithms. Note: Message Digest 5 (MD5) [RFC1321] is
considered unacceptable for F() [RFC6151].
Prefix:
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".
Client_DUID:
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.
IAID:
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.
secret_key:
A secret key configured by the DHCPv6 server administrator,
which must not be known by the attacker. It must be encoded
as an array of 8-bit unsigned integers. 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.
Counter:
A 32-bit unsigned integer in network byte order that is
employed to resolve address conflicts. It must be initialized
to 0.
2. 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:
IPV6_ADDR = IPV6_ADDR_LOW +
RID % (IPV6_ADDR_HI - IPV6_ADDR_LOW + 1)
where:
IPV6_ADDR:
The candidate IPv6 address to be leased.
IPV6_ADDR_HI:
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.
IPV6_ADDR_LOW:
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.
3. The Interface Identifier of the selected IPv6 address must be
compared against the reserved IPv6 Interface Identifiers
[RFC5453] [IANA-RESERVED-IID]. 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.
4. If the resulting address is not available (e.g., there is a
conflicting binding), 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 [RFC7721].
As required by [RFC3315], 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 [RFC7136]. For example, the universal/
local bit of Modified EUI-64 format identifiers is treated as any
other bit of such identifier.
4. Security Considerations
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 [RFC7707]) are mitigated.
The method specified in this document neither mitigates nor
exacerbates the security considerations for DHCPv6 discussed in
[RFC3315] and does not mitigate a range of other privacy implications
associated with DHCPv6. Please read [RFC7844] 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 would still be able to
correlate the activities of the victim across networks.
5. References
5.1. Normative References
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
2003, <http://www.rfc-editor.org/info/rfc3315>.
[RFC5453] Krishnan, S., "Reserved IPv6 Interface Identifiers",
RFC 5453, DOI 10.17487/RFC5453, February 2009,
<http://www.rfc-editor.org/info/rfc5453>.
[RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6
Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136,
February 2014, <http://www.rfc-editor.org/info/rfc7136>.
5.2. Informative References
[FIPS-SHS]
Federal Information Processing Standards (FIPS), "Secure
Hash Standard (SHS)", FIPS 180-4, August 2015,
<http://csrc.nist.gov/publications/fips/fips180-4/
fips-180-4.pdf>.
[IANA-RESERVED-IID]
IANA, "Reserved IPv6 Interface Identifiers",
<http://www.iana.org/assignments/ipv6-interface-ids>.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
DOI 10.17487/RFC1321, April 1992,
<http://www.rfc-editor.org/info/rfc1321>.
[RFC6151] Turner, S. and L. Chen, "Updated Security Considerations
for the MD5 Message-Digest and the HMAC-MD5 Algorithms",
RFC 6151, DOI 10.17487/RFC6151, March 2011,
<http://www.rfc-editor.org/info/rfc6151>.
[RFC7031] Mrugalski, T. and K. Kinnear, "DHCPv6 Failover
Requirements", RFC 7031, DOI 10.17487/RFC7031, September
2013, <http://www.rfc-editor.org/info/rfc7031>.
[RFC7217] Gont, F., "A Method for Generating Semantically Opaque
Interface Identifiers with IPv6 Stateless Address
Autoconfiguration (SLAAC)", RFC 7217,
DOI 10.17487/RFC7217, April 2014,
<http://www.rfc-editor.org/info/rfc7217>.
[RFC7707] Gont, F. and T. Chown, "Network Reconnaissance in IPv6
Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016,
<http://www.rfc-editor.org/info/rfc7707>.
[RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy
Considerations for IPv6 Address Generation Mechanisms",
RFC 7721, DOI 10.17487/RFC7721, March 2016,
<http://www.rfc-editor.org/info/rfc7721>.
[RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity
Profiles for DHCP Clients", RFC 7844,
DOI 10.17487/RFC7844, May 2016,
<http://www.rfc-editor.org/info/rfc7844>.
Acknowledgements
This document is based on [RFC7217], authored by Fernando Gont.
The authors would like to thank Marc Blanchet, Stephane Bortzmeyer,
Tatuya Jinmei, Andre Kostur, Tomek Mrugalski, Hosnieh Rafiee, Jim
Schaad, Jean-Francois Tremblay, Tina Tsou, and Bernie Volz for
providing valuable comments on earlier draft versions of this
documents.
The authors would like to thank Ted Lemon, who kindly answered some
DHCPv6-related questions, and Nevil Brownlee for his guidance while
pursuing this document.
Fernando Gont would like to thank Nelida Garcia and Guillermo Gont
for their love and support, and Diego Armando Maradona for his magic
and inspiration.
Authors' Addresses
Fernando Gont
SI6 Networks / UTN-FRH
Evaristo Carriego 2644
Haedo, Provincia de Buenos Aires 1706
Argentina
Phone: +54 11 4650 8472
Email: fgont@si6networks.com
URI: http://www.si6networks.com
Will (Shucheng) Liu
Huawei Technologies
Bantian, Longgang District
Shenzhen 518129
China
Email: liushucheng@huawei.com
AI ELI5
On this page
§1Introduction
DHCPv6 is the protocol that assigns IPv6 addresses to devices on a network. Traditionally, servers could assign addresses in predictable sequences or based on device hardware identifiers. RFC 7943 describes a method for DHCPv6 servers to select semantically opaque interface identifiers (the host portion of the IPv6 address) so that addresses do not reveal information about the client or follow a guessable pattern.
This is a server-side algorithm that requires no changes to existing DHCPv6 specifications or client software. It works by computing a cryptographic hash of the client's DUID (unique identifier), the network prefix, and a secret key known only to the server. The result is an address that is stable (the same client always gets the same address in the same subnet) yet unpredictable to outsiders.
DHCPv6 is how devices get their IPv6 address from a server. This RFC shows how the server can pick addresses that look random but are actually consistent for each client.
§2Design Goals
RFC 7943 aims to achieve four properties. First, addresses remain stable within each subnet for the same client, even if different DHCPv6 servers (all running this algorithm with the same secret key) assign the address. Second, an attacker cannot predict what address a client will receive without knowing the secret key, even if they know other addresses on the network. Third, addresses remain stable across server reinstallations or loss of the lease database, since they are computed rather than looked up. Fourth, multiple servers can independently generate the same addresses for the same client without sharing state, which simplifies failover scenarios.
The RFC emphasizes that this algorithm only mitigates address-based tracking and device fingerprinting. It does not address all privacy concerns related to DHCPv6, such as the fact that servers can see which clients are requesting addresses.
The goal is addresses that are the same for each client, unpredictable to attackers, and survive server reboots without needing a database.
§3The Algorithm
The algorithm works in four steps. First, compute a random but stable identifier (RID) using a pseudorandom function F. The input includes the network prefix (128-bit), the client's DUID, the IAID (Identity Association Identifier from the DHCPv6 request), a counter starting at 0, and a secret key. The default function is SHA-256, though implementations may offer others. The output must be at least 64 bits.
Second, use the RID to derive a candidate IPv6 address by adding the RID (modulo the address pool size) to the pool's lower boundary. Third, check the resulting address against reserved interface identifiers. If reserved, increment the counter and recompute. Fourth, if the address is already in use (conflicting binding), increment the counter and try again. Through this process, the algorithm naturally handles address conflicts and reserved patterns by simply trying the next value in the sequence determined by the RID.
Mix the client ID, network prefix, and secret key through a hash function to get a number. Use that number to pick an address from the available range. If someone already has that address, try the next number.
§4Security Parameters
The secret key is the foundation of the algorithm's security. All DHCPv6 servers leasing addresses from the same pool must use the same secret key so they generate the same addresses for the same clients. The key must be kept confidential and should be at least 128 bits long; key lengths of 256 bits are recommended. If an attacker learns the secret key, they can predict all future addresses.
The prefixing of the hash input with the network prefix ensures that different subnets produce different addresses for the same client, which prevents correlation of activities across networks. Including the IAID ensures that different address associations for the same client (e.g., on different interfaces) get different addresses. Implementations MUST provide an interface for administrators to view and change the secret key, and access to it should be restricted (e.g., superuser only) because its secrecy is critical.
The secret key is like a password the server uses to generate addresses. Bigger keys (256 bits) are better. Different networks get different addresses from the same key.
§5Deployment
This algorithm is purely a server-side decision and requires no changes to clients or to the DHCPv6 specification. An administrator can enable or disable it per server. It works with existing DHCPv6 implementations because it only affects how the server selects which address to offer to a client.
When replacing a DHCPv6 server or reinstalling one, administrators can keep the same secret key to ensure the replacement system generates the same addresses as the original. This is crucial for maintaining stable address assignments across maintenance events. The method is especially useful in scenarios with multiple servers on the same network or embedded devices that cannot maintain a persistent lease database.
The server can turn this on or off without telling clients anything different. And if the server crashes and restarts, it can still assign the same addresses as before because it just recomputes them.