draft-ietf-dhc-dhcpv6-privacy-00.txt   draft-ietf-dhc-dhcpv6-privacy-01.txt 
dhc S. Krishnan dhc S. Krishnan
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Informational T. Mrugalski Intended status: Informational T. Mrugalski
Expires: August 13, 2015 ISC Expires: February 27, 2016 ISC
S. Jiang S. Jiang
Huawei Technologies Co., Ltd Huawei Technologies Co., Ltd
February 9, 2015 August 26, 2015
Privacy considerations for DHCPv6 Privacy considerations for DHCPv6
draft-ietf-dhc-dhcpv6-privacy-00 draft-ietf-dhc-dhcpv6-privacy-01
Abstract Abstract
DHCPv6 is a protocol that is used to provide addressing and DHCPv6 is a protocol that is used to provide addressing and
configuration information to IPv6 hosts. This document discusses the configuration information to IPv6 hosts. This document described the
various identifiers used by DHCPv6 and the potential privacy issues. privacy issues associated with the use of DHCPv6 by the Internet
users. It is intended to be an analysis of the present situation and
doe not propose any solutions.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 13, 2015. This Internet-Draft will expire on February 27, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Identifiers in DHCPv6 . . . . . . . . . . . . . . . . . . . . 3 3. Identifiers in DHCPv6 . . . . . . . . . . . . . . . . . . . . 4
3.1. DUID . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. DUID . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Client ID Option . . . . . . . . . . . . . . . . . . . . 4 3.2. Client ID Option . . . . . . . . . . . . . . . . . . . . 4
3.3. IA_NA, IA_TA, IA_PD, IA Address and IA Prefix Options . . 4 3.3. IA_NA, IA_TA, IA_PD, IA Address and IA Prefix Options . . 4
3.4. Interface ID . . . . . . . . . . . . . . . . . . . . . . 5 3.4. Client FQDN Option . . . . . . . . . . . . . . . . . . . 5
3.5. Subscriber ID . . . . . . . . . . . . . . . . . . . . . . 5 3.5. Client Link-layer Address Option . . . . . . . . . . . . 5
3.6. Remote ID . . . . . . . . . . . . . . . . . . . . . . . . 5 3.6. Option Request Option . . . . . . . . . . . . . . . . . . 6
3.7. Client FQDN Option . . . . . . . . . . . . . . . . . . . 6 3.7. Vendor Class and Vendor-specific Information Options . . 6
3.8. Client Link-layer Address Option . . . . . . . . . . . . 6 3.8. Civic Location Option . . . . . . . . . . . . . . . . . . 6
3.9. Option Request Option . . . . . . . . . . . . . . . . . . 6 3.9. Coordinate-Based Location Option . . . . . . . . . . . . 6
3.10. Vendor Class Option . . . . . . . . . . . . . . . . . . . 6 3.10. Client System Architecture Type Option . . . . . . . . . 7
3.11. Civic Location Option . . . . . . . . . . . . . . . . . . 7 3.11. Relay Agent Options . . . . . . . . . . . . . . . . . . . 7
3.12. Coordinate-Based Location Option . . . . . . . . . . . . 7 3.11.1. Subscriber ID . . . . . . . . . . . . . . . . . . . 7
3.13. Client System Architecture Type Option . . . . . . . . . 7 3.11.2. Interface ID . . . . . . . . . . . . . . . . . . . . 7
4. Existing Mechanisms That Affect Privacy . . . . . . . . . . . 7 3.11.3. Remote ID . . . . . . . . . . . . . . . . . . . . . 8
4.1. Temporary addresses . . . . . . . . . . . . . . . . . . . 7 3.11.4. Relay-ID Option . . . . . . . . . . . . . . . . . . 8
4.2. DNS Updates . . . . . . . . . . . . . . . . . . . . . . . 8 4. Existing Mechanisms That Affect Privacy . . . . . . . . . . . 8
4.3. Allocation strategies . . . . . . . . . . . . . . . . . . 8 4.1. Temporary addresses . . . . . . . . . . . . . . . . . . . 8
5. Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2. DNS Updates . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Device type discovery (fingerprinting) . . . . . . . . . 9 4.3. Allocation strategies . . . . . . . . . . . . . . . . . . 9
5.2. Operating system discovery (fingerprinting) . . . . . . . 10 5. Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.3. Finding location information . . . . . . . . . . . . . . 10 5.1. Device type discovery (fingerprinting) . . . . . . . . . 10
5.4. Finding previously visited networks . . . . . . . . . . . 10 5.2. Operating system discovery (fingerprinting) . . . . . . . 11
5.5. Finding a stable identity . . . . . . . . . . . . . . . . 10 5.3. Finding location information . . . . . . . . . . . . . . 11
5.6. Pervasive monitoring . . . . . . . . . . . . . . . . . . 10 5.4. Finding previously visited networks . . . . . . . . . . . 11
5.7. Finding client's IP address or hostname . . . . . . . . . 10 5.5. Finding a stable identity . . . . . . . . . . . . . . . . 11
5.8. Correlation of activities over time . . . . . . . . . . . 11 5.6. Pervasive monitoring . . . . . . . . . . . . . . . . . . 11
5.9. Location tracking . . . . . . . . . . . . . . . . . . . . 11 5.7. Finding client's IP address or hostname . . . . . . . . . 12
5.10. Leasequery & bulk leasequery . . . . . . . . . . . . . . 11 5.8. Correlation of activities over time . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 5.9. Location tracking . . . . . . . . . . . . . . . . . . . . 12
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12 5.10. Leasequery & bulk leasequery . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . 12 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . 12 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 10.1. Normative References . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
DHCPv6 [RFC3315] is a protocol that is used to provide addressing and DHCPv6 [RFC3315] is a protocol that is used to provide addressing and
configuration information to IPv6 hosts. The DHCPv6 protocol uses configuration information to IPv6 hosts. The DHCPv6 protocol uses
several identifiers that could become a source for gleaning several identifiers that could become a source for gleaning
additional information about the IPv6 host. This information may information about the IPv6 host. This information may include device
include device type, operating system information, location(s) that type, operating system information, location(s) that the device may
the device may have previously visited, etc. This document discusses have previously visited, etc. This document discusses the various
the various identifiers used by DHCPv6 and the potential privacy identifiers used by DHCPv6 and the potential privacy issues
issues [RFC6973]. [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 Future works may propose protocol changes to fix the privacy issues
that have been analyzed in this document. It is out of scope for that have been analyzed in this document. Protocol changes are out
this document. of scope for this document.
Editor notes: for now, the document is mainly considering the privacy The primary focus of this document is around privacy considerations
of DHCPv6 client. The privacy of DHCPv6 server and relay agent are for clients to support client mobility and connection to random
considered less important because they are open for public services. networks. The privacy or DHCP servers and relay agents are
However, this may be a subject to change if further study shows considered less important as they are typically open for public
opposite result. services. And, it is generally assumed that relay agent to server
communication 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
DHCP servers and relay agents.
2. Terminology 2. Terminology
This section clarifies the terminology used throughout this document.
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 MAC address,
client-id that does not change or a hostname. Stable identifier may
or may not be globally unique.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. When these document are to be interpreted as described in [RFC2119]. When these
words are not in ALL CAPS (such as "should" or "Should"), they have words are not in ALL CAPS (such as "should" or "Should"), they have
their usual English meanings, and are not to be interpreted as their usual English meanings, and are not to be interpreted as
[RFC2119] key words. [RFC2119] key words.
Naming convention from [RFC3315] and related is used throughout this
document. In addition the following terminology is used:
Stable identifier - Any property disclosed by a DHCP client that
does not change over time or changes very infrequently and is
unique for said client in a given context. Examples may
include MAC address, client-id or 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 while other may
generate it on the fly and use a different one after each
boot. Stable identifier may or may not be globally unique.
3. Identifiers in DHCPv6 3. Identifiers in DHCPv6
There are several identifiers used in DHCPv6. This section provides There are several identifiers used in DHCPv6. This section provides
an introduction to the various options that will be used further in an introduction to the various options that will be used further in
the document. the document.
3.1. DUID 3.1. DUID
Each DHCPv6 client and server has a DHCPv6 Unique Identifier (DUID) Each DHCPv6 client and server has a DHCPv6 Unique Identifier (DUID)
[RFC3315]. The DUID is designed to be unique across all DHCPv6 [RFC3315]. The DUID is designed to be unique across all DHCPv6
clients and servers, and to remain stable after it has been initially clients and servers, and to remain stable after it has been initially
generated. The DUID can be of different forms. Commonly used forms 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 are based on the link-layer address of one of the device's network
interfaces (with or without a timestamp), on the Universally Unique interfaces (with or without a timestamp), on the Universally Unique
IDentifier (UUID) [RFC6355]. The default type, recommended by IDentifier (UUID) [RFC6355]. The default type, defined in
[RFC3315], is DUID-LLT that is based on link-layer address, which is Section 9.2 of [RFC3315] is DUID-LLT that is based on link-layer
commonly implemented in most popular clients. address. It is commonly implemented in most popular clients.
It is important to understand DUID lifecycle. Clients and servers It is important to understand DUID lifecycle. Clients and servers
are expected to generate their DUID once (during first operation) and are expected to generate their DUID once (during first operation) and
store it in a non-volatile storage or use the same deterministic store it in a non-volatile storage or use the same deterministic
algorithm to generate the same DUID value again. This means that algorithm to generate the same DUID value again. This means that
most implementations will use the available link-layer address during most implementations will use the available link-layer address during
its first boot. Even if the administrator enables privacy extensions its first boot. Even if the administrator enables privacy extensions
(see [RFC4941]) and its equivalent for link-layer address (see [RFC4941]) and its equivalent for link-layer address
randomization, it is likely that those privacy mechanisms were randomization, it is likely that those privacy mechanisms were
disabled during the first device boot. Hence the original, disabled during the first device boot. Hence the original,
skipping to change at page 5, line 16 skipping to change at page 5, line 22
each IA_NA, IA_TA and IA_PD options have an IAID field that is unique each IA_NA, IA_TA and IA_PD options have an IAID field that is unique
for each client/option type pair. It is up to the client to pick for each client/option type pair. It is up to the client to pick
unique IAID values. At least one popular implementation uses last unique IAID values. At least one popular implementation uses last
four octets of the link-layer address. In most cases, that means four octets of the link-layer address. In most cases, that means
that merely two bytes are missing for a full link-layer address that merely two bytes are missing for a full link-layer address
reconstruction. However, the first three octets in a typical link- reconstruction. However, the first three octets in a typical link-
layer address are vendor identifier. That can be determined with layer address are vendor identifier. That can be determined with
high level of certainty using other means, thus allowing full link- high level of certainty using other means, thus allowing full link-
layer address discovery. layer address discovery.
3.4. Interface ID 3.4. Client FQDN Option
A DHCPv6 relay includes the Interface ID [RFC3315] option to identify
the interface on which it received the client message that is being
relayed.
Although in principle Interface ID can be arbitrarily long with
completely random values, it is often a text string that includes the
relay agent name followed by interface name. This can be used for
fingerprinting the relay or determining client's point of attachment.
3.5. Subscriber ID
A DHCPv6 relay includes 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.6. Remote ID
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 the 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.7. Client FQDN Option
The Client Fully Qualified Domain Name (FQDN) option [RFC4704] is The Client Fully Qualified Domain Name (FQDN) option [RFC4704] is
used by DHCPv6 clients and servers to exchange information about the used by DHCPv6 clients and servers to exchange information about the
client's fully qualified domain name and about who has the client's fully qualified domain name and about who has the
responsibility for updating the DNS with the associated AAAA and PTR responsibility for updating the DNS with the associated AAAA and PTR
RRs. RRs.
A client can use this option to convey all or part of its domain name 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 to a DHCPv6 server for the IPv6-address-to-FQDN mapping. In most
case a client sends its hostname as a hint for the server. The case a client sends its hostname as a hint for the server. The
DHCPv6 server MAY be configured to modify the supplied name or to DHCPv6 server MAY be configured to modify the supplied name or to
substitute a different name. The server should send its notion of substitute a different name. The server should send its notion of
the complete FQDN for the client in the Domain Name field. the complete FQDN for the client in the Domain Name field.
3.8. Client Link-layer Address Option 3.5. Client Link-layer Address Option
The Client link-layer address option [RFC6939] is used by first-hop The Client link-layer address option [RFC6939] is used by first-hop
DHCPv6 relays to provide the client's link-layer address towards the DHCPv6 relays to provide the client's link-layer address towards the
server. server.
DHCPv6 relay agents that receive messages originating from clients DHCPv6 relay agents that receive messages originating from clients
may include the link-layer source address of the received DHCPv6 may include the link-layer source address of the received DHCPv6
message in the Client Link-Layer Address option, in relayed DHCPv6 message in the Client Link-Layer Address option, in relayed DHCPv6
Relay-Forward messages. Relay-Forward messages.
3.9. Option Request Option 3.6. Option Request Option
DHCPv6 clients include an Option Request option [RFC3315] in DHCPv6 DHCPv6 clients include an Option Request option [RFC3315] in DHCPv6
messages to inform the server about options the client wants the messages to inform the server about options the client wants the
server to send to the client. server to send to the client.
The content of an Option Request option are the option codes for an The content of an Option Request option are the option codes for an
option requested by the client. The client may additionally include option requested by the client. The client may additionally include
instances of those options that are identified in the Option Request instances of those options that are identified in the Option Request
option, with data values as hints to the server about parameter option, with data values as hints to the server about parameter
values the client would like to have returned. values the client would like to have returned.
3.10. Vendor Class Option 3.7. Vendor Class and Vendor-specific Information Options
This Vendor Class option [RFC3315] is used by a DHCPv6 client to The Vendor Class option, defined in Section 22.16 of [RFC3315] is
identify the vendor that manufactured the hardware on which the used by a DHCPv6 client to identify the vendor that manufactured the
client is running. 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.
The information contained in the data area of this option is The information contained in the data area of this option is
contained in one or more opaque fields that identify details of the contained in one or more opaque fields that identify details of the
hardware configuration, for example, the version of the operating hardware configuration, for example, the version of the operating
system the client is running or the amount of memory installed on the system the client is running or the amount of memory installed on the
client. client.
3.11. Civic Location Option 3.8. Civic Location Option
DHCPv6 servers use the Civic Location option [RFC4776] to delivery of DHCPv6 servers use the Civic Location option [RFC4776] to delivery of
location information (the civic and postal addresses) from the DHCPv6 location information (the civic and postal addresses) from the DHCPv6
server to the DHCPv6 clients. It may refer to three locations: the server to the DHCPv6 clients. It may refer to three locations: the
location of the DHCPv6 server, the location of the network element location of the DHCPv6 server, the location of the network element
believed to be closest to the client, or the location of the client, believed to be closest to the client, or the location of the client,
identified by the "what" element within the option. identified by the "what" element within the option.
3.12. Coordinate-Based Location Option 3.9. Coordinate-Based Location Option
The GeoLoc options [RFC6225] is used by DHCPv6 server to provide the The GeoLoc options [RFC6225] is used by DHCPv6 server to provide the
coordinate- based geographic location information to the DHCPv6 coordinate- based geographic location information to the DHCPv6
clients. It enable a DHCPv6 client to obtain its location. clients. It enable a DHCPv6 client to obtain its location.
After the relevant DHCPv6 exchanges have taken place, the location After the relevant DHCPv6 exchanges have taken place, the location
information is stored on the end device rather than somewhere else, information is stored on the end device rather than somewhere else,
where retrieving it might be difficult in practice. where retrieving it might be difficult in practice.
3.13. Client System Architecture Type Option 3.10. Client System Architecture Type Option
The Client System Architecture Type option [RFC5970] is used by The Client System Architecture Type option [RFC5970] is used by
DHCPv6 client to send a list of supported architecture types to the DHCPv6 client to send a list of supported architecture types to the
DHCPv6 server. It is used to provide configuration information for a DHCPv6 server. It is used to provide configuration information for a
node that must be booted using the network rather than from local node that must be booted using the network rather than from local
storage. storage.
3.11. Relay Agent Options
A DHCPv6 relay agent may include a number of options. Those option
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 is 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
operator's intfrastructure (either willing or coerced cooperation or
infrastructure being compromised) usually apply.
The following subsections describe various options inserted by the
relay agents.
3.11.1. Subscriber ID
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.11.2. Interface ID
A DHCPv6 relay includes the Interface ID [RFC3315] option to identify
the interface on which it received the client message that is being
relayed.
Although in principle Interface ID can be arbitrarily long with
completely random values, it is often a text string that includes the
relay agent name followed by interface name. This can be used for
fingerprinting the relay or determining client's point of attachment.
3.11.3. Remote ID
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 the 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.11.4. Relay-ID Option
Relay agent may include Relay-ID [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
client's location within the network.
4. Existing Mechanisms That Affect Privacy 4. Existing Mechanisms That Affect Privacy
This section describes available DHCPv6 mechanisms that one can use This section describes available DHCPv6 mechanisms that one can use
to protect or enhance one's privacy. to protect or enhance one's privacy.
4.1. Temporary addresses 4.1. Temporary addresses
[RFC3315] defines a mechanism for a client to request temporary [RFC3315] defines a mechanism for a client to request temporary
addresses. The idea behind temporary addresses is that a client can addresses. The idea behind temporary addresses is that a client can
request a temporary address for a specific purpose, use it, and then request a temporary address for a specific purpose, use it, and then
skipping to change at page 8, line 43 skipping to change at page 9, line 42
implications. implications.
Iterative allocation - a server may choose to allocate addresses one Iterative allocation - a server may choose to allocate addresses one
by one. That strategy has the benefit of being very fast, thus can by one. That strategy has the benefit of being very fast, thus can
be favored in deployments that prefer performance. However, it makes be favored in deployments that prefer performance. However, it makes
the resources very predictable. Also, since the resources allocated the resources very predictable. Also, since the resources allocated
tend to be clustered at the beginning of available pool, it makes tend to be clustered at the beginning of available pool, it makes
scanning attacks much easier. scanning attacks much easier.
Identifier-based allocation - a server may choose to allocate an Identifier-based allocation - a server may choose to allocate an
address that is based on one of available identifiers, e.g. IID or address that is based on one of available identifiers, e.g. IID or
MAC address. This has a property of being convenient for converting MAC address. This has a property of being convenient for converting
IP address to/from other identifiers, especially if the identifier is IP address to/from other identifiers, especially if the identifier is
or contains MAC address. It is also convenient, as returning client or contains MAC address. It is also convenient, as returning client
is very likely to get the same address, even if the server does not is very likely to get the same address, even if the server does not
store previous client's address. Those properties are convenient for store previous client's address. Those properties are convenient for
system administrators, so DHCPv6 server implementors are sometimes system administrators, so DHCPv6 server implementors are sometimes
requested to implement it. There is at least one implementation that requested to implement it. There is at least one implementation that
supports it. On the other hand, the downside of such allocation is supports it. On the other hand, the downside of such allocation is
that the client now discloses its identifier in its IPv6 address to that the client now discloses its identifier in its IPv6 address to
all services it connects to. That means that correlation of all services it connects to. That means that correlation of
skipping to change at page 9, line 43 skipping to change at page 10, line 42
way, e.g. client's address can be randomized, but it still can leak way, e.g. client's address can be randomized, but it still can leak
its MAC address in client-id option. its MAC address in client-id option.
Other allocation strategies may be implemented. Other allocation strategies may be implemented.
5. Attacks 5. Attacks
5.1. Device type discovery (fingerprinting) 5.1. Device type discovery (fingerprinting)
The type of device used by the client can be guessed by the attacker The type of device used by the client can be guessed by the attacker
using the Vendor Class option, the Client Link-layer Address option, using the Vendor Class option, Vendor-specific Information option,
and by parsing the Client ID option. All of those options may the Client Link-layer Address option, and by parsing the Client ID
contain OUI (Organizationally Unique Identifier) that represents the option. All of those options may contain OUI (Organizationally
device's vendor. That knowledge can be used for device-specific Unique Identifier) that represents the device's vendor. That
vulnerability exploitation attacks. See Section 3.4 of knowledge can be used for device-specific vulnerability exploitation
attacks. See Section 3.4 of
[I-D.ietf-6man-ipv6-address-generation-privacy] for a discussion [I-D.ietf-6man-ipv6-address-generation-privacy] for a discussion
about this type of attack. about this type of attack.
5.2. Operating system discovery (fingerprinting) 5.2. Operating system discovery (fingerprinting)
The operating system running on a client can be guessed using the The operating system running on a client can be guessed using the
Vendor Class option, the Client System Architecture Type option, or Vendor Class option, the Vendor-specific Information option, the
by using fingerprinting techniques on the combination of options Client System Architecture Type option, or by using fingerprinting
requested using the Option Request option. See Section 3.4 of techniques on the combination of options requested using the Option
Request option. See Section 3.4 of
[I-D.ietf-6man-ipv6-address-generation-privacy] for a discussion [I-D.ietf-6man-ipv6-address-generation-privacy] for a discussion
about this type of attack. about this type of attack.
5.3. Finding location information 5.3. Finding location information
The location information can be obtained by the attacker by many The location information can be obtained by the attacker by many
means. The most direct way to obtain this information is by looking means. The most direct way to obtain this information is by looking
into a server initiated message that contains the Civic Location or into a message originating from the server server that contains the
GeoLoc option. It can also be indirectly inferred using the Remote Civic Location or GeoLoc option. It can also be indirectly inferred
ID Option (e.g. using a telephone number), the Interface ID option using the Remote ID Option, the Interface ID option (e.g. if an
(e.g. if an access circuit on an Access Node corresponds to a civic access circuit on an Access Node corresponds to a civic location), or
location), or the Subscriber ID Option (if the attacker has access to the Subscriber ID Option (if the attacker has access to subscriber
subscriber info). info).
5.4. Finding previously visited networks 5.4. Finding previously visited networks
When DHCPv6 clients connect to a network, they attempt to obtain the When DHCPv6 clients connect to a network, they attempt to obtain the
same address they had used before they attached to the network. They same address they had used before they attached to the network. They
do this by putting the previously assigned address(es) in the IA do this by putting the previously assigned address(es) in the IA
Address Option(s) inside the IA_NA, IA_TA. By observing these Address Option(s) inside the IA_NA, IA_TA. By observing these
addresses, an attacker can identify the network the client had addresses, an attacker can identify the network the client had
previously visited. previously visited.
skipping to change at page 10, line 46 skipping to change at page 11, line 47
An attacker might use a stable identity gleaned from DHCPv6 messages An attacker might use a stable identity gleaned from DHCPv6 messages
to correlate activities of a given client on unrelated networks. The to correlate activities of a given client on unrelated networks. The
Client FQDN option, the Subscriber ID Option and the Client ID Client FQDN option, the Subscriber ID Option and the Client ID
options can serve as long lived identifiers of DHCPv6 clients. The options can serve as long lived identifiers of DHCPv6 clients. The
Client FQDN option can also provide an identity that can easily be Client FQDN option can also provide an identity that can easily be
correlated with web server activity logs. correlated with web server activity logs.
5.6. Pervasive monitoring 5.6. Pervasive monitoring
This is an enhancement, or a combination of most aforementioned This is an enhancement, or a combination of most aforementioned
mechanisms. Operator, who controls non-trivial number of access mechanisms. Operator (or anyone who has access to its data), who
points or network segments, may use obtained information about a controls non-trivial number of access points or network segments, may
single client and observer client's habits. use obtained information about a single client and observer client's
habits.
5.7. Finding client's IP address or hostname 5.7. Finding client's IP address or hostname
Many DHCPv6 deployments use DNS Updates [RFC4704] that put client's Many DHCPv6 deployments use DNS Updates [RFC4704] that put client's
information (current IP address, client's hostname). Client ID is information (current IP address, client's hostname) into DNS, where
also disclosed, able it in not easily accessible form (SHA-256 digest it is easily accessible by anyone interested. Client ID is also
of the client-id). Although SHA-256 is irreversible, so DHCPv6 disclosed, albeit in not easily accessible form (SHA-256 digest of
client ID can't be converted back to client-id. However, SHA-256 the client-id). As SHA-256 is considered irreversible, DHCID can't
digest can be used as a unique identifier that is accessible by any be converted back to client-id. However, SHA-256 digest can be used
host. as an unique identifier that is accessible by any host.
5.8. Correlation of activities over time 5.8. Correlation of activities over time
As with other identifiers, an IPv6 address can be used to correlate 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 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 address. If that address was generated from some other, stable
identifier and that generation scheme can be deducted by an attacker, identifier and that generation scheme can be deducted by an attacker,
the duration of correlation attack extends to that identifier. In the duration of correlation attack extends to that identifier. In
many cases, its lifetime is equal to the lifetime of the device many cases, its lifetime is equal to the lifetime of the device
itself. See Section 3.1 of itself. See Section 3.1 of
skipping to change at page 11, line 35 skipping to change at page 12, line 38
If a stable identifier is used for assigning an address and such 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- mapping is discovered by an attacker (e.g. a server that uses IEEE-
identifier-based IID to generate IPv6 address), all scenarios identifier-based IID to generate IPv6 address), all scenarios
discussed in Section 3.2 of discussed in Section 3.2 of
[I-D.ietf-6man-ipv6-address-generation-privacy] apply. In particular [I-D.ietf-6man-ipv6-address-generation-privacy] apply. In particular
both passive (a service that the client connects to can log client's both passive (a service that the client connects to can log client's
address and draw conclusions regarding its location and movement address and draw conclusions regarding its location and movement
patterns based on prefix it is connecting from) and active (attacker patterns based on prefix it is connecting from) and active (attacker
can send ICMPv6 echo requests or other probe packets to networks of can send ICMPv6 echo requests or other probe packets to networks of
suspected client locations). suspected client locations) can be used. To give 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
current location and his habits.
5.10. Leasequery & bulk leasequery 5.10. Leasequery & bulk leasequery
Attackers may pretend as an access concentrator, either DHCPv6 relay Attackers may pretend as an access concentrator, either DHCPv6 relay
agent or DHCPv6 client, to obtain location information directly from agent or DHCPv6 client, to obtain location information directly from
the DHCP server(s) using the DHCPv6 Leasequery [RFC5007] mechanism. the DHCP server(s) using the DHCPv6 Leasequery [RFC5007] mechanism.
Location information is information needed by the access concentrator Location information is information needed by the access concentrator
to forward traffic to a broadband-accessible host. This information to forward traffic to a broadband-accessible host. This information
includes knowledge of the host hardware address, the port or virtual includes knowledge of the host hardware address, the port or virtual
circuit that leads to the host, and/or the hardware address of the circuit that leads to the host, and/or the hardware address of the
intervening subscriber modem. intervening subscriber modem.
Furthermore, the attackers may use DHCPv6 bulk leasequery [RFC5460] Furthermore, the attackers may use DHCPv6 bulk leasequery [RFC5460]
mechanism to obtain bulk information about DHCPv6 bindings, even mechanism to obtain bulk information about DHCPv6 bindings, even
without knowing the target bindings. without knowing the target bindings.
Additionally, active leasequery
[I-D.ietf-dhc-dhcpv6-active-leasequery] is a mechanism for
subscribing to DHCPv6 lease update changes in near real-time. The
intent of this mechanism is to update operator's database, but if
misused, an attacker could defeat server's authentication mechanisms
and subscribe to all updates. He then could continue receiving
updates, without any need for local presence.
6. Security Considerations 6. Security Considerations
TBD In current practice, the client privacy and the 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
for the server and the network.
7. Privacy Considerations 7. Privacy Considerations
This document at its entirety discusses privacy considerations in This document at its entirety discusses privacy considerations in
DHCPv6. As such, no separate section about this is needed. DHCPv6. As such, no dedicated section about this is needed.
8. IANA Considerations 8. IANA Considerations
This draft does not request any IANA action. This draft does not request any IANA action.
9. Acknowledgements 9. Acknowledgements
The authors would like to thanks the valuable comments made by The authors would like to thanks the valuable comments made by
Stephen Farrell, Ted Lemon, Ines Robles, Russ White, Christian Stephen Farrell, Ted Lemon, Ines Robles, Russ White, Christian
Schaefer and other members of DHC WG. Schaefer and other members of DHC WG.
This document was produced using the xml2rfc tool [RFC2629]. This document was produced using the xml2rfc tool [RFC2629].
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
and M. Carney, "Dynamic Host Configuration Protocol for C., and M. Carney, "Dynamic Host Configuration Protocol
IPv6 (DHCPv6)", RFC 3315, July 2003. 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>.
10.2. Informative References 10.2. Informative References
[I-D.ietf-6man-ipv6-address-generation-privacy] [I-D.ietf-6man-ipv6-address-generation-privacy]
Cooper, A., Gont, F., and D. Thaler, "Privacy Cooper, A., Gont, F., and D. Thaler, "Privacy
Considerations for IPv6 Address Generation Mechanisms", Considerations for IPv6 Address Generation Mechanisms",
draft-ietf-6man-ipv6-address-generation-privacy-03 (work draft-ietf-6man-ipv6-address-generation-privacy-07 (work
in progress), January 2015. in progress), June 2015.
[I-D.ietf-dhc-dhcpv6-active-leasequery]
Dushyant, D., Kinnear, K., and D. Kukrety, "DHCPv6 Active
Leasequery", draft-ietf-dhc-dhcpv6-active-leasequery-04
(work in progress), July 2015.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999. DOI 10.17487/RFC2629, June 1999,
<http://www.rfc-editor.org/info/rfc2629>.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633, Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003. DOI 10.17487/RFC3633, December 2003,
<http://www.rfc-editor.org/info/rfc3633>.
[RFC4580] Volz, B., "Dynamic Host Configuration Protocol for IPv6 [RFC4580] Volz, B., "Dynamic Host Configuration Protocol for IPv6
(DHCPv6) Relay Agent Subscriber-ID Option", RFC 4580, June (DHCPv6) Relay Agent Subscriber-ID Option", RFC 4580,
2006. DOI 10.17487/RFC4580, June 2006,
<http://www.rfc-editor.org/info/rfc4580>.
[RFC4649] Volz, B., "Dynamic Host Configuration Protocol for IPv6 [RFC4649] Volz, B., "Dynamic Host Configuration Protocol for IPv6
(DHCPv6) Relay Agent Remote-ID Option", RFC 4649, August (DHCPv6) Relay Agent Remote-ID Option", RFC 4649,
2006. DOI 10.17487/RFC4649, August 2006,
<http://www.rfc-editor.org/info/rfc4649>.
[RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for [RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for
IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN)
Option", RFC 4704, October 2006. Option", RFC 4704, DOI 10.17487/RFC4704, October 2006,
<http://www.rfc-editor.org/info/rfc4704>.
[RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol [RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol
(DHCPv4 and DHCPv6) Option for Civic Addresses (DHCPv4 and DHCPv6) Option for Civic Addresses
Configuration Information", RFC 4776, November 2006. 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 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, September 2007. 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, [RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng,
"DHCPv6 Leasequery", RFC 5007, September 2007. "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, February [RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460,
2009. DOI 10.17487/RFC5460, February 2009,
<http://www.rfc-editor.org/info/rfc5460>.
[RFC5970] Huth, T., Freimann, J., Zimmer, V., and D. Thaler, "DHCPv6 [RFC5970] Huth, T., Freimann, J., Zimmer, V., and D. Thaler, "DHCPv6
Options for Network Boot", RFC 5970, September 2010. 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, "Dynamic [RFC6225] Polk, J., Linsner, M., Thomson, M., and B. Aboba, Ed.,
Host Configuration Protocol Options for Coordinate-Based "Dynamic Host Configuration Protocol Options for
Location Configuration Information", RFC 6225, July 2011. 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 [RFC6355] Narten, T. and J. Johnson, "Definition of the UUID-Based
DHCPv6 Unique Identifier (DUID-UUID)", RFC 6355, August DHCPv6 Unique Identifier (DUID-UUID)", RFC 6355,
2011. DOI 10.17487/RFC6355, August 2011,
<http://www.rfc-editor.org/info/rfc6355>.
[RFC6939] Halwasia, G., Bhandari, S., and W. Dec, "Client Link-Layer [RFC6422] Lemon, T. and Q. Wu, "Relay-Supplied DHCP Options",
Address Option in DHCPv6", RFC 6939, May 2013. RFC 6422, DOI 10.17487/RFC6422, December 2011,
<http://www.rfc-editor.org/info/rfc6422>.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., [RFC6939] Halwasia, G., Bhandari, S., and W. Dec, "Client Link-Layer
Morris, J., Hansen, M., and R. Smith, "Privacy Address Option in DHCPv6", RFC 6939, DOI 10.17487/RFC6939,
Considerations for Internet Protocols", RFC 6973, July May 2013, <http://www.rfc-editor.org/info/rfc6939>.
2013.
Authors' Addresses Authors' Addresses
Suresh Krishnan Suresh Krishnan
Ericsson Ericsson
8400 Decarie Blvd. 8400 Decarie Blvd.
Town of Mount Royal, QC Town of Mount Royal, QC
Canada Canada
Phone: +1 514 345 7900 x42871 Phone: +1 514 345 7900 x42871
Email: suresh.krishnan@ericsson.com Email: suresh.krishnan@ericsson.com
Tomek Mrugalski Tomek Mrugalski
skipping to change at page 14, line 19 skipping to change at page 16, line 26
Phone: +1 514 345 7900 x42871 Phone: +1 514 345 7900 x42871
Email: suresh.krishnan@ericsson.com Email: suresh.krishnan@ericsson.com
Tomek Mrugalski Tomek Mrugalski
Internet Systems Consortium, Inc. Internet Systems Consortium, Inc.
950 Charter Street 950 Charter Street
Redwood City, CA 94063 Redwood City, CA 94063
USA USA
Phone: +1 650 423 1345
Email: tomasz.mrugalski@gmail.com Email: tomasz.mrugalski@gmail.com
Sheng Jiang Sheng Jiang
Huawei Technologies Co., Ltd Huawei Technologies Co., Ltd
Q14, Huawei Campus, No.156 BeiQing Road Q14, Huawei Campus, No.156 BeiQing Road
Hai-Dian District, Beijing 100095 Hai-Dian District, Beijing 100095
P.R. China P.R. China
Email: jiangsheng@huawei.com Email: jiangsheng@huawei.com
 End of changes. 52 change blocks. 
169 lines changed or deleted 272 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/