summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7824.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7824.txt')
-rw-r--r--doc/rfc/rfc7824.txt1011
1 files changed, 1011 insertions, 0 deletions
diff --git a/doc/rfc/rfc7824.txt b/doc/rfc/rfc7824.txt
new file mode 100644
index 0000000..be1399e
--- /dev/null
+++ b/doc/rfc/rfc7824.txt
@@ -0,0 +1,1011 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) S. Krishnan
+Request for Comments: 7824 Ericsson
+Category: Informational T. Mrugalski
+ISSN: 2070-1721 ISC
+ S. Jiang
+ Huawei Technologies Co., Ltd.
+ May 2016
+
+
+ Privacy Considerations for DHCPv6
+
+Abstract
+
+ DHCPv6 is a protocol that is used to provide addressing and
+ configuration information to IPv6 hosts. This document describes the
+ privacy issues associated with the use of DHCPv6 by Internet users.
+ It is intended to be an analysis of the present situation and does
+ not propose any solutions.
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for informational purposes.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Not all documents
+ approved by the IESG are a candidate for any level of Internet
+ Standard; see Section 2 of RFC 5741.
+
+ 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/rfc7824.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Krishnan, et al. Informational [Page 1]
+
+RFC 7824 DHCPv6 Privacy Considerations May 2016
+
+
+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. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Krishnan, et al. Informational [Page 2]
+
+RFC 7824 DHCPv6 Privacy Considerations May 2016
+
+
+Table of Contents
+
+ 1. Introduction ....................................................4
+ 2. Terminology .....................................................4
+ 3. Identifiers in DHCPv6 Options and Fields ........................5
+ 3.1. Source IPv6 Address ........................................5
+ 3.2. DUID .......................................................5
+ 3.3. Client Identifier Option ...................................6
+ 3.4. IA_NA, IA_TA, IA_PD, IA Address, and IA Prefix Options .....6
+ 3.5. Client FQDN Option .........................................6
+ 3.6. Client Link-Layer Address Option ...........................7
+ 3.7. Option Request Option ......................................7
+ 3.8. Vendor Class and Vendor-Specific Information Options .......7
+ 3.9. Civic Location Option ......................................8
+ 3.10. Coordinate-Based Location Option ..........................8
+ 3.11. Client System Architecture Type Option ....................8
+ 3.12. Relay Agent Options .......................................8
+ 3.12.1. Subscriber-ID Option ...............................9
+ 3.12.2. Interface ID Option ................................9
+ 3.12.3. Remote ID Option ...................................9
+ 3.12.4. Relay-ID Option ....................................9
+ 4. Existing Mechanisms That Affect Privacy ........................10
+ 4.1. Temporary Addresses .......................................10
+ 4.2. DNS Updates ...............................................10
+ 4.3. Allocation Strategies .....................................10
+ 5. Attacks ........................................................12
+ 5.1. Device Type Discovery (Fingerprinting) ....................12
+ 5.2. Operating System Discovery (Fingerprinting) ...............12
+ 5.3. Finding Location Information ..............................12
+ 5.4. Finding Previously Visited Networks .......................13
+ 5.5. Finding a Stable Identity .................................13
+ 5.6. Pervasive Monitoring ......................................13
+ 5.7. Finding a Client's IP Address or Hostname .................14
+ 5.8. Correlation of Activities over Time .......................14
+ 5.9. Location Tracking .........................................14
+ 5.10. Leasequery and Bulk Leasequery ...........................15
+ 6. Security Considerations ........................................15
+ 7. Privacy Considerations .........................................15
+ 8. References .....................................................16
+ 8.1. Normative References ......................................16
+ 8.2. Informative References ....................................16
+ Acknowledgements ..................................................18
+ Authors' Addresses ................................................18
+
+
+
+
+
+
+
+
+Krishnan, et al. Informational [Page 3]
+
+RFC 7824 DHCPv6 Privacy Considerations May 2016
+
+
+1. Introduction
+
+ DHCPv6 [RFC3315] is a protocol that is used to provide addressing and
+ configuration information to IPv6 hosts. DHCPv6 uses several
+ identifiers that could become a source for gleaning information about
+ the IPv6 host. This information may include device type, operating
+ system information, location(s) that the device may have previously
+ visited, etc. This document discusses the various identifiers used
+ by DHCPv6 and the potential privacy issues [RFC6973]. In particular,
+ it also takes into consideration the problem of pervasive monitoring
+ [RFC7258].
+
+ Future works may propose protocol changes to fix the privacy issues
+ that have been analyzed in this document. See [RFC7844] for one of
+ such changes. Protocol changes are out of scope for this document.
+
+ The primary focus of this document is around privacy considerations
+ for clients to support client mobility and connection to random
+ networks. The privacy of DHCPv6 servers and relay agents are
+ considered less important as they are typically open for public
+ services. And, it is generally assumed that communication from the
+ relay agent to the server is protected from casual snooping, as that
+ communication occurs in the provider's backbone. Nevertheless, the
+ topics involving relay agents and servers are explored to some
+ degree. However, future work may want to further explore privacy of
+ DHCPv6 servers and relay agents.
+
+2. Terminology
+
+ Naming conventions from [RFC3315] and other DHCPv6-related RFCs are
+ used throughout this document. In addition, the following term is
+ used:
+
+ Stable identifier: Any property disclosed by a DHCPv6 client that
+ does not change over time or changes very infrequently and is
+ unique for said client in a given context. Examples include
+ Media Access Control (MAC) address, client-id, and a
+ hostname. Some identifiers may be considered stable only
+ under certain conditions; for example, one client
+ implementation may keep its client-id stored in stable
+ storage whereas another may generate it on the fly and use a
+ different one after each boot. Stable identifiers may or may
+ not be globally unique.
+
+
+
+
+
+
+
+
+Krishnan, et al. Informational [Page 4]
+
+RFC 7824 DHCPv6 Privacy Considerations May 2016
+
+
+3. Identifiers in DHCPv6 Options and Fields
+
+ In DHCPv6, there are many options that include identification
+ information or that can be used to extract identification information
+ about the client. This section enumerates various options or fields
+ and the identifiers conveyed in them, which can be used to disclose
+ client identification. The attacks that are enabled by such
+ disclosures are detailed in Section 5.
+
+3.1. Source IPv6 Address
+
+ Although an IPv6 link-local address is technically not a part of
+ DHCPv6, it appears in the DHCPv6 transmissions, so it is mentioned
+ here for completeness.
+
+ If the client does not use privacy extensions (see [RFC4941]) or
+ similar solutions and its IPv6 link-local address is based on a
+ physical link-layer address, this information is disclosed to the
+ DHCPv6 server and to anyone who manages to intercept this
+ transmission.
+
+ There are multiple cases where IPv6 link-local addresses are used in
+ DHCPv6. Initial client transmissions are always sent from the IPv6
+ link-local addresses even when the server unicast option (see
+ Sections 22.12 and 18 of [RFC3315] for details) is enabled. If there
+ are relay agents, they forward the client's traffic wrapped in Relay-
+ forward and store original source IPv6 address in peer-address field.
+
+3.2. DUID
+
+ Each DHCPv6 client and server has a DHCP Unique Identifier (DUID)
+ [RFC3315]. The DUID is designed to be unique across all DHCPv6
+ clients and servers and to remain stable after it has been initially
+ generated. The DUID can be of different forms. Commonly used forms
+ are based on the link-layer address of one of the device's network
+ interfaces (with or without a timestamp) [RFC3315], or on the
+ Universally Unique IDentifier (UUID) [RFC6355]. The default type,
+ defined in Section 9.2 of [RFC3315] is DUID-LLT that is based on
+ link-layer address. It is commonly implemented in most popular
+ clients.
+
+ It is important to understand DUID life cycle. Clients and servers
+ are expected to generate their DUID once (during first operation) and
+ store it in a non-volatile storage or use the same deterministic
+ algorithm to generate the same DUID value again. This means that
+ most implementations will use the available link-layer address during
+ their first boot. Even if the administrator enables link-layer
+ address randomization, it is likely that it was not yet enabled
+
+
+
+Krishnan, et al. Informational [Page 5]
+
+RFC 7824 DHCPv6 Privacy Considerations May 2016
+
+
+ during the first device boot. Hence, the original, unobfuscated
+ link-layer address will likely end up being announced as the client
+ DUID, even if the link-layer address has changed (or even if being
+ changed on a periodic basis). The exposure of the original link-
+ layer address in DUID will also undermine other privacy extensions
+ such as [RFC4941].
+
+3.3. Client Identifier Option
+
+ The Client Identifier option (OPTION_CLIENTID) [RFC3315] is used to
+ carry the DUID of a DHCPv6 client between a client and a server.
+ There is an analogous Server Identifier Option, but it is not as
+ interesting in the privacy context (unless a host can be convinced to
+ start acting as a server). See Section 3.2 for relevant discussion
+ about DUIDs.
+
+3.4. IA_NA, IA_TA, IA_PD, IA Address, and IA Prefix Options
+
+ The Identity Association for Non-temporary Addresses (IA_NA) option
+ [RFC3315] is used to carry the parameters and any non-temporary
+ addresses associated with the given IA_NA. The Identity Association
+ for Temporary Addresses (IA_TA) option [RFC3315] is analogous to the
+ IA_NA option but is used for temporary addresses. The IA Address
+ option [RFC3315] is used to specify IPv6 addresses associated with an
+ IA_NA or an IA_TA and is encapsulated within the Options field of
+ such an IA_NA or IA_TA option. The Identity Association for Prefix
+ Delegation (IA_PD) [RFC3633] option is used to carry the prefixes
+ that are assigned to the requesting router. IA Prefix option
+ [RFC3633] is used to specify IPv6 prefixes associated with an IA_PD
+ and is encapsulated within the Options field of such an IA_PD option.
+
+ To differentiate between instances of the same type of IA containers
+ for a client, each IA_NA, IA_TA, and IA_PD options have an IAID field
+ with a unique value for a given IA type. It is up to the client to
+ pick unique IAID values. At least one popular implementation uses
+ the last four octets of the link-layer address. In most cases, that
+ means that merely two bytes are missing for a full link-layer address
+ reconstruction. However, the first three octets in a typical link-
+ layer address are vendor identifiers. That can be determined with a
+ high level of certainty using other means, thus allowing full link-
+ layer address discovery.
+
+3.5. Client FQDN Option
+
+ The Client Fully Qualified Domain Name (FQDN) option [RFC4704] is
+ used by DHCPv6 clients and servers to exchange information about the
+ client's FQDN and about who has the responsibility for updating the
+ DNS with the associated AAAA and PTR RRs.
+
+
+
+Krishnan, et al. Informational [Page 6]
+
+RFC 7824 DHCPv6 Privacy Considerations May 2016
+
+
+ A client can use this option to convey all or part of its domain name
+ to a DHCPv6 server for the IPv6-address-to-FQDN mapping. In most
+ cases, a client sends its hostname as a hint for the server. The
+ DHCPv6 server may be configured to modify the supplied name or to
+ substitute a different name. The server should send its notion of
+ the complete FQDN for the client in the Domain Name field.
+
+3.6. Client Link-Layer Address Option
+
+ The client link-layer address option [RFC6939] is used by first-hop
+ DHCPv6 relays to provide the client's link-layer address towards the
+ server.
+
+ DHCPv6 relay agents that receive messages originating from clients
+ may include the link-layer source address of the received DHCPv6
+ message in the client link-layer address option, in relayed DHCPv6
+ Relay-forward messages.
+
+3.7. Option Request Option
+
+ DHCPv6 clients include an Option Request option [RFC3315] in DHCPv6
+ messages to inform the server about options the client wants the
+ server to send to the client.
+
+ The contents of an Option Request option are the option codes for
+ options requested by the client. The client may additionally include
+ instances of those options that are identified in the Option Request
+ option, with data values as hints to the server about parameter
+ values the client would like to have returned.
+
+3.8. Vendor Class and Vendor-Specific Information Options
+
+ The Vendor Class option, defined in Section 22.16 of [RFC3315], is
+ used by a DHCPv6 client to identify the vendor that manufactured the
+ hardware on which the client is running.
+
+ The Vendor-specific information option, defined in Section 22.17 of
+ [RFC3315], includes enterprise number, which identifies the client's
+ vendor and often includes a number of additional parameters that are
+ specific to a given vendor. That may include any type of information
+ the vendor deems useful. It should be noted that this information
+ may be present (and different) in both directions: client-to-server
+ and server-to-client communications.
+
+
+
+
+
+
+
+
+Krishnan, et al. Informational [Page 7]
+
+RFC 7824 DHCPv6 Privacy Considerations May 2016
+
+
+ The information contained in the data area of this option is
+ contained in one or more opaque fields that identify details of the
+ hardware configuration, for example, the version of the operating
+ system the client is running or the amount of memory installed on the
+ client.
+
+3.9. Civic Location Option
+
+ DHCPv6 servers use the Civic Location option [RFC4776] to deliver
+ location information (the civic and postal addresses) from the DHCPv6
+ server to DHCPv6 clients. It may refer to three locations: the
+ location of the DHCPv6 server, the location of the network element
+ believed to be closest to the client, or the location of the client,
+ identified by the "what" element within the option.
+
+3.10. Coordinate-Based Location Option
+
+ The GeoLoc options [RFC6225] are used by the DHCPv6 server to provide
+ coordinate-based geographic location information to DHCPv6 clients.
+ They enable a DHCPv6 client to obtain its location.
+
+3.11. Client System Architecture Type Option
+
+ The Client System Architecture Type option [RFC5970] is used by the
+ DHCPv6 client to send a list of supported architecture types to the
+ DHCPv6 server. It is used by clients that must be booted using the
+ network rather than from local storage, so the server can decide
+ which boot file should be provided to the client.
+
+3.12. Relay Agent Options
+
+ A DHCPv6 relay agent may include a number of options. Those options
+ contain information that can be used to identify the client. Those
+ options are almost exclusively exchanged between the relay agent and
+ the server, thus never leaving the operators network. In particular,
+ they're almost never present in the last wireless hop in case of WiFi
+ networks. The only exception to that rule is somewhat infrequently
+ used Relay-Supplied Options option [RFC6422]. This fact implies that
+ the threat-model-related relay options are slightly different.
+ Traffic sniffing at the last hop and related class of attacks
+ typically do not apply. On the other hand, all attacks that involve
+ the operator's infrastructure (either willing or coerced cooperation
+ or infrastructure being compromised) usually apply.
+
+ The following subsections describe various options inserted by the
+ relay agents.
+
+
+
+
+
+Krishnan, et al. Informational [Page 8]
+
+RFC 7824 DHCPv6 Privacy Considerations May 2016
+
+
+3.12.1. Subscriber-ID Option
+
+ A DHCPv6 relay may include a Subscriber-ID option [RFC4580] to
+ associate some provider-specific information with clients' DHCPv6
+ messages that is independent of the physical network configuration.
+
+ In many deployments, the relay agent that inserts this option is
+ configured to use client's link-layer address as Subscriber-ID.
+
+3.12.2. Interface ID Option
+
+ A DHCPv6 relay includes the Interface ID option [RFC3315] to identify
+ the interface on which it received the client message that is being
+ relayed.
+
+ Although, in principle, the Interface ID can be arbitrarily long with
+ completely random values, it is sometimes a text string that includes
+ the relay agent name followed by the interface name. This can be
+ used for fingerprinting the relay or determining a client's point of
+ attachment.
+
+3.12.3. Remote ID Option
+
+ A DHCPv6 relay includes a Remote ID option [RFC4649] to identify the
+ remote host end of the circuit.
+
+ The remote-id is vendor specific, for which the vendor is indicated
+ in the enterprise-number field. The remote-id field may encode the
+ information that identified DHCPv6 clients:
+
+ o a "caller ID" telephone number for dial-up connection
+
+ o a "user name" prompted for by a Remote Access Server
+
+ o a remote caller ATM address o a "modem ID" of a cable data modem
+
+ o the remote IP address of a point-to-point link
+
+ o an interface or port identifier
+
+3.12.4. Relay-ID Option
+
+ Relay agent may include Relay-ID option [RFC5460], which contains a
+ unique relay agent identifier. While its intended use is to provide
+ additional information for the server, so it would be able to respond
+ to leasequeries later, this information can be also used to identify
+ a client's location within the network.
+
+
+
+
+Krishnan, et al. Informational [Page 9]
+
+RFC 7824 DHCPv6 Privacy Considerations May 2016
+
+
+4. Existing Mechanisms That Affect Privacy
+
+ This section describes deployed DHCPv6 mechanisms that can affect
+ privacy.
+
+4.1. Temporary Addresses
+
+ [RFC3315] defines a mechanism for a client to request temporary
+ addresses. The idea behind temporary addresses is that a client can
+ request a temporary address for a specific purpose, use it, and then
+ never renew it (i.e., let it expire).
+
+ There are a number of serious issues, both related to protocol and
+ its implementations, that make temporary addresses nearly useless for
+ their original goal. First, [RFC3315] does not include T1 and T2
+ renewal timers in IA_TA (a container for temporary addresses).
+ However, in Section 18.1.3, it explicitly mentions that temporary
+ addresses can be renewed. Client implementations may mistakenly
+ renew temporary addresses if they are not careful (i.e., by including
+ the IA_TA with the same IAID in Renew or Rebind requests, rather than
+ a new IAID -- see Section 22.5 of [RFC3315]), thus forfeiting short
+ liveness. [RFC4704] does not explicitly prohibit servers from
+ updating DNS for assigned temporary addresses, and there are
+ implementations that can be configured to do that. However, this is
+ not advised as publishing a client's IPv6 address in DNS that is
+ publicly available is a major privacy breach.
+
+4.2. DNS Updates
+
+ The Client FQDN option [RFC4704] used along with DNS UPDATE [RFC2136]
+ defines a mechanism that allows both clients and the server to insert
+ information about clients into the DNS domain. Both forward (AAAA)
+ and reverse (PTR) resource records can be updated. This allows other
+ nodes to conveniently refer to a host, despite the fact that its IPv6
+ address may be changing.
+
+ This mechanism exposes two important pieces of information: the
+ current address (which can be mapped to current location) and a
+ client's hostname. The stable hostname can then by used to correlate
+ the client across different network attachments even when its IPv6
+ address keeps changing.
+
+4.3. Allocation Strategies
+
+ A DHCPv6 server running in typical, stateful mode is given a task of
+ managing one or more pools of IPv6 resources (currently non-temporary
+ addresses, temporary addresses and/or prefixes, but more resource
+ types may be defined in the future). When a client requests a
+
+
+
+Krishnan, et al. Informational [Page 10]
+
+RFC 7824 DHCPv6 Privacy Considerations May 2016
+
+
+ resource, the server must pick a resource out of the configured pool.
+ Depending on the server's implementation, various allocation
+ strategies are possible. Choices in this regard may have privacy
+ implications.
+
+ Iterative allocation: a server may choose to allocate addresses one
+ by one. That strategy has the benefit of being very fast, thus
+ being favored in deployments that prefer performance. However, it
+ makes the resources very predictable. Also, since the resources
+ allocated tend to be clustered at the beginning of an available
+ pool, it makes scanning attacks much easier.
+
+ Identifier-based allocation: some server implementations use a fixed
+ identifier for a specific client, seemingly taken from the
+ client's MAC address when available or some lower bits of client's
+ source IPv6 address. This has a property of being convenient for
+ converting IP address to/from other identifiers, especially if the
+ identifier is or contains a MAC address. It is also convenient,
+ as a returning client is very likely to get the same address, even
+ if the server does not retain the client's previous address.
+ Those properties are convenient for system administrators, so
+ DHCPv6 server implementors are sometimes requested to implement
+ it. There is at least one implementation that supports it. The
+ downside of such allocation is that the client now discloses its
+ identifier in its IPv6 address to all services to which it
+ connects. That means that attacks related to the correlation of
+ activities over time, location tracking, address scanning, and OS/
+ vendor discovery apply.
+
+ Hash allocation: an extension of identifier-based allocation.
+ Instead of using the identifier directly, it is hashed first. If
+ the hash is implemented correctly, it removes the flaw of
+ disclosing the identifier, a property that eliminates
+ susceptibility to address scanning and OS/vendor discovery. If
+ the hash is poorly implemented (e.g., can be reversed), it
+ introduces no improvement over identifier-based allocation. Even
+ a well-implemented hash does not mitigate the threat of
+ correlation over time.
+
+ Random allocation: a server can pick a resource pseudorandomly out
+ of an available pool. This allocation scheme essentially prevents
+ returning clients from getting the same address or prefix again.
+ On the other hand, it is beneficial from a privacy perspective as
+ addresses and prefixes generated that way are not susceptible to
+ correlation attacks, OS/vendor discovery attacks, or identity
+ discovery attacks. Note that even though the address or prefix
+ itself may be resilient to a given attack, the client may still be
+
+
+
+
+Krishnan, et al. Informational [Page 11]
+
+RFC 7824 DHCPv6 Privacy Considerations May 2016
+
+
+ susceptible if additional information is disclosed other way; for
+ example, the client's address may be randomized, but it still can
+ leak its MAC address in the Client Identifier option.
+
+ Other allocation strategies may be implemented.
+
+5. Attacks
+
+5.1. Device Type Discovery (Fingerprinting)
+
+ The type of device used by the client can be guessed by the attacker
+ using the Vendor Class option, Vendor-specific information option,
+ the client link-layer address option, and by parsing the Client
+ Identifier option. All of those options may contain OUI
+ (Organizationally Unique Identifier) that represents the device's
+ vendor. That knowledge can be used for device-specific vulnerability
+ exploitation attacks. See Section 3.4 of [RFC7721] for a discussion
+ about this type of attack.
+
+5.2. Operating System Discovery (Fingerprinting)
+
+ The operating system running on a client can be guessed using the
+ Vendor Class option, the Vendor-specific information option, the
+ Client System Architecture Type option, or by using fingerprinting
+ techniques on the combination of options requested using the Option
+ Request option.
+
+5.3. Finding Location Information
+
+ The physical location information can be obtained by the attacker by
+ many means. The most direct way to obtain this information is by
+ looking into a message originating from the server that contains the
+ Civic Location or GeoLoc options. It can also be indirectly inferred
+ using the Remote ID option, the Interface ID option (e.g., if an
+ access circuit on an Access Node corresponds to a civic location), or
+ the Subscriber-ID option (if the attacker has access to subscriber
+ info).
+
+ Another way to discover a client's physical location is to use
+ geolocation services. Those services typically map IP prefixes into
+ geographical locations. The services are usually based on known
+ locations of the subnet, so they may reveal a client's location to
+ the extent of the network to which it is connected, if they can
+ locate the network. However, they usually are not able to discover
+ specific physical location within a network. That is not always true
+ and it depends on the quality of the a priori information available
+ in the geolocation services databases. It should be noted that this
+ threat is general to the DHCPv6 mechanism. Regardless of the
+
+
+
+Krishnan, et al. Informational [Page 12]
+
+RFC 7824 DHCPv6 Privacy Considerations May 2016
+
+
+ allocation strategy used by the DHCPv6 server implementation, the
+ addresses assigned will always belong to the subnet the server is
+ configured to manage. Cases of using ULAs (Unique Local Addresses)
+ assigned by the DHCPv6 server are out of scope for this document.
+
+5.4. Finding Previously Visited Networks
+
+ When DHCPv6 clients reconnect to a network, they attempt to obtain
+ the same address they used when they previously attached to that
+ network. They do this by putting the previously assigned address(es)
+ in the IA Address option(s). [RFC3315] does not exclude IA_TA in
+ such a case, so it is possible that a client implementation includes
+ an address contained in an IA_TA for the Confirm message. By
+ observing these addresses, an attacker can identify the network the
+ client had previously visited.
+
+5.5. Finding a Stable Identity
+
+ An attacker might use a stable identity gleaned from DHCPv6 messages
+ to correlate activities of a given client on unrelated networks. The
+ Client FQDN option, the Subscriber-ID option, and the Client ID
+ option can serve as long-lived identifiers of DHCPv6 clients. The
+ Client FQDN option can also provide an identity that can easily be
+ correlated with web server activity logs.
+
+ It should be noted that in the general case, the MAC addresses as
+ such are not available in the DHCPv6 packets. Therefore, they cannot
+ be used directly in a reliable way. However, they may become
+ indirectly available using other mechanisms: the client-id contains
+ the link-local address if DUID-LL or DUID-LLT types are used, the
+ source IPv6 address may use an EUI-64 that contains a MAC address,
+ some access technologies may specify a MAC address in dedicated
+ options (e.g., cable modems use MAC addresses in Data Over Cable
+ Service Interface Specification (DOCSIS) options). Relay agents may
+ insert additional information that is used to help the server to
+ identify the client. This could be the Remote-Id option, Subscriber-
+ ID option, client link-layer address option or Vendor-specific
+ information options. Options inserted by relay agents usually
+ traverse only the relay-server path, so they typically can't be
+ eavesdropped by intercepting the client's transmissions. This
+ depends on the actual deployment model and used access technologies.
+
+5.6. Pervasive Monitoring
+
+ Pervasive Monitoring (PM) is widespread (and often covert)
+ surveillance through intrusive gathering of protocol artifacts,
+ including application content or protocol metadata such as headers.
+ Active or passive wiretaps and traffic analysis, (e.g., correlation,
+
+
+
+Krishnan, et al. Informational [Page 13]
+
+RFC 7824 DHCPv6 Privacy Considerations May 2016
+
+
+ timing or measuring packet sizes) or subverting the cryptographic
+ keys used to secure protocols can also be used as part of pervasive
+ monitoring. PM is distinguished by being indiscriminate and very
+ large scale; it does not necessarily introduce new types of technical
+ compromise. See [RFC7258] for a discussion about PM.
+
+ In the DHCPv6 context, the PM approach can be used to collect any
+ identifiers discussed in Section 3. DHCPv4 and DHCPv6 are especially
+ susceptible as the initial message sent (SOLICIT in the case of
+ DHCPv6) is one of the very first packets sent when visiting a
+ network. Furthermore, in certain cases, this packet can be logged
+ even on networks that do not support IPv6 (some implementations
+ initiate DHCPv6 even without receiving RA with M or O bits set).
+ This may be an easily overlooked attack vector when an IPv6-capable
+ device connects to an IPv4-only network, gains only IPv4
+ connectivity, but still leaks its stable identifiers over DHCPv6.
+
+ Using the PM approach, the attacks discussed in Sections 5.1, 5.2,
+ 5.3, 5.4, 5.5, 5.7, 5.8, and possibly 5.9, apply.
+
+5.7. Finding a Client's IP Address or Hostname
+
+ Many DHCPv6 deployments use DNS Updates [RFC4704] that put client's
+ information (current IP address, client's hostname) into the DNS,
+ where it is easily accessible by anyone interested. Client ID is
+ also disclosed, albeit in not an easily accessible form (SHA-256
+ digest of the client-id). As SHA-256 is considered irreversible,
+ DHCID can't be converted back to client-id. However, SHA-256 digest
+ can be used as an unique identifier that is accessible by any host.
+
+5.8. Correlation of Activities over Time
+
+ As with other identifiers, an IPv6 address can be used to correlate
+ the activities of a host for at least as long as the lifetime of the
+ address. If that address was generated from some other, stable
+ identifier and that generation scheme can be deduced by an attacker,
+ the duration of the correlation attack extends to that of the
+ identifier. In many cases, its lifetime is equal to the lifetime of
+ the device itself. See Section 3.1 of [RFC7721] for detailed
+ discussion.
+
+5.9. Location Tracking
+
+ If a stable identifier is used for assigning an address and such
+ mapping is discovered by an attacker (e.g., a server that uses IEEE-
+ identifier-based IID to generate an IPv6 address), all scenarios
+ discussed in Section 3.2 of [RFC7721] apply. In particular, both
+ passive (a service that the client connects to can log the client's
+
+
+
+Krishnan, et al. Informational [Page 14]
+
+RFC 7824 DHCPv6 Privacy Considerations May 2016
+
+
+ address and draw conclusions regarding its location and movement
+ patterns based on the prefix it is connecting from) and active (an
+ attacker can send ICMPv6 echo requests or other probe packets to
+ networks of suspected client locations) can be used. To give a
+ specific example, by accessing a social portal from
+ tomek-laptop.coffee.somecity.com.example,
+ tomek-laptop.mycompany.com.example, and
+ tomek-laptop.myisp.example.com, the portal administrator can draw
+ conclusions about tomek-laptop's owner's current location and his
+ habits.
+
+5.10. Leasequery and Bulk Leasequery
+
+ Attackers may masquerade as an access concentrator, either as a
+ DHCPv6 relay agent or as a DHCPv6 client, to obtain location
+ information directly from the DHCPv6 server(s) using the DHCPv6
+ Leasequery [RFC5007] mechanism.
+
+ Location information is information needed by the access concentrator
+ to forward traffic to a broadband-accessible host. This information
+ includes knowledge of the host hardware address, the port or virtual
+ circuit that leads to the host, and/or the hardware address of the
+ intervening subscriber modem.
+
+ Furthermore, the attackers may use the DHCPv6 bulk leasequery
+ [RFC5460] mechanism to obtain bulk information about DHCPv6 bindings,
+ even without knowing the target bindings.
+
+ Additionally, active leasequery [RFC7653] is a mechanism for
+ subscribing to DHCPv6 lease update changes in near real-time. The
+ intent of this mechanism is to update an operator's database;
+ however, if the mechanism is misused, an attacker could defeat the
+ server's authentication mechanisms and subscribe to all updates. He
+ then could continue receiving updates, without any need for local
+ presence.
+
+6. Security Considerations
+
+ In current practice, the client privacy and client authentication are
+ mutually exclusive. The client authentication procedure reveals
+ additional client information in their certificates/identifiers.
+ Full privacy for the clients may mean the clients are also anonymous
+ to the server and the network.
+
+7. Privacy Considerations
+
+ This document in its entirety discusses privacy considerations in
+ DHCPv6. As such, no dedicated discussion is needed.
+
+
+
+Krishnan, et al. Informational [Page 15]
+
+RFC 7824 DHCPv6 Privacy Considerations May 2016
+
+
+8. References
+
+8.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>.
+
+ [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
+ Morris, J., Hansen, M., and R. Smith, "Privacy
+ Considerations for Internet Protocols", RFC 6973,
+ DOI 10.17487/RFC6973, July 2013,
+ <http://www.rfc-editor.org/info/rfc6973>.
+
+ [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
+ Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
+ 2014, <http://www.rfc-editor.org/info/rfc7258>.
+
+ [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>.
+
+8.2. Informative References
+
+ [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
+ "Dynamic Updates in the Domain Name System (DNS UPDATE)",
+ RFC 2136, DOI 10.17487/RFC2136, April 1997,
+ <http://www.rfc-editor.org/info/rfc2136>.
+
+ [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
+ Host Configuration Protocol (DHCP) version 6", RFC 3633,
+ DOI 10.17487/RFC3633, December 2003,
+ <http://www.rfc-editor.org/info/rfc3633>.
+
+ [RFC4580] Volz, B., "Dynamic Host Configuration Protocol for IPv6
+ (DHCPv6) Relay Agent Subscriber-ID Option", RFC 4580,
+ DOI 10.17487/RFC4580, June 2006,
+ <http://www.rfc-editor.org/info/rfc4580>.
+
+ [RFC4649] Volz, B., "Dynamic Host Configuration Protocol for IPv6
+ (DHCPv6) Relay Agent Remote-ID Option", RFC 4649,
+ DOI 10.17487/RFC4649, August 2006,
+ <http://www.rfc-editor.org/info/rfc4649>.
+
+
+
+
+
+
+Krishnan, et al. Informational [Page 16]
+
+RFC 7824 DHCPv6 Privacy Considerations May 2016
+
+
+ [RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for
+ IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN)
+ Option", RFC 4704, DOI 10.17487/RFC4704, October 2006,
+ <http://www.rfc-editor.org/info/rfc4704>.
+
+ [RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol
+ (DHCPv4 and DHCPv6) Option for Civic Addresses
+ Configuration Information", RFC 4776,
+ DOI 10.17487/RFC4776, November 2006,
+ <http://www.rfc-editor.org/info/rfc4776>.
+
+ [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
+ Extensions for Stateless Address Autoconfiguration in
+ IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
+ <http://www.rfc-editor.org/info/rfc4941>.
+
+ [RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng,
+ "DHCPv6 Leasequery", RFC 5007, DOI 10.17487/RFC5007,
+ September 2007, <http://www.rfc-editor.org/info/rfc5007>.
+
+ [RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460,
+ DOI 10.17487/RFC5460, February 2009,
+ <http://www.rfc-editor.org/info/rfc5460>.
+
+ [RFC5970] Huth, T., Freimann, J., Zimmer, V., and D. Thaler, "DHCPv6
+ Options for Network Boot", RFC 5970, DOI 10.17487/RFC5970,
+ September 2010, <http://www.rfc-editor.org/info/rfc5970>.
+
+ [RFC6225] Polk, J., Linsner, M., Thomson, M., and B. Aboba, Ed.,
+ "Dynamic Host Configuration Protocol Options for
+ Coordinate-Based Location Configuration Information",
+ RFC 6225, DOI 10.17487/RFC6225, July 2011,
+ <http://www.rfc-editor.org/info/rfc6225>.
+
+ [RFC6355] Narten, T. and J. Johnson, "Definition of the UUID-Based
+ DHCPv6 Unique Identifier (DUID-UUID)", RFC 6355,
+ DOI 10.17487/RFC6355, August 2011,
+ <http://www.rfc-editor.org/info/rfc6355>.
+
+ [RFC6422] Lemon, T. and Q. Wu, "Relay-Supplied DHCP Options",
+ RFC 6422, DOI 10.17487/RFC6422, December 2011,
+ <http://www.rfc-editor.org/info/rfc6422>.
+
+ [RFC6939] Halwasia, G., Bhandari, S., and W. Dec, "Client Link-Layer
+ Address Option in DHCPv6", RFC 6939, DOI 10.17487/RFC6939,
+ May 2013, <http://www.rfc-editor.org/info/rfc6939>.
+
+
+
+
+
+Krishnan, et al. Informational [Page 17]
+
+RFC 7824 DHCPv6 Privacy Considerations May 2016
+
+
+ [RFC7653] Raghuvanshi, D., Kinnear, K., and D. Kukrety, "DHCPv6
+ Active Leasequery", RFC 7653, DOI 10.17487/RFC7653,
+ October 2015, <http://www.rfc-editor.org/info/rfc7653>.
+
+ [RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity
+ Profile for DHCP Clients", RFC 7844, DOI 10.17487/RFC7844,
+ May 2016, <http://www.rfc-editor.org/info/rfc7844>.
+
+Acknowledgements
+
+ The authors would like to thank Stephen Farrell, Ted Lemon, Ines
+ Robles, Russ White, Christian Schaefer, Jinmei Tatuya, Bernie Volz,
+ Marcin Siodelski, Christian Huitema, Brian Haberman, Robert Sparks,
+ Peter Yee, Ben Campbell, and other members of DHC WG for their
+ valuable comments.
+
+Authors' Addresses
+
+ Suresh Krishnan
+ Ericsson
+ 8400 Decarie Blvd.
+ Town of Mount Royal, QC
+ Canada
+
+ Phone: +1 514 345 7900 x42871
+ Email: suresh.krishnan@ericsson.com
+
+
+ Tomek Mrugalski
+ Internet Systems Consortium, Inc.
+ 950 Charter Street
+ Redwood City, CA 94063
+ United States
+
+ Email: tomasz.mrugalski@gmail.com
+
+
+ Sheng Jiang
+ Huawei Technologies Co., Ltd.
+ Q14, Huawei Campus, No.156 BeiQing Road
+ Hai-Dian District, Beijing 100095
+ China
+
+ Email: jiangsheng@huawei.com
+
+
+
+
+
+
+
+Krishnan, et al. Informational [Page 18]
+