draft-ietf-dhc-anonymity-profile-02.txt | draft-ietf-dhc-anonymity-profile-03.txt | |||
---|---|---|---|---|
Network Working Group C. Huitema | Network Working Group C. Huitema | |||
Internet-Draft Microsoft | Internet-Draft Microsoft | |||
Updates: 4361 (if approved) T. Mrugalski | Intended status: Standards Track T. Mrugalski | |||
Intended status: Standards Track ISC | Expires: March 4, 2016 ISC | |||
Expires: February 21, 2016 S. Krishnan | S. Krishnan | |||
Ericsson | Ericsson | |||
August 20, 2015 | September 1, 2015 | |||
Anonymity profile for DHCP clients | Anonymity profile for DHCP clients | |||
draft-ietf-dhc-anonymity-profile-02.txt | draft-ietf-dhc-anonymity-profile-03.txt | |||
Abstract | Abstract | |||
Some DHCP options carry unique identifiers. These identifiers can | Some DHCP options carry unique identifiers. These identifiers can | |||
enable device tracking even if the device administrator takes care of | enable device tracking even if the device administrator takes care of | |||
randomizing other potential identifications like link-layer addresses | randomizing other potential identifications like link-layer addresses | |||
or IPv6 addresses. The anonymity profile is designed for clients | or IPv6 addresses. The anonymity profile is designed for clients | |||
that wish to remain anonymous to the visited network. The profile | that wish to remain anonymous to the visited network. The profile | |||
provides guidelines on the composition of DHCP or DHCPv6 requests, | provides guidelines on the composition of DHCP or DHCPv6 requests, | |||
designed to minimize disclosure of identifying information. This | designed to minimize disclosure of identifying information. This | |||
skipping to change at page 1, line 40 | skipping to change at page 1, line 40 | |||
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 February 21, 2016. | This Internet-Draft will expire on March 4, 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 | |||
skipping to change at page 2, line 16 | skipping to change at page 2, line 16 | |||
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 | |||
1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 3 | 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 3 | |||
2. Application domain . . . . . . . . . . . . . . . . . . . . . 3 | 2. Application domain . . . . . . . . . . . . . . . . . . . . . 3 | |||
2.1. MAC Address Randomization hypotheses . . . . . . . . . . 4 | 2.1. MAC address Randomization hypotheses . . . . . . . . . . 4 | |||
2.2. MAC Address Randomization and DHCP . . . . . . . . . . . 5 | 2.2. MAC address Randomization and DHCP . . . . . . . . . . . 5 | |||
2.3. Radio fingerprinting . . . . . . . . . . . . . . . . . . 5 | 2.3. Radio fingerprinting . . . . . . . . . . . . . . . . . . 5 | |||
2.4. Operating system fingerprinting . . . . . . . . . . . . . 6 | 2.4. Operating system fingerprinting . . . . . . . . . . . . . 6 | |||
2.5. No anonymity profile identification . . . . . . . . . . . 6 | 2.5. No anonymity profile identification . . . . . . . . . . . 6 | |||
2.6. Using the anonymity profiles . . . . . . . . . . . . . . 7 | 2.6. Using the anonymity profiles . . . . . . . . . . . . . . 7 | |||
2.7. What about privacy for DHCP servers . . . . . . . . . . . 7 | 2.7. What about privacy for DHCP servers . . . . . . . . . . . 8 | |||
3. Anonymity profile for DHCPv4 . . . . . . . . . . . . . . . . 8 | 3. Anonymity profile for DHCPv4 . . . . . . . . . . . . . . . . 8 | |||
3.1. Client IP address field . . . . . . . . . . . . . . . . . 9 | 3.1. Option encoding and avoiding fingerprinting . . . . . . . 9 | |||
3.2. Requested IP address option . . . . . . . . . . . . . . . 9 | 3.2. Client IP address field . . . . . . . . . . . . . . . . . 9 | |||
3.3. Client hardware address . . . . . . . . . . . . . . . . . 10 | 3.3. Requested IP address option . . . . . . . . . . . . . . . 10 | |||
3.4. Client Identifier Option . . . . . . . . . . . . . . . . 10 | 3.4. Client hardware address . . . . . . . . . . . . . . . . . 10 | |||
3.5. Host Name Option . . . . . . . . . . . . . . . . . . . . 11 | 3.5. Client Identifier Option . . . . . . . . . . . . . . . . 11 | |||
3.6. Client FQDN Option . . . . . . . . . . . . . . . . . . . 12 | 3.6. Parameter Request List . . . . . . . . . . . . . . . . . 11 | |||
3.7. UUID/GUID-based Client Identifier Option . . . . . . . . 12 | 3.7. Host Name Option . . . . . . . . . . . . . . . . . . . . 12 | |||
3.8. User and Vendor Class DHCP options . . . . . . . . . . . 13 | 3.8. Client FQDN Option . . . . . . . . . . . . . . . . . . . 13 | |||
4. Anonymity profile for DHCPv6 . . . . . . . . . . . . . . . . 13 | 3.9. UUID/GUID-based Client Identifier Option . . . . . . . . 13 | |||
4.1. Do not send Confirm messages, unless really sure where . 14 | 3.10. User and Vendor Class DHCP options . . . . . . . . . . . 14 | |||
4.2. Client Identifier DHCPv6 Option . . . . . . . . . . . . . 14 | 4. Anonymity profile for DHCPv6 . . . . . . . . . . . . . . . . 14 | |||
4.2.1. Anonymous Information-Request . . . . . . . . . . . . 15 | 4.1. Option encoding and avoiding fingerprinting . . . . . . . 14 | |||
4.3. Server Identifier Option . . . . . . . . . . . . . . . . 15 | 4.2. Do not send Confirm messages, unless really sure where . 15 | |||
4.4. Address assignment options . . . . . . . . . . . . . . . 15 | 4.3. Client Identifier DHCPv6 Option . . . . . . . . . . . . . 15 | |||
4.4.1. Obtain temporary addresses . . . . . . . . . . . . . 16 | 4.3.1. Anonymous Information-Request . . . . . . . . . . . . 16 | |||
4.5. Option Request Option . . . . . . . . . . . . . . . . . . 16 | 4.4. Server Identifier Option . . . . . . . . . . . . . . . . 16 | |||
4.5.1. Previous option values . . . . . . . . . . . . . . . 17 | 4.5. Address assignment options . . . . . . . . . . . . . . . 16 | |||
4.6. Authentication Option . . . . . . . . . . . . . . . . . . 17 | 4.5.1. Obtain temporary addresses . . . . . . . . . . . . . 17 | |||
4.7. User and Vendor Class DHCPv6 options . . . . . . . . . . 17 | 4.6. Option Request Option . . . . . . . . . . . . . . . . . . 17 | |||
4.8. Client FQDN Option . . . . . . . . . . . . . . . . . . . 17 | 4.6.1. Previous option values . . . . . . . . . . . . . . . 18 | |||
5. Operational Considerations . . . . . . . . . . . . . . . . . 18 | 4.7. Authentication Option . . . . . . . . . . . . . . . . . . 18 | |||
6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 | 4.8. User and Vendor Class DHCPv6 options . . . . . . . . . . 18 | |||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 | 4.9. Client FQDN Option . . . . . . . . . . . . . . . . . . . 18 | |||
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 | 5. Operational Considerations . . . . . . . . . . . . . . . . . 19 | |||
9. Changes from previous versions . . . . . . . . . . . . . . . 18 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 | |||
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 | |||
10.1. Normative References . . . . . . . . . . . . . . . . . . 19 | 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 | |||
10.2. Informative References . . . . . . . . . . . . . . . . . 20 | 9. Changes from previous versions . . . . . . . . . . . . . . . 19 | |||
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 | ||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 | 10.1. Normative References . . . . . . . . . . . . . . . . . . 21 | |||
10.2. Informative References . . . . . . . . . . . . . . . . . 22 | ||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 | ||||
1. Introduction | 1. Introduction | |||
Reports surfaced recently of systems that would monitor the wireless | Reports surfaced recently of systems that would monitor the wireless | |||
connections of passengers at Canadian airports [CNBC]. We can assume | connections of passengers at Canadian airports [CNBC]. We can assume | |||
that these are either fragments or trial runs of a wider system that | that these are either fragments or trial runs of a wider system that | |||
would attempt to monitor Internet users as they roam through wireless | would attempt to monitor Internet users as they roam through wireless | |||
access points and other temporary network attachments. We can also | access points and other temporary network attachments. We can also | |||
assume that privacy conscious users will attempt to evade this | assume that privacy conscious users will attempt to evade this | |||
monitoring, for example by ensuring that low level identifiers such | monitoring, for example by ensuring that low level identifiers such | |||
skipping to change at page 3, line 45 | skipping to change at page 3, line 47 | |||
1.1. Requirements | 1.1. Requirements | |||
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]. | document are to be interpreted as described in [RFC2119]. | |||
2. Application domain | 2. Application domain | |||
Mobile nodes can be tracked using multiple identifiers, the most | Mobile nodes can be tracked using multiple identifiers, the most | |||
prominent being MAC addresses. For example, when devices use Wi-Fi | prominent being link-layer addresses, a.k.a. MAC addresses. For | |||
connectivity, they place the MAC address in the header of all the | example, when devices use Wi-Fi connectivity, they place the MAC | |||
packets that they transmit. Standard implementation of Wi-Fi use | address in the header of all the packets that they transmit. | |||
unique 48 bit MAC addresses, assigned to the devices according to | Standard implementation of Wi-Fi use unique 48 bit link-layer | |||
procedures defined by IEEE 802. Even when the Wi-Fi packets are | addresses, assigned to the devices according to procedures defined by | |||
encrypted, the portion of the header containing the addresses will be | IEEE 802. Even when the Wi-Fi packets are encrypted, the portion of | |||
sent in clear text. Tracking devices can "listen to the airwaves" to | the header containing the addresses will be sent in clear text. | |||
find out what devices are transmitting near them. | Tracking devices can "listen to the airwaves" to find out what | |||
devices are transmitting near them. | ||||
We can easily imagine that the MAC addresses can be correlated with | We can easily imagine that the MAC addresses can be correlated with | |||
other data, e.g., clear text names and cookies, to build a registry | other data, e.g., clear text names and cookies, to build a registry | |||
linking MAC addresses to the identity of devices' owners. Once that | linking MAC addresses to the identity of devices' owners. Once that | |||
correlation is done, tracking the MAC address is sufficient to track | correlation is done, tracking the MAC address is sufficient to track | |||
individual people, even when all application data sent from the | individual people, even when all application data sent from the | |||
devices is encrypted. MAC addresses can also be correlated with IP | devices is encrypted. link-layer addresses can also be correlated | |||
addresses of devices, negating potential privacy benefits of IPv6 | with IP addresses of devices, negating potential privacy benefits of | |||
"privacy" addresses. Privacy advocates have some reason to be | IPv6 "privacy" addresses. Privacy advocates have reasons to be | |||
concerned. | concerned. | |||
The obvious solution is to "randomize" the MAC address. Before | The obvious solution is to "randomize" the MAC address. Before | |||
connecting to a particular network, the device replaces the MAC | connecting to a particular network, the device replaces the MAC | |||
address with a randomly drawn 48 bit value. MAC address | address with a randomly drawn 48 bit value. Link-layer address | |||
randomization was successfully tried at the IETF in Honolulu in | randomization was successfully tried at the IETF in Honolulu in | |||
November 2014 [IETFMACRandom]. However, we have to consider the | November 2014 [IETFMACRandom]. However, we have to consider the | |||
linkage between MAC addresses, DHCP identifiers and IP addresses. | linkage between link-layer addresses, DHCP identifiers and IP | |||
addresses. | ||||
2.1. MAC Address Randomization hypotheses | 2.1. MAC address Randomization hypotheses | |||
There is not yet an established standard for randomizing MAC | There is not yet an established standard for randomizing link-layer | |||
addresses. Various prototypes have tried different strategies, such | addresses. Various prototypes have tried different strategies, such | |||
as: | as: | |||
Per connection: Configure a random MAC address at the time of | Per connection: Configure a random link-layer address at the time of | |||
connecting to a network, e.g. to specific Wi-Fi SSID, and keep it | connecting to a network, e.g. to specific Wi-Fi SSID, and keep it | |||
for the duration of the connection. | for the duration of the connection. | |||
Per network: Same as "per connection," but always use the same MAC | Per network: Same as "per connection," but always use the same link- | |||
address for the same network -- different of course from the | layer address for the same network -- different of course from the | |||
addresses used in other networks. | addresses used in other networks. | |||
Time interval: Change the MAC address at regular time intervals. | Time interval: Change the link-layer address at regular time | |||
intervals. | ||||
In practice, there are many reasons to keep the MAC address constant | In practice, there are many reasons to keep the link-layer address | |||
for the duration of a link-layer connection, as in the "per | constant for the duration of a link-layer connection, as in the "per | |||
connection" or "per network" variants. On Wi-Fi networks, changing | connection" or "per network" variants. On Wi-Fi networks, changing | |||
the MAC address requires dropping the existing Wi-Fi connection and | the link-layer address requires dropping the existing Wi-Fi | |||
then re-establishing it, which implies repeating the connection | connection and then re-establishing it, which implies repeating the | |||
process and associated procedures. The IP addresses will change, | connection process and associated procedures. The IP addresses will | |||
which means that all required TCP connections will have to be re- | change, which means that all required TCP connections will have to be | |||
established. If the network access is provided through a NAT, | re-established. If the network access is provided through a NAT, | |||
changing IP address also means that the NAT traversal procedures will | changing IP address also means that the NAT traversal procedures will | |||
have to be restarted. This means a lot of disruption. At the same | have to be restarted. This means a lot of disruption. At the same | |||
time, an observer on the network will easily notice that a station | time, an observer on the network will easily notice that a station | |||
left, another came in just after that, and that the new one appears | left, another came in just after that, and that the new one appears | |||
to be communicating with pretty much the same set of IP addresses as | to be communicating with pretty much the same set of IP addresses as | |||
the old one. This provides for easy correlation. | the old one. This provides for easy correlation. | |||
The anonymity profile pretty much assumes that the MAC address | The anonymity profile pretty much assumes that the link-layer address | |||
randomization follows the "per connection" or "per network" | randomization follows the "per connection" or "per network" | |||
strategies, or a variant of the "time interval" strategy in which the | strategies, or a variant of the "time interval" strategy in which the | |||
interval has about the same duration as the average connection. | interval has about the same duration as the average connection. | |||
2.2. MAC Address Randomization and DHCP | 2.2. MAC address Randomization and DHCP | |||
From a privacy point of view, it is clear that MAC Addresses, IP | From a privacy point of view, it is clear that link-layer address, IP | |||
addresses and DHCP identifiers shall evolve in synchrony. For | address and DHCP identifier shall evolve in synchrony. For example, | |||
example, if the MAC address changes and the DHCP identifier stays | if the link-layer address changes and the DHCP identifier stays | |||
constant, then it is really easy to correlate old and new MAC | constant, then it is really easy to correlate old and new link-layer | |||
addresses, either by listening to DHCP traffic or by observing that | addresses, either by listening to DHCP traffic or by observing that | |||
the IP address remains constant, since it is tied to the DHCP | the IP address remains constant, since it is tied to the DHCP | |||
identifier. Conversely, if the DHCP identifier changes but the MAC | identifier. Conversely, if the DHCP identifier changes but the link- | |||
address remains constant, the old and new identifiers and addresses | layer address remains constant, the old and new identifiers and | |||
can be correlated by listening to L2 traffic. The procedures | addresses can be correlated by listening to L2 traffic. The | |||
documented in the following sections construct DHCP identifiers from | procedures documented in the following sections construct DHCP | |||
the current MAC address, automatically providing for this | identifiers from the current link-layer address, automatically | |||
synchronization. | providing for this synchronization. | |||
The proposed anonymity profiles solve this synchronization issues by | The proposed anonymity profiles solve this synchronization issues by | |||
deriving most identifiers from the MAC address, and generally by | deriving most identifiers from the link-layer address, and generally | |||
making making sure that DHCP parameter values do not remain constant | by making making sure that DHCP parameter values do not remain | |||
after an address change. | constant after an address change. | |||
2.3. Radio fingerprinting | 2.3. Radio fingerprinting | |||
MAC address randomization solves the trivial monitoring problem in | MAC address randomization solves the trivial monitoring problem in | |||
which someone just uses a Wi-Fi scanner and records the MAC addresses | which someone just uses a Wi-Fi scanner and records the MAC addresses | |||
seen on the air. DHCP anonymity solves the more elaborated scenario | seen on the air. DHCP anonymity solves the more elaborated scenario | |||
in which someone monitor MAC addresses and identities used in DHCP at | in which someone monitor link-layer addresses and identities used in | |||
the access point or DHCP server. But this are not the only ways to | DHCP at the access point or DHCP server. But these are not the only | |||
track a mobile device. | ways to track a mobile device. | |||
Radio fingerprinting is a process that identifies a radio transmitter | Radio fingerprinting is a process that identifies a radio transmitter | |||
by the unique "fingerprint" of its signal transmission, i.e., the | by the unique "fingerprint" of its signal transmission, i.e., the | |||
tiny differences caused by minute imperfections of the radio | tiny differences caused by minute imperfections of the radio | |||
transmission hardware. This can be applied to diverse types of | transmission hardware. This can be applied to diverse types of | |||
radios, including Wi-Fi as described for example in | radios, including Wi-Fi as described for example in | |||
[WiFiRadioFingerprinting]. No amount of MAC address randomization | [WiFiRadioFingerprinting]. No amount of link-layer address | |||
will protect against such techniques. Protections may exist, but | randomization will protect against such techniques. Protections may | |||
they are outside the scope of the present document. | exist, but they are outside the scope of the present document. | |||
On the other hand, we should not renounce randomization just because | On the other hand, we should not renounce randomization just because | |||
radio fingerprinting exists. The radio fingerprinting techniques are | radio fingerprinting exists. The radio fingerprinting techniques are | |||
harder to deploy than just recording MAC addresses with a scanner. | harder to deploy than just recording link-layer addresses with a | |||
They can only track devices for which the fingerprint are known, and | scanner. They can only track devices for which the fingerprint are | |||
thus have a narrower scope of application than mass monitoring of | known, and thus have a narrower scope of application than mass | |||
addresses and DHCP parameters. | monitoring of addresses and DHCP parameters. | |||
2.4. Operating system fingerprinting | 2.4. Operating system fingerprinting | |||
When a standard like DHCP allows for multiple options, different | When a standard like DHCP allows for multiple options, different | |||
implementers will make different choices for the options that they | implementers will make different choices for the options that they | |||
support or the values they chose for the options. Conversely, | support or the values they chose for the options. Conversely, | |||
monitoring the options and values present in DHCP messages reveals | monitoring the options and values present in DHCP messages reveals | |||
these differences and allows for "operating system fingerprinting," | these differences and allows for "operating system fingerprinting," | |||
i.e., finding the type and version of software that a particular | i.e., finding the type and version of software that a particular | |||
device is running. Finding these versions provides some information | device is running. Finding these versions provides some information | |||
skipping to change at page 6, line 36 | skipping to change at page 6, line 38 | |||
possibilities of operating system fingerprinting. | possibilities of operating system fingerprinting. | |||
2.5. No anonymity profile identification | 2.5. No anonymity profile identification | |||
Reviewers of the anonymity profiles have sometimes suggested adding | Reviewers of the anonymity profiles have sometimes suggested adding | |||
an option to explicitly identify the profiles as "using the anonymity | an option to explicitly identify the profiles as "using the anonymity | |||
option." One suggestion is that if the client wishes to remain | option." One suggestion is that if the client wishes to remain | |||
anonymous, it would be good if the client told the server about that | anonymous, it would be good if the client told the server about that | |||
in case the server is willing to co-operate. Another possibility | in case the server is willing to co-operate. Another possibility | |||
would be to use specific privacy-oriented construct, such as for | would be to use specific privacy-oriented construct, such as for | |||
example a new type of DUID of temporary DUID that would be changing | example a new type of DUID for a temporary DUID that would be | |||
over time. | changing over time. | |||
This is not workable in a large number of cases as it is possible | This is not workable in a large number of cases as it is possible | |||
that the network operator (or other entities that have access to the | that the network operator (or other entities that have access to the | |||
operator's network) might be actively participating in surveillance | operator's network) might be actively participating in surveillance | |||
and anti-privacy, willingly or not. Declaring a preference for | and anti-privacy, willingly or not. Declaring a preference for | |||
anonymity is a bit like walking around with a Guy Fawkes mask. When | anonymity is a bit like walking around with a Guy Fawkes mask. When | |||
anonymity is required, it is generally not a good idea to stick out | anonymity is required, it is generally not a good idea to stick out | |||
of the crowd. Simply revealing the desire for privacy, could cause | of the crowd. Simply revealing the desire for privacy, could cause | |||
the attacker to react by triggering additional surveillance or | the attacker to react by triggering additional surveillance or | |||
monitoring mechanisms. Therefore we feel that it is preferable to | monitoring mechanisms. Therefore we feel that it is preferable to | |||
not disclose one's desire for privacy. | not disclose one's desire for privacy. | |||
This preference leads to some important implications. In particular, | This preference leads to some important implications. In particular, | |||
we make an effort to make the mitigation techniques difficult to | we make an effort to make the mitigation techniques difficult to | |||
distinguish from regular client behaviors, if at all possible. | distinguish from regular client behaviors, if at all possible. | |||
2.6. Using the anonymity profiles | 2.6. Using the anonymity profiles | |||
There are downsides to randomizing MAC addresses and DHCP | There are downsides to randomizing link-layer addresses and DHCP | |||
identifiers. By definition, randomization will break management | identifiers. By definition, randomization will break management | |||
procedures that rely on tracking MAC addresses. Even if this is not | procedures that rely on tracking link-layer addresses. Even if this | |||
too much of a concern, we have to be worried about the frequency of | is not too much of a concern, we have to be worried about the | |||
MAC address randomization. Suppose for example that many devices | frequency of link-layer address randomization. Suppose for example | |||
would get new random MAC addresses at short intervals, maybe every | that many devices would get new random link-layer addresses at short | |||
few minutes. This would generate new DHCP requests in rapid | intervals, maybe every few minutes. This would generate new DHCP | |||
succession, with a high risk of exhausting DHCPv4 address pools. | requests in rapid succession, with a high risk of exhausting DHCPv4 | |||
Even with IPv6, there would still be a risk of increased neighbor | address pools. Even with IPv6, there would still be a risk of | |||
discovery traffic, and bloating of various address tables. | increased neighbor discovery traffic, and bloating of various address | |||
Implementers will have to be cautious when programming devices to use | tables. Implementers will have to be cautious when programming | |||
randomized MAC addresses. They will have to carefully chose the | devices to use randomized MAC addresses. They will have to carefully | |||
frequency with which such addresses will be renewed. | chose the frequency with which such addresses will be renewed. | |||
This document only provides guidelines for using DHCP when clients | This document only provides guidelines for using DHCP when clients | |||
care about privacy and servers do not object. We assume that the | care about privacy and servers do not object. We assume that the | |||
request for anonymity is materialized by the assignment of a | request for anonymity is materialized by the assignment of a | |||
randomized MAC address to the network interface. Once that decision | randomized link-layer address to the network interface. Once that | |||
is made, the following guidelines will avoid leakage of identity in | decision is made, the following guidelines will avoid leakage of | |||
DHCP parameters or in assigned addresses. | identity in DHCP parameters or in assigned addresses. | |||
There may be rare situations where the clients want anonymity to | There may be rare situations where the clients want anonymity to | |||
attackers but not to their DHCP server. These clients should still | attackers but not to their DHCP server. These clients should still | |||
use MAC Address randomization to hide from observers, and some form | use link-layer address randomization to hide from observers, and some | |||
of encrypted communication to the DHCP server. This scenario is not | form of encrypted communication to the DHCP server. This scenario is | |||
yet supported in this document. | not yet supported in this document. | |||
To preserve anonymity, the clients need to not use stable values for | To preserve anonymity, the clients need to not use stable values for | |||
the client identifiers. This is clearly a tradeoff, because a stable | the client identifiers. This is clearly a tradeoff, because a stable | |||
client identifier guarantees that the client will receive consistent | client identifier guarantees that the client will receive consistent | |||
parameters over time. An example is given in | parameters over time. An example is given in [RFC7618], where the | |||
[I-D.ietf-dhc-dynamic-shared-v4allocation], where the client | client identifier is used to guarantee that the same client will | |||
identifier is used to guarantee that the same client will always get | always get the same combination of IP address and port range. Static | |||
the same combination of IP address and port range. Static clients | clients benefit most from stable parameters, and can often be already | |||
benefit most from stable parameters, and can often be already | ||||
identified by physical connection layer parameters. These static | identified by physical connection layer parameters. These static | |||
clients will normally not use the anonymity profile. Mobile clients, | clients will normally not use the anonymity profile. Mobile clients, | |||
in contrast, have the option of using the anonymity profile in | in contrast, have the option of using the anonymity profile in | |||
conjunction with [I-D.ietf-dhc-dynamic-shared-v4allocation] if they | conjunction with [RFC7618] if they are more concerned with privacy | |||
are more concerned with privacy protection than with stable | protection than with stable parameters. | |||
parameters. | ||||
2.7. What about privacy for DHCP servers | 2.7. What about privacy for DHCP servers | |||
This document only provides recommendations for DHCP clients. The | This document only provides recommendations for DHCP clients. The | |||
main target are DHCP clients used in mobile devices. Such devices | main target are DHCP clients used in mobile devices. Such devices | |||
are a tempting target for various monitoring systems, and providing | are a tempting target for various monitoring systems, and providing | |||
them with a simple anonymity solution is urgent. We can argue that | them with a simple anonymity solution is urgent. We can argue that | |||
some mobile devices embed DHCP servers, and that providing solutions | some mobile devices embed DHCP servers, and that providing solutions | |||
for such devices is also quite important. Two plausible examples | for such devices is also quite important. Two plausible examples | |||
would be a DHCP server for a car network, or a DHCP server for a | would be a DHCP server for a car network, or a DHCP server for a | |||
mobile hot spot. However, mobile servers get a lot of privacy | mobile hot spot. However, mobile servers get a lot of privacy | |||
protection through the use of access control and link layer | protection through the use of access control and link layer | |||
encryption. Servers may disclose information to clients through | encryption. Servers may disclose information to clients through | |||
DHCP, but they normally only do that to clients that have passed the | DHCP, but they normally only do that to clients that have passed the | |||
link-layer access control and have been authorized to use the network | link-layer access control and have been authorized to use the network | |||
services. This arguably makes solving the server problem less urgent | services. This arguably makes solving the server problem less urgent | |||
than solving the client problem. | than solving the client problem. | |||
The server part will be covered by the general mitigation work going | Server privacy issues are presented in [I-D.ietf-dhc-dhcp-privacy] | |||
on in DHCP working group, following the analyses presented in | and [I-D.ietf-dhc-dhcpv6-privacy]. Mitigation of these issues is | |||
[I-D.ietf-dhc-dhcp-privacy] and [I-D.ietf-dhc-dhcpv6-privacy]. | left to further study. | |||
3. Anonymity profile for DHCPv4 | 3. Anonymity profile for DHCPv4 | |||
Clients using the DHCPv4 anonymity profile limit the disclosure of | Clients using the DHCPv4 anonymity profile limit the disclosure of | |||
information by controlling the header parameters and by limiting the | information by controlling the header parameters and by limiting the | |||
number and values of options. The number of options depend on the | number and values of options. The number of options depend on the | |||
specific DHCP message: | specific DHCP message: | |||
DISCOVER: The anonymized DISCOVER messages MUST contain the Message | DISCOVER: The anonymized DISCOVER messages MUST contain the Message | |||
Type, Client Identifier, and Parameter Request List options. It | Type, Client Identifier, and Parameter Request List options. It | |||
skipping to change at page 8, line 45 | skipping to change at page 8, line 50 | |||
it SHOULD contain the corresponding Server Identifier option. It | it SHOULD contain the corresponding Server Identifier option. It | |||
SHOULD NOT contain any other option. | SHOULD NOT contain any other option. | |||
DECLINE: The anonymized DECLINE messages SHOULD contain the Message | DECLINE: The anonymized DECLINE messages SHOULD contain the Message | |||
Type, Client Identifier and Server Identifier options. | Type, Client Identifier and Server Identifier options. | |||
RELEASE: The anonymized RELEASE messages SHOULD contain the Message | RELEASE: The anonymized RELEASE messages SHOULD contain the Message | |||
Type, Client Identifier and Server Identifier options. | Type, Client Identifier and Server Identifier options. | |||
INFORM: The anonymized INFORM messages MUST contain the Message | INFORM: The anonymized INFORM messages MUST contain the Message | |||
Type, Client Id, and Parameter Request List options. It SHOULD | Type, Client Identifier, and Parameter Request List options. It | |||
NOT contain any other option. | SHOULD NOT contain any other option. | |||
Header fields and option values SHOULD be set in accordance with the | Header fields and option values SHOULD be set in accordance with the | |||
DHCP specification, but some header fields and option values SHOULD | DHCP specification, but some header fields and option values SHOULD | |||
be constructed per the following guidelines. | be constructed per the following guidelines. | |||
The inclusion of HostName and FQDN options in DISCOVER, REQUEST or | The inclusion of HostName and FQDN options in DISCOVER, REQUEST or | |||
INFORM messages is discussed in Section 3.5 and Section 3.6. | INFORM messages is discussed in Section 3.7 and Section 3.8. | |||
3.1. Client IP address field | 3.1. Option encoding and avoiding fingerprinting | |||
There are many choices for implementing DHCPv4 messages. Clients can | ||||
choose to transmit a specific set of options, pick particular | ||||
encoding for these options, and transmit options in different orders. | ||||
These choices can be use to fingerprint the client. | ||||
The following sections provide guidance on the encoding of options. | ||||
However, this guidance alone may not be sufficient to prevent | ||||
fingerprinting from revealing information, such as the device type, | ||||
vendor type or OS type and in some cases specific version, or from | ||||
revealing whether the client is using the anonymity profile. | ||||
The client willing to protect its privacy SHOULD limit the subset of | ||||
options sent in messages to the subset listed in the following | ||||
sections. | ||||
The client willing to protect its privacy SHOULD randomize options | ||||
order before sending any DHCPv4 message. If this random ordering | ||||
cannot be implemented, the client MAY arrange options by increasing | ||||
order of option codes. | ||||
3.2. Client IP address field | ||||
Four bytes in the header of the DHCP messages carry the "Client IP | Four bytes in the header of the DHCP messages carry the "Client IP | |||
address" (ciaddr) as defined in [RFC2131]. In DHCP, this field is | address" (ciaddr) as defined in [RFC2131]. In DHCP, this field is | |||
used by the clients to indicate the address that they used | used by the clients to indicate the address that they used | |||
previously, so that as much as possible the server can allocate them | previously, so that as much as possible the server can allocate them | |||
the same address. | the same address. | |||
There is very little privacy implication of sending this address in | There is very little privacy implication of sending this address in | |||
the DHCP messages, except in one case, when connecting to a different | the DHCP messages, except in one case, when connecting to a different | |||
network than the last network connected. If the DHCP client somehow | network than the last network connected. If the DHCP client somehow | |||
repeated the address used in a previous network attachment, | repeated the address used in a previous network attachment, | |||
monitoring services might use the information to tie the two network | monitoring services might use the information to tie the two network | |||
locations. DHCP clients should ensure that the field is cleared when | locations. DHCP clients should ensure that the field is cleared when | |||
they know that the network attachment has changed, and in particular | they know that the network attachment has changed, and in particular | |||
of the link layer address is reset by the device's administrator. | if the link layer address is reset by the device's administrator. | |||
The clients using the anonymity profile MUST NOT include in the | The clients using the anonymity profile MUST NOT include in the | |||
message a Client IP Address that has been obtained with a different | message a Client IP Address that has been obtained with a different | |||
MAC address. | link-layer address. | |||
3.2. Requested IP address option | 3.3. Requested IP address option | |||
The Requested IP address option (code 50) allows the client to | The Requested IP address option id defined in [RFC2132] with code 50. | |||
request that a particular IP address be assigned. The option is | It allows the client to request that a particular IP address be | |||
mandatory in some protocol messages per [RFC2131], for example when a | assigned. The option is mandatory in some protocol messages per | |||
client selects to use an address offered by a server. However, this | [RFC2131], for example when a client selects to use an address | |||
option is not mandatory in the DHCPDISCOVER message. It is simply a | offered by a server. However, this option is not mandatory in the | |||
convenience, an attempt to regain the same IP address that was used | DHCPDISCOVER message. It is simply a convenience, an attempt to | |||
in a previous connection. Doing so entails the risk of disclosing an | regain the same IP address that was used in a previous connection. | |||
IP address used by the client at a previous location, or with a | Doing so entails the risk of disclosing an IP address used by the | |||
different MAC Address. | client at a previous location, or with a different link-layer | |||
address. | ||||
When using the anonymity profile, clients SHOULD NOT use the | When using the anonymity profile, clients SHOULD NOT use the | |||
Requested IP address option in DHCPDISCOVER Messages. They MUST use | Requested IP address option in DHCPDISCOVER messages. They MUST use | |||
the option when mandated by the DHCP protocol, for example in | the option when mandated by the DHCP protocol, for example in | |||
DHCPREQUEST Messages. | DHCPREQUEST messages. | |||
There are scenarios in which a client connects to a network when a | There are scenarios in which a client connects to a network when a | |||
lease is still valid. In that state, the client that is concerned | lease is still valid. In that state, the client that is concerned | |||
with privacy SHOULD perform a complete four way handshake starting | with privacy SHOULD perform a complete four way handshake starting | |||
with DHCPDISCOVER to obtain a new address lease. If the client can | with DHCPDISCOVER to obtain a new address lease. If the client can | |||
ascertain that this is exactly the same network to which it was | ascertain that this is exactly the same network to which it was | |||
previously connected, and if the link layer address did not change, | previously connected, and if the link layer address did not change, | |||
the client MAY issue a DHCPREQUEST to try reclaim the current | the client MAY issue a DHCPREQUEST to try reclaim the current | |||
address. | address. | |||
3.3. Client hardware address | 3.4. Client hardware address | |||
Sixteen bytes in the header of the DHCP messages carry the "Client | Sixteen bytes in the header of the DHCP messages carry the "Client | |||
hardware address" (chaddr) as defined in [RFC2131]. The presence of | hardware address" (chaddr) as defined in [RFC2131]. The presence of | |||
this address is necessary for the proper operation of the DHCP | this address is necessary for the proper operation of the DHCP | |||
service. | service. | |||
Hardware addresses, called "link layer address" in many RFCs, can be | Hardware addresses, called "link layer address" in many RFCs, can be | |||
used to uniquely identify a device, especially if they follow the | used to uniquely identify a device, especially if they follow the | |||
IEEE 802 recommendations. These unique identifiers can be used by | IEEE 802 recommendations. These unique identifiers can be used by | |||
monitoring services to track the location of the device and its user. | monitoring services to track the location of the device and its user. | |||
The only plausible defense is to somehow reset the hardware address | The only plausible defense is to somehow reset the hardware address | |||
to a random value when visiting an untrusted location, before | to a random value when visiting an untrusted location, before | |||
transmitting anything at that location with the hardware address. If | transmitting anything at that location with the hardware address. If | |||
the hardware address is reset to a new value, or randomized, the DHCP | the hardware address is reset to a new value, or randomized, the DHCP | |||
client SHOULD use the new randomized value in the DHCP messages. | client SHOULD use the new randomized value in the DHCP messages. | |||
3.4. Client Identifier Option | 3.5. Client Identifier Option | |||
The client identifier option is defined in [RFC2132] with option code | The client identifier option is defined in [RFC2132] with option code | |||
61. It is discussed in details in [RFC4361]. The purpose of the | 61. It is discussed in detail in [RFC4361]. The purpose of the | |||
client identifier option is to identify the client in a manner | client identifier option is to identify the client in a manner | |||
independent of the link layer address. This is particularly useful | independent of the link layer address. This is particularly useful | |||
if the DHCP server is expected to assign the same address to the | if the DHCP server is expected to assign the same address to the | |||
client after a network attachment is swapped and the link layer | client after a network attachment is swapped and the link layer | |||
address changes. It is also useful when the same node issues | address changes. It is also useful when the same node issues | |||
requests through several interfaces, and expects the DHCP server to | requests through several interfaces, and expects the DHCP server to | |||
provide consistent configuration data over multiple interfaces. | provide consistent configuration data over multiple interfaces. | |||
The considerations for hardware independence and strong client | The considerations for hardware independence and strong client | |||
identity have an adverse effect on the privacy of mobile clients, | identity have an adverse effect on the privacy of mobile clients, | |||
because the hardware-independent unique identifier obviously enables | because the hardware-independent unique identifier obviously enables | |||
very efficient tracking of the client's movements. | very efficient tracking of the client's movements. One option would | |||
be to not transmit this option at all, but this may affect | ||||
interoperability and will definitely mark the client as requesting | ||||
anonymity, exposing it to the risks mentioned in Section 2.5. | ||||
The recommendations in [RFC4361] are very strong, stating for example | The recommendations in [RFC4361] are very strong, stating for example | |||
that "DHCPv4 clients MUST NOT use client identifiers based solely on | that "DHCPv4 clients MUST NOT use client identifiers based solely on | |||
layer two addresses that are hard-wired to the layer two device | layer two addresses that are hard-wired to the layer two device | |||
(e.g., the Ethernet MAC address)." These strong recommendations are | (e.g., the Ethernet MAC address)." These strong recommendations are | |||
in fact a tradeoff between ease of management and privacy, and the | in fact a tradeoff between ease of management and privacy, and the | |||
tradeoff should depend on the circumstances. | tradeoff should depend on the circumstances. | |||
In contradiction to [RFC4361], When using the anonymity profile, DHCP | In contradiction to [RFC4361], when using the anonymity profile, DHCP | |||
clients MUST use client identifiers based solely on the link layer | clients MUST use client identifiers based solely on the link layer | |||
address that will be used in the underlying connection. This will | address that will be used in the underlying connection. This will | |||
ensure that the DHCP client identifier does not leak any information | ensure that the DHCP client identifier does not leak any information | |||
that is not already available to entities monitoring the network | that is not already available to entities monitoring the network | |||
connection. It will also ensure that a strategy of randomizing the | connection. It will also ensure that a strategy of randomizing the | |||
link layer address will not be nullified by DHCP options. | link layer address will not be nullified by DHCP options. | |||
In general, clients that care about privacy SHOULD NOT use RFC4361 as | ||||
doing so would provide a stable identifier even when MAC | ||||
randomization is used. If RFC4361 needs to be used, it is | ||||
RECOMMENDED for the client to only use the DUID type DUID-LL (3) with | ||||
the link layer address of the interface on which the DHCP message is | ||||
sent. | ||||
There are usages of DHCP where the underlying connection is a point | There are usages of DHCP where the underlying connection is a point | |||
to point link, in which case there is no link layer address available | to point link, in which case there is no link layer address available | |||
to construct a non-revealing identifier. If anonymity is desired in | to construct a non-revealing identifier. If anonymity is desired in | |||
such networks, the client SHOULD pick a random identifier that is | such networks, the client SHOULD pick a random identifier that is | |||
unique to the current link, using for example a combination of a | unique to the current link, using for example a combination of a | |||
local secret and an identifier of the connection. | local secret and an identifier of the connection. | |||
3.5. Host Name Option | 3.6. Parameter Request List | |||
The Parameter Request List (PRL) option is defined in [RFC2132] with | ||||
option code 61. It list the parameters requested from the server by | ||||
the client. Different implementations request different | ||||
parameters.[RFC2132] specifies that "the client MAY list the options | ||||
in order of preference." It practice, this means that different | ||||
client implementations will request different parameters, in | ||||
different orders. | ||||
The choice of option numbers and the specific ordering of option | ||||
numbers in the Parameter Request List can be used to fingerprint the | ||||
client. This may not reveal the identity of a client, but may | ||||
provide additional information, such as the device type, vendor type | ||||
or OS type and in some cases specific version. | ||||
The client willing to protect its privacy SHOULD only request a | ||||
minimal number of options in PRL, and SHOULD also randomly shuffle | ||||
the option codes order in PRL. If this random ordering cannot be | ||||
implemented, the client MAY order option codes order in PRL by | ||||
increasing order of option codes. | ||||
3.7. Host Name Option | ||||
The Host Name option is defined in [RFC2132] with option code 12. | The Host Name option is defined in [RFC2132] with option code 12. | |||
Depending on implementations, the option value can carry either a | Depending on implementations, the option value can carry either a | |||
fully qualified domain name such as "node1984.example.com," or a | fully qualified domain name such as "node1984.example.com," or a | |||
simple host name such as "node1984." The host name is commonly used | simple host name such as "node1984." The host name is commonly used | |||
by the DHCP server to identify the host, and also to automatically | by the DHCP server to identify the host, and also to automatically | |||
update the address of the host in local name services. | update the address of the host in local name services. | |||
Fully qualified domain names are obviously unique identifiers, but | Fully qualified domain names are obviously unique identifiers, but | |||
even simple host names can provide a significant amount of | even simple host names can provide a significant amount of | |||
skipping to change at page 12, line 25 | skipping to change at page 13, line 11 | |||
local link. Clients MAY use the following algorithm: compute a | local link. Clients MAY use the following algorithm: compute a | |||
secure hash of a local secret and of the link layer address that will | secure hash of a local secret and of the link layer address that will | |||
be used in the underlying connection, and then use the hexadecimal | be used in the underlying connection, and then use the hexadecimal | |||
representation of the first 6 bytes of the hash as the obfuscated | representation of the first 6 bytes of the hash as the obfuscated | |||
host name. | host name. | |||
There is a potential downside to having a specific name pattern for | There is a potential downside to having a specific name pattern for | |||
hosts that require anonymity, as explained in Section 2.5. For this | hosts that require anonymity, as explained in Section 2.5. For this | |||
reason, the above algorithm is just a suggestion. | reason, the above algorithm is just a suggestion. | |||
3.6. Client FQDN Option | 3.8. Client FQDN Option | |||
The Client FQDN option is defined in [RFC4702] with option code 81. | The Client FQDN option is defined in [RFC4702] with option code 81. | |||
The option allows the DHCP clients to advertise to the DHCP server | The option allows the DHCP clients to advertise to the DHCP server | |||
their fully qualified domain name (FQDN) such as | their fully qualified domain name (FQDN) such as | |||
"mobile.example.com." This would allow the DHCP server to update in | "mobile.example.com." This would allow the DHCP server to update in | |||
the DNS the PTR record for the IP address allocated to the client. | the DNS the PTR record for the IP address allocated to the client. | |||
Depending on circumstances, either the DHCP client or the DHCP server | Depending on circumstances, either the DHCP client or the DHCP server | |||
could update in the DNS the A record for the FQDN of the client. | could update in the DNS the A record for the FQDN of the client. | |||
Obviously, this option uniquely identifies the client, exposing it to | Obviously, this option uniquely identifies the client, exposing it to | |||
skipping to change at page 12, line 49 | skipping to change at page 13, line 35 | |||
When using the anonymity profile, DHCP clients SHOULD NOT include the | When using the anonymity profile, DHCP clients SHOULD NOT include the | |||
Client FQDN option in their DHCP requests. Alternatively, they MAY | Client FQDN option in their DHCP requests. Alternatively, they MAY | |||
include a special purpose FQDN using the same hostname as in the Host | include a special purpose FQDN using the same hostname as in the Host | |||
Name Option, with a suffix matching the connection-specific DNS | Name Option, with a suffix matching the connection-specific DNS | |||
suffix being advertised by that DHCP server. Having a name in the | suffix being advertised by that DHCP server. Having a name in the | |||
DNS allows working with legacy systems that require one to be there, | DNS allows working with legacy systems that require one to be there, | |||
e.g., by verifying a forward and reverse lookup succeeds with the | e.g., by verifying a forward and reverse lookup succeeds with the | |||
same result. | same result. | |||
3.7. UUID/GUID-based Client Identifier Option | 3.9. UUID/GUID-based Client Identifier Option | |||
The UUID/GUID-based Client Machine Identifier option is defined in | The UUID/GUID-based Client Machine Identifier option is defined in | |||
[RFC4578], with option code 97. The option is part of a set of | [RFC4578], with option code 97. The option is part of a set of | |||
options for Intel Preboot eXecution Environment (PXE). The purpose | options for Intel Preboot eXecution Environment (PXE). The purpose | |||
of the PXE system is to perform management functions on a device | of the PXE system is to perform management functions on a device | |||
before its main OS is operational. The Client Machine Identifier | before its main OS is operational. The Client Machine Identifier | |||
carries a 16-octet Globally Unique Identifier (GUID), which uniquely | carries a 16-octet Globally Unique Identifier (GUID), which uniquely | |||
identifies the device. | identifies the device. | |||
The PXE system is clearly designed for devices operating in a | The PXE system is clearly designed for devices operating in a | |||
controlled environment, and its functions are not meant to be used by | controlled environment, and its functions are not meant to be used by | |||
mobile nodes visiting untrusted networks. If only for privacy | mobile nodes visiting untrusted networks. If only for privacy | |||
reasons, nodes visiting untrusted networks MUST disable the PXE | reasons, nodes visiting untrusted networks MUST disable the PXE | |||
functions, and MUST NOT send the corresponding options. | functions, and MUST NOT send the corresponding options. | |||
3.8. User and Vendor Class DHCP options | 3.10. User and Vendor Class DHCP options | |||
Vendor identifying options are defined in [RFC2132] and [RFC3925]. | Vendor identifying options are defined in [RFC2132] and [RFC3925]. | |||
When using the anonymity profile, DHCP clients SHOULD NOT use the | When using the anonymity profile, DHCP clients SHOULD NOT use the | |||
Vendor Specific Information option (code 43), the Vendor Class | Vendor Specific Information option (code 43), the Vendor Class | |||
Identifier Option (60), the Vendor Class option (code 124), or the | Identifier Option (60), the Vendor Class option (code 124), or the | |||
Vendor Specific Information option (code 125) as these options | Vendor Specific Information option (code 125) as these options | |||
potentially reveal identifying information. | potentially reveal identifying information. | |||
4. Anonymity profile for DHCPv6 | 4. Anonymity profile for DHCPv6 | |||
skipping to change at page 13, line 41 | skipping to change at page 14, line 30 | |||
In the stateless scenario, clients configure addresses using a | In the stateless scenario, clients configure addresses using a | |||
combination of client managed identifiers and router-advertised | combination of client managed identifiers and router-advertised | |||
prefixes, without involving the DHCPv6 services. Different ways of | prefixes, without involving the DHCPv6 services. Different ways of | |||
constructing these prefixes have different implications on privacy, | constructing these prefixes have different implications on privacy, | |||
which are discussed in [I-D.ietf-6man-default-iids] and | which are discussed in [I-D.ietf-6man-default-iids] and | |||
[I-D.ietf-6man-ipv6-address-generation-privacy]. In the stateless | [I-D.ietf-6man-ipv6-address-generation-privacy]. In the stateless | |||
scenario, clients use DHCPv6 to obtain network configuration | scenario, clients use DHCPv6 to obtain network configuration | |||
parameters, through the INFORMATION-REQUEST message. | parameters, through the INFORMATION-REQUEST message. | |||
The choice between the stateful and stateless scenario depends of | The choice between the stateful and stateless scenario depends on | |||
flag and prefix options published by the "Router Advertisement" | flag and prefix options published by the "Router Advertisement" | |||
messages of local routers, as specified in [RFC4861]. When these | messages of local routers, as specified in [RFC4861]. When these | |||
options enable stateless address configuration hosts using the | options enable stateless address configuration hosts using the | |||
anonymity profile SHOULD choose it over stateful address | anonymity profile SHOULD choose it over stateful address | |||
configuration, because stateless configuration requires fewer | configuration, because stateless configuration requires fewer | |||
information disclosure than stateful configuration. | information disclosures than stateful configuration. | |||
When using the anonymity profile, DHCPv6 clients carefully select | When using the anonymity profile, DHCPv6 clients carefully select | |||
DHCPv6 options used in the various messages that they sent. The list | DHCPv6 options used in the various messages that they send. The list | |||
of options that are mandatory or optional for each message is | of options that are mandatory or optional for each message is | |||
specified in [RFC3315]. Some of these options have specific | specified in [RFC3315]. Some of these options have specific | |||
implications on anonymity. The following sections provide guidance | implications on anonymity. The following sections provide guidance | |||
on the choice of option values when using the anonymity profile. | on the choice of option values when using the anonymity profile. | |||
4.1. Do not send Confirm messages, unless really sure where | 4.1. Option encoding and avoiding fingerprinting | |||
The [RFC3315] requires clients to send a Confirm message when they | There are many choices for implementing DHCPv6 messages. As | |||
attach to a new link to verify whether the addressing and | explained in Section 3.1, these choices can be use to fingerprint the | |||
configuration information they previously received is still valid. | client. | |||
This requirement was relaxed in [I-D.ietf-dhc-rfc3315bis]. When | ||||
these clients send Confirm messages, they include any IAs assigned to | The following sections provide guidance on the encoding of options. | |||
the interface that may have moved to a new link, along with the | However, this guidance alone may not be sufficient to prevent | |||
addresses associated with those IAs. By examining the addresses in | fingerprinting from revealing information, such as the device type, | |||
the Confirm message an attacker can trivially identify the previous | vendor type or OS type and in some cases specific version, or from | |||
point(s) of attachment. | revealing whether the client is using the anonymity profile. | |||
The client willing to protect its privacy SHOULD limit the subset of | ||||
options sent in messages to the subset listed in the following | ||||
sections. | ||||
The client willing to protect its privacy SHOULD randomize options | ||||
order before sending any DHCPv6 message. If this random ordering | ||||
cannot be implemented, the client MAY arrange options by increasing | ||||
order of option codes. | ||||
4.2. Do not send Confirm messages, unless really sure where | ||||
[RFC3315] requires clients to send a Confirm message when they attach | ||||
to a new link to verify whether the addressing and configuration | ||||
information they previously received is still valid. This | ||||
requirement was relaxed in [I-D.ietf-dhc-rfc3315bis]. When these | ||||
clients send Confirm messages, they include any IAs assigned to the | ||||
interface that may have moved to a new link, along with the addresses | ||||
associated with those IAs. By examining the addresses in the Confirm | ||||
message an attacker can trivially identify the previous point(s) of | ||||
attachment. | ||||
Clients interested in protecting their privacy SHOULD NOT send | Clients interested in protecting their privacy SHOULD NOT send | |||
Confirm messages and instead directly try to acquire addresses on the | Confirm messages and instead directly try to acquire addresses on the | |||
new link. However, not sending confirm messages can result in | new link. However, not sending confirm messages can result in | |||
connectivity hiatus in some scenarios, e.g. roaming between two | connectivity hiatus in some scenarios, e.g. roaming between two | |||
access points in the same wireless network. DHCPv6 clients that can | access points in the same wireless network. DHCPv6 clients that can | |||
verify that the previous link and the current link are part of the | verify that the previous link and the current link are part of the | |||
same network MAY send Confirm messages while still protecting their | same network MAY send Confirm messages while still protecting their | |||
privacy. | privacy. | |||
4.2. Client Identifier DHCPv6 Option | 4.3. Client Identifier DHCPv6 Option | |||
The client identifier option is defined in [RFC3315] with option code | The client identifier option is defined in [RFC3315] with option code | |||
1. The purpose of the client identifier option is to identify the | 1. The purpose of the client identifier option is to identify the | |||
client to the server. The content of the option is a DHCP User ID | client to the server. The content of the option is a DHCP Unique | |||
(DUID). One of the primary privacy concerns is that a client is | Identifier (DUID). One of the primary privacy concerns is that a | |||
disclosing a stable identifier (the DUID) that can be use for | client is disclosing a stable identifier (the DUID) that can be use | |||
tracking and profiling. Three DUID formats are specified: Link-layer | for tracking and profiling. Three DUID formats are specified in | |||
address plus time, Vendor-assigned unique ID based on Enterprise | [RFC3315]: Link-layer address plus time, Vendor-assigned unique ID | |||
Number, Link-layer address. | based on Enterprise Number, Link-layer address. A fourth type, DUID- | |||
UUID is defined in [RFC6355]. | ||||
When using the anonymity profile in conjunction with randomized MAC | When using the anonymity profile in conjunction with randomized link- | |||
addresses, DHCPv6 clients MUST use the DUID format number 3, Link- | layer addresses, DHCPv6 clients MUST use the DUID format number 3, | |||
layer address. The value of the Link-layer address should be that | Link-layer address. The value of the Link-layer address should be | |||
currently assigned to the interface. | that currently assigned to the interface. | |||
When using the anonymity profile without the benefit of randomized | When using the anonymity profile without the benefit of randomized | |||
MAC addresses, clients that want to protect their privacy SHOULD | link-layer addresses, clients that want to protect their privacy | |||
generate a new randomized DUID-LLT every time they attach to a new | SHOULD generate a new randomized DUID-LLT every time they attach to a | |||
link or detect a possible link change event. The exact details are | new link or detect a possible link change event. The exact details | |||
left up to implementors, but there are several factors should be | are left up to implementors, but there are several factors should be | |||
taken into consideration. The DUID type SHOULD be set to 1 (DUID- | taken into consideration. The DUID type SHOULD be set to 1 (DUID- | |||
LLT). Hardware type SHOULD be set appropriately to the hardware | LLT). Hardware type SHOULD be set appropriately to the hardware | |||
type. Time MAY be set to current time, but this will reveal the fact | type. Time MAY be set to current time, but this will reveal the fact | |||
that the DUID is newly generated. Implementors interested in hiding | that the DUID is newly generated. Implementors interested in hiding | |||
this fact MAY use a time stamp from the past. e.g. a random timestamp | this fact MAY use a time stamp from the past. e.g. a random timestamp | |||
from the previous year could be a good value. In the most common | from the previous year could be a good value. | |||
cases the link-layer address is based on MAC. The first three octets | ||||
are composed of the OUI (Organizationally Unique Identifier) that is | ||||
expected to have a value assigned to a real organization. See | ||||
[IEEE-OUI] for currently assigned values. Using a value that is | ||||
unassigned may disclose the fact that a DUID is randomized. Using a | ||||
value that belongs to a third party may have legal implications. | ||||
4.2.1. Anonymous Information-Request | 4.3.1. Anonymous Information-Request | |||
According to [RFC3315], a DHCPv6 client typically includes its client | According to [RFC3315], a DHCPv6 client typically includes its client | |||
identifier in most of the messages it sends. There is one exception, | identifier in most of the messages it sends. There is one exception, | |||
however. Client is allowed to omit its client identifier when | however. Client is allowed to omit its client identifier when | |||
sending Information-Request. | sending Information-Request. | |||
When using stateless DHCPv6, clients wanting to protect their privacy | When using stateless DHCPv6, clients wanting to protect their privacy | |||
SHOULD NOT include client identifiers in their Information-Request | SHOULD NOT include client identifiers in their Information-Request | |||
messages. This will prevent the server from specifying client- | messages. This will prevent the server from specifying client- | |||
specific options if it is configured to do so, but the need for | specific options if it is configured to do so, but the need for | |||
anonymity precludes such options anyway. | anonymity precludes such options anyway. | |||
4.3. Server Identifier Option | 4.4. Server Identifier Option | |||
When using the anonymity profile, DHCPv6 clients SHOULD use the | When using the anonymity profile, DHCPv6 clients SHOULD use the | |||
Server Identifier Option (code 2) as specified in [RFC3315]. Clients | Server Identifier Option (code 2) as specified in [RFC3315]. Clients | |||
MUST only include server identifier values that were received with | MUST only include server identifier values that were received with | |||
the current MAC address, because reuse of old values discloses | the current link-layer address, because reuse of old values discloses | |||
information that can be used to identify the client. | information that can be used to identify the client. | |||
4.4. Address assignment options | 4.5. Address assignment options | |||
When using the anonymity profile, DHCPv6 clients might have to use | When using the anonymity profile, DHCPv6 clients might have to use | |||
SOLICIT or REQUEST messages to obtain IPv6 addresses through the DHCP | SOLICIT or REQUEST messages to obtain IPv6 addresses through the DHCP | |||
server. The clients SHOULD only use the options necessary to perform | server. The clients SHOULD only use the options necessary to perform | |||
the requested DHCPv6 transactions, such as Identity Association for | the requested DHCPv6 transactions, such as Identity Association for | |||
Non-temporary Addresses Option (code 3) or Identity Association for | Non-temporary Addresses Option (code 3) or Identity Association for | |||
Temporary Addresses Option (code 4). | Temporary Addresses Option (code 4). | |||
The clients MAY use the IA Address Option (code 5) but need to | The clients MAY use the IA Address Option (code 5) but need to | |||
balance the potential advantage of "address continuity" versus the | balance the potential advantage of "address continuity" versus the | |||
potential risk of "previous address disclosure." A potential | potential risk of "previous address disclosure." A potential | |||
solution is to remove all stored addresses when a MAC address | solution is to remove all stored addresses when a link-layer address | |||
changes, and to only use the IA Address option with addresses that | changes, and to only use the IA Address option with addresses that | |||
have been explicitly assigned through the current MAC address. | have been explicitly assigned through the current link-layer address. | |||
The interaction between prefix delegation and anonymity require | The interaction between prefix delegation and anonymity require | |||
further study. For now, the simple solution is to avoid using prefix | further study. For now, the simple solution is to avoid using prefix | |||
delegation when striving for anonymity. When using the anonymity | delegation when striving for anonymity. When using the anonymity | |||
profiles, clients SHOULD NOT use IA_PD, the prefix delegation form of | profiles, clients SHOULD NOT use IA_PD, the prefix delegation form of | |||
address assignment. | address assignment. | |||
4.4.1. Obtain temporary addresses | 4.5.1. Obtain temporary addresses | |||
[RFC3315] defines a special container (IA_TA) for requesting | [RFC3315] defines a special container (IA_TA) for requesting | |||
temporary addresses. This is a good mechanism in principle, but | temporary addresses. This is a good mechanism in principle, but | |||
there are a number of issues associated with it. First of all, this | there are a number of issues associated with it. First, this is not | |||
is not widely used feature. Thus clients cannot count on it to be | a widely used feature, so clients depending solely on temporary | |||
always available. Secondly, [RFC3315] does not specify any renewal | addresses may lock themselves out of service. Secondly, [RFC3315] | |||
mechanisms for temporary addresses. Therefore the support for | does not specify any lifetime or lease length for temporary | |||
renewing temporary addresses in server implementations usually varies | addresses. Therefore support for renewing temporary addresses may | |||
between poor and non-existent. Finally, a client reveals its desire | vary between client implementations, including not being supported at | |||
for privacy just by requesting temporary addresses, and potentially | all. Finally, by requesting temporary addresses a client reveals its | |||
risks countermeasures as described in Section 2.5. | desire for privacy and potentially risks countermeasures as described | |||
in Section 2.5. | ||||
Clients interested in their privacy SHOULD NOT use the IA_TA. They | Clients interested in their privacy SHOULD NOT use IA_TA. They | |||
should simply send an IA_NA with a randomized IAID. This, along with | should simply send an IA_NA with a randomized IAID. This, along with | |||
the mitigation technique discussed in Section 4.3, will ensure that a | the mitigation technique discussed in Section 4.4, will ensure that a | |||
client will get a new address that can be renewed and can be used as | client will get a new address that can be renewed and can be used as | |||
long as needed. To get a new address, it can send Request message | long as needed. To get a new address, it can send Request message | |||
with a new randomized IAID before releasing the older one. This will | with a new randomized IAID before releasing the other one. This will | |||
cause the server to assign a new address, as it still has a valid | cause the server to assign a new address, as it still has a valid | |||
lease for the old IAID value. Once a new address is assigned, the | lease for the old IAID value. Once a new address is assigned, the | |||
address obtained using the older IAID value can be released safely or | address obtained using the older IAID value can be released safely, | |||
be allowed to time out. | using the Release message or it may simply be allowed to time out. | |||
From the Operating System perspective, addresses obtained using this | ||||
technique SHOULD be treated as temporary addresses as specified in | ||||
[RFC4941]. | ||||
Note that this solution may not work if the server enforces specific | This solution may not work if the server enforces specific policies, | |||
policies such as providing only one address per client. If client | e.g. only one address per client. If client does not succeed in | |||
does not succeed in obtaining a second address using a new IAID, it | receiving a second address using a new IAID, it may release the first | |||
needs to release the first one (using an old IAID) and then retry | one (using the old IAID) and then retry asking for a new address. | |||
asking for a new address. | ||||
4.5. Option Request Option | From the Operating System perspective, addresses obtained using this | |||
technique SHOULD be treated as temporary as specified in [RFC4941]. | ||||
A DHCPv6 client may reveal other types of information, besides unique | 4.6. Option Request Option | |||
identifiers. There are many ways a DHCPv6 client can perform certain | ||||
actions and the specifics can be used to fingerprint the client. | ||||
This may not reveal the identity of a client, but may provide | ||||
additional information, such as the device type, vendor type or OS | ||||
type and in some cases specific version. | ||||
One specific method used for fingerprinting utilizes the order in | The Option Request Option (ORO) is defined in [RFC3315] with option | |||
which options are included in the message. Another related technique | code 6. It specifies the options that the client is requesting from | |||
utilizes the order in which option codes are included in an Option | the server. The choice of requested options and the order of | |||
Request Option (ORO). | encoding of these options in the ORO can be used to fingerprint the | |||
client. | ||||
The client willing to protect its privacy SHOULD randomize options | The client willing to protect its privacy SHOULD only request a | |||
order before sending any DHCPv6 message. Such a client SHOULD also | minimal subset of options and SHOULD randomly shuffle the option | |||
randomly shuffle the option codes order in ORO. | codes order in ORO. If this random ordering cannot be implemented, | |||
the client MAY order option codes in ORO by increasing order of | ||||
option codes. | ||||
4.5.1. Previous option values | 4.6.1. Previous option values | |||
According to [RFC3315], the client that includes an Option Request | According to [RFC3315], the client that includes an Option Request | |||
Option in a Solicit or Request message MAY additionally include | Option in a Solicit or Request message 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. | |||
When using the anonymity profile, clients SHOULD NOT include such | When using the anonymity profile, clients SHOULD NOT include such | |||
instances of options because old values might be used to identify the | instances of options because old values might be used to identify the | |||
client. | client. | |||
4.6. Authentication Option | 4.7. Authentication Option | |||
The purpose of the Authentication option (code 11) is to authenticate | The purpose of the Authentication option (code 11) is to authenticate | |||
the identity of clients and servers and the contents of DHCP | the identity of clients and servers and the contents of DHCP | |||
messages. As such, the option can be used to identify the client, | messages. As such, the option can be used to identify the client, | |||
and is incompatible with the stated goal of "client anonymity." | and is incompatible with the stated goal of "client anonymity." | |||
DHCPv6 clients that use the anonymity profile SHOULD NOT use the | DHCPv6 clients that use the anonymity profile SHOULD NOT use the | |||
authentication option. They MAY use it if they recognize that they | authentication option. They MAY use it if they recognize that they | |||
are operating in a trusted environment, e.g., in a work place | are operating in a trusted environment, e.g., in a work place | |||
network. | network. | |||
4.7. User and Vendor Class DHCPv6 options | 4.8. User and Vendor Class DHCPv6 options | |||
When using the anonymity profile, DHCPv6 clients SHOULD NOT use the | When using the anonymity profile, DHCPv6 clients SHOULD NOT use the | |||
User Class option (code 15) or the Vendor Class option (code 16), as | User Class option (code 15) or the Vendor Class option (code 16), as | |||
these options potentially reveal identifying information. | these options potentially reveal identifying information. | |||
4.8. Client FQDN Option | 4.9. Client FQDN Option | |||
The Client FQDN option is defined in [RFC4704] with option code 29. | The Client FQDN option is defined in [RFC4704] with option code 29. | |||
The option allows the DHCP clients to advertize to the DHCP their | The option allows the DHCP clients to advertise to the DHCP server | |||
fully qualified domain name (FQDN) such as "mobile.example.com." | their fully qualified domain name (FQDN) such as | |||
When using the anonymity profile, DHCPv6 clients SHOULD NOT include | "mobile.example.com." When using the anonymity profile, DHCPv6 | |||
the Client FQDN option in their DHCPv6 messages because it identifies | clients SHOULD NOT include the Client FQDN option in their DHCPv6 | |||
the client. As explained in Section 3.6 they MAY use a local-only | messages because it identifies the client. As explained in | |||
FQDN by combining a host name derived from the link layer address and | Section 3.8 they MAY use a local-only FQDN by combining a host name | |||
a suffix advertised by the local DHCP server. | derived from the link layer address and a suffix advertised by the | |||
local DHCP server. | ||||
5. Operational Considerations | 5. Operational Considerations | |||
The anonymity profile has the effect of hiding the client identity | The anonymity profile has the effect of hiding the client identity | |||
from the DHCP server. This is not always desirable. Some DHCP | from the DHCP server. This is not always desirable. Some DHCP | |||
servers provide facilities like publishing names and addresses in the | servers provide facilities like publishing names and addresses in the | |||
DNS, or ensuring that returning clients get reassigned the same | DNS, or ensuring that returning clients get reassigned the same | |||
address. | address. | |||
Clients using the anonymity profile may be consuming more resources. | Clients using the anonymity profile may be consuming more resources. | |||
For example when they change MAC address and request for a new IP, | For example when they change link-layer address and request for a new | |||
the old one is still marked as leased by the server. | IP, the old one is still marked as leased by the server. | |||
Implementers SHOULD provide a way for clients to control when the | Implementers SHOULD provide a way for clients to control when the | |||
anonymity profile is used, and when standard behavior is preferred. | anonymity profile is used, and when standard behavior is preferred. | |||
Implementers MAY implement this control by tying use of the anonymity | Implementers MAY implement this control by tying use of the anonymity | |||
profile to that of link-layer address randomization. | profile to that of link-layer address randomization. | |||
6. Security Considerations | 6. Security Considerations | |||
The use of the anonymity profile does not change the security | The use of the anonymity profile does not change the security | |||
considerations of the DHCPv4 or DHCPv6 protocols. | considerations of the DHCPv4 or DHCPv6 protocols. | |||
7. IANA Considerations | 7. IANA Considerations | |||
This draft does not require any IANA action. | This draft does not require any IANA action. | |||
8. Acknowledgments | 8. Acknowledgments | |||
The inspiration for this draft came from discussions in the Perpass | The inspiration for this draft came from discussions in the Perpass | |||
mailing list. Several people provided feedback on this draft, | mailing list. Several people provided feedback on this draft, | |||
notably Noel Anderson, Lorenzo Colitti, Stephen Farrell, Nick Grifka, | notably Noel Anderson, Lorenzo Colitti, Stephen Farrell, Nick Grifka, | |||
Tushar Gupta, Gabriel Montenegro, Marcin Siodelski, Dave Thaler and | Tushar Gupta, Gabriel Montenegro, Marcin Siodelski, Dave Thaler, | |||
Jun Wu. | Bernie Volz, and Jun Wu. | |||
9. Changes from previous versions | 9. Changes from previous versions | |||
The RFC Editor must ensure that this section is removed prior to RFC | ||||
publication. | ||||
Changes from draft-00 to draft-01: | Changes from draft-00 to draft-01: | |||
1. In Section 2.6, added guidance when using | 1. In Section 2.6, added guidance when using [RFC7618]. | |||
[I-D.ietf-dhc-dynamic-shared-v4allocation]. | ||||
2. In Section 3.4, added guidance for case when no link layer | 2. In Section 3.5, added guidance for case when no link layer | |||
address is available. | address is available. | |||
3. In Section 3.5, changed the recommended mechanism for obfuscating | 3. In Section 3.7, changed the recommended mechanism for obfuscating | |||
host names, in order to avoid reveal the underlying link layer | host names, in order to avoid reveal the underlying link layer | |||
address. | address. | |||
4. In Section 4.1, added an exception to the "should not send | 4. In Section 4.2, added an exception to the "should not send | |||
confirm" recommendation, to account for the "good" use of Confirm | confirm" recommendation, to account for the "good" use of Confirm | |||
when roaming between access points on the same network. | when roaming between access points on the same network. | |||
Changes from draft-01 to draft-02: | ||||
1. In Section 3, checked the requirements of parameters in messages | ||||
to ensure consistency with the main text. | ||||
2. In Section 3.5, added guidance for case when no link layer | ||||
address is available. | ||||
3. In Section 3.7, specified that clients SHOULD NOT send the | ||||
option, and that the optional obfuscation mechanism is just a | ||||
suggestion. | ||||
4. Updated the text in Section 4.5.1 for temporary IPv6 address | ||||
allocation. | ||||
5. Rewrote Section 5 on operational requirements for clarity. | ||||
Changes from draft-02 to draft-03: | ||||
1. Removed the update of [RFC4361] since we are specifying when to | ||||
use that RFC, but are not recommending any specific change. | ||||
2. Fixed a number of typos and nits. | ||||
3. In Section 2.7, specified that mitigation of server privacy | ||||
issues is left for further study. | ||||
4. Moved the guidance on avoiding fingerprinting to Section 3.1 and | ||||
Section 4.1. | ||||
5. In Section 3.5, added text explaining why the client identifier | ||||
option should still be sent, even when anonymity is desired. | ||||
6. Added Section 3.6 specifying the random ordering of requested | ||||
option codes in the PRL parameter, with an alternative option for | ||||
strict ordering. | ||||
7. Changed the requirement in Section 4.6 to allow "increasing order | ||||
of option codes" as an alternative to "randomized order of | ||||
options". | ||||
8. In Section 4.5.1 revised the language stating lack of support for | ||||
renewing temporary addresses, as RFC 3315 does in fact specify a | ||||
mechanism for doing so. | ||||
10. References | 10. References | |||
10.1. Normative References | 10.1. Normative References | |||
[I-D.ietf-dhc-rfc3315bis] | [I-D.ietf-dhc-rfc3315bis] | |||
Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., | Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., | |||
Richardson, M., Jiang, S., and T. Lemon, "Dynamic Host | Richardson, M., Jiang, S., and T. Lemon, "Dynamic Host | |||
Configuration Protocol for IPv6 (DHCPv6) bis", draft-ietf- | Configuration Protocol for IPv6 (DHCPv6) bis", draft-ietf- | |||
dhc-rfc3315bis-01 (work in progress), July 2015. | dhc-rfc3315bis-01 (work in progress), July 2015. | |||
[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>. | ||||
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC | [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", | |||
2131, DOI 10.17487/RFC2131, March 1997, | RFC 2131, DOI 10.17487/RFC2131, March 1997, | |||
<http://www.rfc-editor.org/info/rfc2131>. | <http://www.rfc-editor.org/info/rfc2131>. | |||
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor | [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor | |||
Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, | Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, | |||
<http://www.rfc-editor.org/info/rfc2132>. | <http://www.rfc-editor.org/info/rfc2132>. | |||
[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>. | ||||
[RFC3925] Littlefield, J., "Vendor-Identifying Vendor Options for | [RFC3925] Littlefield, J., "Vendor-Identifying Vendor Options for | |||
Dynamic Host Configuration Protocol version 4 (DHCPv4)", | Dynamic Host Configuration Protocol version 4 (DHCPv4)", | |||
RFC 3925, DOI 10.17487/RFC3925, October 2004, | RFC 3925, DOI 10.17487/RFC3925, October 2004, | |||
<http://www.rfc-editor.org/info/rfc3925>. | <http://www.rfc-editor.org/info/rfc3925>. | |||
[RFC4361] Lemon, T. and B. Sommerfeld, "Node-specific Client | [RFC4361] Lemon, T. and B. Sommerfeld, "Node-specific Client | |||
Identifiers for Dynamic Host Configuration Protocol | Identifiers for Dynamic Host Configuration Protocol | |||
Version Four (DHCPv4)", RFC 4361, DOI 10.17487/RFC4361, | Version Four (DHCPv4)", RFC 4361, DOI 10.17487/RFC4361, | |||
February 2006, <http://www.rfc-editor.org/info/rfc4361>. | February 2006, <http://www.rfc-editor.org/info/rfc4361>. | |||
[RFC4702] Stapp, M., Volz, B., and Y. Rekhter, "The Dynamic Host | [RFC4702] Stapp, M., Volz, B., and Y. Rekhter, "The Dynamic Host | |||
Configuration Protocol (DHCP) Client Fully Qualified | Configuration Protocol (DHCP) Client Fully Qualified | |||
Domain Name (FQDN) Option", RFC 4702, DOI 10.17487/ | Domain Name (FQDN) Option", RFC 4702, | |||
RFC4702, October 2006, | DOI 10.17487/RFC4702, October 2006, | |||
<http://www.rfc-editor.org/info/rfc4702>. | <http://www.rfc-editor.org/info/rfc4702>. | |||
[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>. | ||||
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, | [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, | |||
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, | "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, | |||
September 2007. | DOI 10.17487/RFC4861, September 2007, | |||
<http://www.rfc-editor.org/info/rfc4861>. | ||||
[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>. | ||||
10.2. Informative References | 10.2. Informative References | |||
[CNBC] Weston, G., Greenwald, G., and R. Gallagher, "CBC News: | [CNBC] Weston, G., Greenwald, G., and R. Gallagher, "CBC News: | |||
CSEC used airport Wi-Fi to track Canadian travellers", Jan | CSEC used airport Wi-Fi to track Canadian travellers", Jan | |||
2014, <http://www.cbc.ca/news/politics/csec-used-airport- | 2014, <http://www.cbc.ca/news/politics/csec-used-airport- | |||
wi-fi-to-track-canadian-travellers-edward-snowden- | wi-fi-to-track-canadian-travellers-edward-snowden- | |||
documents-1.2517881>. | documents-1.2517881>. | |||
[I-D.ietf-6man-default-iids] | [I-D.ietf-6man-default-iids] | |||
Gont, F., Cooper, A., Thaler, D., and S. LIU, | Gont, F., Cooper, A., Thaler, D., and S. LIU, | |||
"Recommendation on Stable IPv6 Interface Identifiers", | "Recommendation on Stable IPv6 Interface Identifiers", | |||
draft-ietf-6man-default-iids-05 (work in progress), July | draft-ietf-6man-default-iids-07 (work in progress), August | |||
2015. | 2015. | |||
[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-dhcp-privacy] | [I-D.ietf-dhc-dhcp-privacy] | |||
Jiang, S., Krishnan, S., and T. Mrugalski, "Privacy | Jiang, S., Krishnan, S., and T. Mrugalski, "Privacy | |||
considerations for DHCP", draft-ietf-dhc-dhcp-privacy-00 | considerations for DHCPv4", draft-ietf-dhc-dhcp-privacy-01 | |||
(work in progress), February 2015. | (work in progress), August 2015. | |||
[I-D.ietf-dhc-dhcpv6-privacy] | [I-D.ietf-dhc-dhcpv6-privacy] | |||
Krishnan, S., Mrugalski, T., and S. Jiang, "Privacy | Krishnan, S., Mrugalski, T., and S. Jiang, "Privacy | |||
considerations for DHCPv6", draft-ietf-dhc- | considerations for DHCPv6", draft-ietf-dhc- | |||
dhcpv6-privacy-00 (work in progress), February 2015. | dhcpv6-privacy-01 (work in progress), August 2015. | |||
[I-D.ietf-dhc-dynamic-shared-v4allocation] | ||||
Cui, Y., Qiong, Q., Farrer, I., Lee, Y., Sun, Q., and M. | ||||
Boucadair, "Dynamic Allocation of Shared IPv4 Addresses", | ||||
draft-ietf-dhc-dynamic-shared-v4allocation-09 (work in | ||||
progress), May 2015. | ||||
[IEEE-OUI] | ||||
IEEE, "Organizationally Unique Identifiers | ||||
http://www.ieee.org/netstorage/standards/oui.txt", | ||||
<http://www.ieee.org/netstorage/standards/oui.txt>. | ||||
[IETFMACRandom] | [IETFMACRandom] | |||
Zuniga, JC., "MAC Privacy", November 2014, | Zuniga, JC., "MAC Privacy", November 2014, | |||
<http://www.ietf.org/blog/2014/11/mac-privacy/>. | <http://www.ietf.org/blog/2014/11/mac-privacy/>. | |||
[RFC4578] Johnston, M. and S. Venaas, Ed., "Dynamic Host | [RFC4578] Johnston, M. and S. Venaas, Ed., "Dynamic Host | |||
Configuration Protocol (DHCP) Options for the Intel | Configuration Protocol (DHCP) Options for the Intel | |||
Preboot eXecution Environment (PXE)", RFC 4578, DOI | Preboot eXecution Environment (PXE)", RFC 4578, | |||
10.17487/RFC4578, November 2006, | DOI 10.17487/RFC4578, November 2006, | |||
<http://www.rfc-editor.org/info/rfc4578>. | <http://www.rfc-editor.org/info/rfc4578>. | |||
[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>. | ||||
[RFC7618] Cui, Y., Sun, Q., Farrer, I., Lee, Y., Sun, Q., and M. | ||||
Boucadair, "Dynamic Allocation of Shared IPv4 Addresses", | ||||
RFC 7618, DOI 10.17487/RFC7618, August 2015, | ||||
<http://www.rfc-editor.org/info/rfc7618>. | ||||
[WiFiRadioFingerprinting] | [WiFiRadioFingerprinting] | |||
Brik, V., Banerjee, S., Gruteser, M., and S. Oh, "Wireless | Brik, V., Banerjee, S., Gruteser, M., and S. Oh, "Wireless | |||
Device Identification with Radiometric Signatures", | Device Identification with Radiometric Signatures", | |||
September 2008, <http://www.winlab.rutgers.edu/~gruteser/ | September 2008, | |||
papers/brik_paradis.pdf>. | <http://www.winlab.rutgers.edu/~gruteser/papers/ | |||
brik_paradis.pdf>. | ||||
Authors' Addresses | Authors' Addresses | |||
Christian Huitema | Christian Huitema | |||
Microsoft | Microsoft | |||
Redmond, WA 98052 | Redmond, WA 98052 | |||
U.S.A. | U.S.A. | |||
Email: huitema@microsoft.com | Email: huitema@microsoft.com | |||
End of changes. 107 change blocks. | ||||
285 lines changed or deleted | 394 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/ |