doc: Add RFC documents

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]
+