draft-ietf-dhc-anonymity-profile-03.txt | draft-ietf-dhc-anonymity-profile-04.txt | |||
---|---|---|---|---|
Network Working Group C. Huitema | Network Working Group C. Huitema | |||
Internet-Draft Microsoft | Internet-Draft Microsoft | |||
Intended status: Standards Track T. Mrugalski | Intended status: Standards Track T. Mrugalski | |||
Expires: March 4, 2016 ISC | Expires: April 4, 2016 ISC | |||
S. Krishnan | S. Krishnan | |||
Ericsson | Ericsson | |||
September 1, 2015 | October 2, 2015 | |||
Anonymity profile for DHCP clients | Anonymity profile for DHCP clients | |||
draft-ietf-dhc-anonymity-profile-03.txt | draft-ietf-dhc-anonymity-profile-04.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 March 4, 2016. | This Internet-Draft will expire on April 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 24 | skipping to change at page 2, line 24 | |||
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 . . . . . . . . . . . 8 | 2.7. What about privacy for DHCP servers . . . . . . . . . . . 8 | |||
3. Anonymity profile for DHCPv4 . . . . . . . . . . . . . . . . 8 | 3. Anonymity profile for DHCPv4 . . . . . . . . . . . . . . . . 8 | |||
3.1. Option encoding and avoiding fingerprinting . . . . . . . 9 | 3.1. Avoiding fingerprinting . . . . . . . . . . . . . . . . . 9 | |||
3.2. Client IP address field . . . . . . . . . . . . . . . . . 9 | 3.2. Client IP address field . . . . . . . . . . . . . . . . . 9 | |||
3.3. Requested IP address option . . . . . . . . . . . . . . . 10 | 3.3. Requested IP address option . . . . . . . . . . . . . . . 10 | |||
3.4. Client hardware address . . . . . . . . . . . . . . . . . 10 | 3.4. Client hardware address field . . . . . . . . . . . . . . 10 | |||
3.5. Client Identifier Option . . . . . . . . . . . . . . . . 11 | 3.5. Client Identifier Option . . . . . . . . . . . . . . . . 11 | |||
3.6. Parameter Request List . . . . . . . . . . . . . . . . . 11 | 3.6. Parameter Request List Option . . . . . . . . . . . . . . 12 | |||
3.7. Host Name Option . . . . . . . . . . . . . . . . . . . . 12 | 3.7. Host Name Option . . . . . . . . . . . . . . . . . . . . 12 | |||
3.8. Client FQDN Option . . . . . . . . . . . . . . . . . . . 13 | 3.8. Client FQDN Option . . . . . . . . . . . . . . . . . . . 13 | |||
3.9. UUID/GUID-based Client Identifier Option . . . . . . . . 13 | 3.9. UUID/GUID-based Client Identifier Option . . . . . . . . 13 | |||
3.10. User and Vendor Class DHCP options . . . . . . . . . . . 14 | 3.10. User and Vendor Class DHCP options . . . . . . . . . . . 14 | |||
4. Anonymity profile for DHCPv6 . . . . . . . . . . . . . . . . 14 | 4. Anonymity profile for DHCPv6 . . . . . . . . . . . . . . . . 14 | |||
4.1. Option encoding and avoiding fingerprinting . . . . . . . 14 | 4.1. Option encoding and avoiding fingerprinting . . . . . . . 15 | |||
4.2. Do not send Confirm messages, unless really sure where . 15 | 4.2. Do not send Confirm messages, unless really sure where . 15 | |||
4.3. Client Identifier DHCPv6 Option . . . . . . . . . . . . . 15 | 4.3. Client Identifier DHCPv6 Option . . . . . . . . . . . . . 16 | |||
4.3.1. Anonymous Information-Request . . . . . . . . . . . . 16 | 4.3.1. Anonymous Information-Request . . . . . . . . . . . . 16 | |||
4.4. Server Identifier Option . . . . . . . . . . . . . . . . 16 | 4.4. Server Identifier Option . . . . . . . . . . . . . . . . 16 | |||
4.5. Address assignment options . . . . . . . . . . . . . . . 16 | 4.5. Address assignment options . . . . . . . . . . . . . . . 17 | |||
4.5.1. Obtain temporary addresses . . . . . . . . . . . . . 17 | 4.5.1. Obtain temporary addresses . . . . . . . . . . . . . 17 | |||
4.6. Option Request Option . . . . . . . . . . . . . . . . . . 17 | 4.5.2. Prefix delegation . . . . . . . . . . . . . . . . . . 18 | |||
4.6. Option Request Option . . . . . . . . . . . . . . . . . . 18 | ||||
4.6.1. Previous option values . . . . . . . . . . . . . . . 18 | 4.6.1. Previous option values . . . . . . . . . . . . . . . 18 | |||
4.7. Authentication Option . . . . . . . . . . . . . . . . . . 18 | 4.7. Authentication Option . . . . . . . . . . . . . . . . . . 19 | |||
4.8. User and Vendor Class DHCPv6 options . . . . . . . . . . 18 | 4.8. User and Vendor Class DHCPv6 options . . . . . . . . . . 19 | |||
4.9. Client FQDN Option . . . . . . . . . . . . . . . . . . . 18 | 4.9. Client FQDN Option . . . . . . . . . . . . . . . . . . . 19 | |||
5. Operational Considerations . . . . . . . . . . . . . . . . . 19 | 5. Operational Considerations . . . . . . . . . . . . . . . . . 19 | |||
6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 | |||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 | |||
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 | 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 | |||
9. Changes from previous versions . . . . . . . . . . . . . . . 19 | 9. Changes from previous versions . . . . . . . . . . . . . . . 20 | |||
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 | |||
10.1. Normative References . . . . . . . . . . . . . . . . . . 21 | 10.1. Normative References . . . . . . . . . . . . . . . . . . 22 | |||
10.2. Informative References . . . . . . . . . . . . . . . . . 22 | 10.2. Informative References . . . . . . . . . . . . . . . . . 23 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 | |||
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 5, line 33 | skipping to change at page 5, line 34 | |||
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 link- | identifier. Conversely, if the DHCP identifier changes but the link- | |||
layer address remains constant, the old and new identifiers and | layer address remains constant, the old and new identifiers and | |||
addresses can be correlated by listening to L2 traffic. The | addresses can be correlated by listening to L2 traffic. The | |||
procedures documented in the following sections construct DHCP | procedures documented in the following sections construct DHCP | |||
identifiers from the current link-layer address, automatically | identifiers from the current link-layer address, automatically | |||
providing for this 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 link-layer address, and generally | deriving most identifiers from the link-layer address, and generally | |||
by making making sure that DHCP parameter values do not remain | by making sure that DHCP parameter values do not remain constant | |||
constant after an address change. | 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 link-layer addresses and identities used in | in which someone monitor link-layer addresses and identities used in | |||
DHCP at the access point or DHCP server. But these are not the only | DHCP at the access point or DHCP server. But these are not the only | |||
ways to track a mobile device. | ways to track a mobile device. | |||
skipping to change at page 7, line 36 | skipping to change at page 7, line 36 | |||
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 link-layer address to the network interface. Once that | randomized link-layer address to the network interface. Once that | |||
decision is made, the following guidelines will avoid leakage of | decision is made, the following guidelines will avoid leakage of | |||
identity in 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 link-layer address randomization to hide from observers, and some | use link-layer address randomization to hide from observers, and some | |||
form of encrypted communication to the DHCP server. This scenario is | form of encrypted communication to the DHCP server. This scenario is | |||
not yet supported in this document. | out of scope for 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 [RFC7618], where the | parameters over time. An example is given in [RFC7618], where the | |||
client identifier is used to guarantee that the same client will | client identifier is used to guarantee that the same client will | |||
always get the same combination of IP address and port range. Static | always get the same combination of IP address and port range. Static | |||
clients benefit most from stable parameters, and can often be already | clients 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, | |||
skipping to change at page 8, line 33 | skipping to change at page 8, line 33 | |||
and [I-D.ietf-dhc-dhcpv6-privacy]. Mitigation of these issues is | and [I-D.ietf-dhc-dhcpv6-privacy]. Mitigation of these issues is | |||
left to further study. | 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 | DHCPDISCOVER: The anonymized DHCPDISCOVER messages MUST contain the | |||
Type, Client Identifier, and Parameter Request List options. It | Message Type, MAY contain the Client Identifier, and MAY contain | |||
SHOULD NOT contain any other option. | the Parameter Request List options. It SHOULD NOT contain any | |||
other option. | ||||
REQUEST: The anonymized REQUEST messages SHOULD contain the Message | DHCPREQUEST: The anonymized DHCPREQUEST messages MUST contain the | |||
Type, Client Identifier, Requested IP address and Parameter | Message Type, MAY contain the Client Identifier, and MAY contain | |||
Request List options. If the message is in response to an OFFER, | the Parameter Request List options. If the message is in response | |||
it SHOULD contain the corresponding Server Identifier option. It | to a DHCPOFFER, it MUST contain the corresponding Server | |||
SHOULD NOT contain any other option. | Identifier option and the Requested IP address. If the message is | |||
not in response to a DHCPOFFER, it MAY contain a Requested IP | ||||
address as explained in Section 3.3. It SHOULD NOT contain any | ||||
other option. | ||||
DECLINE: The anonymized DECLINE messages SHOULD contain the Message | DHCPDECLINE: The anonymized DHCPDECLINE messages MUST contain the | |||
Type, Client Identifier and Server Identifier options. | Message Type, Server Identifier, and Requested IP address options, | |||
and MAY contain the Client Identifier options. | ||||
RELEASE: The anonymized RELEASE messages SHOULD contain the Message | DHCPRELEASE: The anonymized DHCPRELEASE messages MUST contain the | |||
Type, Client Identifier and Server Identifier options. | Message Type and Server Identifier options, and MAY contain the | |||
Client Identifier option. | ||||
INFORM: The anonymized INFORM messages MUST contain the Message | DHCPINFORM: The anonymized DHCPINFORM messages MUST contain the | |||
Type, Client Identifier, and Parameter Request List options. It | Message Type, and MAY contain the Client Identifier and Parameter | |||
SHOULD NOT contain any other option. | Request List options. It 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 DHCPDISCOVER, | |||
INFORM messages is discussed in Section 3.7 and Section 3.8. | DHCPREQUEST or DHCPINFORM messages is discussed in Section 3.7 and | |||
Section 3.8. | ||||
3.1. Option encoding and avoiding fingerprinting | 3.1. Avoiding fingerprinting | |||
There are many choices for implementing DHCPv4 messages. Clients can | There are many choices for implementing DHCPv4 messages. Clients can | |||
choose to transmit a specific set of options, pick particular | choose to transmit a specific set of options, pick particular | |||
encoding for these options, and transmit options in different orders. | encoding for these options, and transmit options in different orders. | |||
These choices can be use to fingerprint the client. | These choices can be use to fingerprint the client. | |||
The following sections provide guidance on the encoding of options. | The following sections provide guidance on the encoding of options | |||
However, this guidance alone may not be sufficient to prevent | and fields within the packets. However, this guidance alone may not | |||
fingerprinting from revealing information, such as the device type, | be sufficient to prevent fingerprinting from revealing information, | |||
vendor type or OS type and in some cases specific version, or from | such as the device type, vendor type or OS type and in some cases | |||
revealing whether the client is using the anonymity profile. | 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 | The client willing to protect its privacy SHOULD limit the subset of | |||
options sent in messages to the subset listed in the following | options sent in messages to the subset listed in the following | |||
sections. | sections. | |||
The client willing to protect its privacy SHOULD randomize options | The client willing to protect its privacy SHOULD randomize options | |||
order before sending any DHCPv4 message. If this random ordering | order before sending any DHCPv4 message. If this random ordering | |||
cannot be implemented, the client MAY arrange options by increasing | cannot be implemented, the client MAY arrange options by increasing | |||
order of option codes. | order of option codes. | |||
skipping to change at page 10, line 27 | skipping to change at page 10, line 36 | |||
regain the same IP address that was used in a previous connection. | regain the same IP address that was used in a previous connection. | |||
Doing so entails the risk of disclosing an IP address used by the | Doing so entails the risk of disclosing an IP address used by the | |||
client at a previous location, or with a different link-layer | client at a previous location, or with a different link-layer | |||
address. | 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 connecting to a network | |||
lease is still valid. In that state, the client that is concerned | remembers previously allocated address, i.e. is in the INIT-REBOOT | |||
with privacy SHOULD perform a complete four way handshake starting | state. In that state, the client that is concerned with privacy | |||
with DHCPDISCOVER to obtain a new address lease. If the client can | SHOULD perform a complete four way handshake starting 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.4. Client hardware address | 3.4. Client hardware address field | |||
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. | |||
skipping to change at page 11, line 47 | skipping to change at page 12, line 8 | |||
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. | |||
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.6. Parameter Request List | 3.6. Parameter Request List Option | |||
The Parameter Request List (PRL) option is defined in [RFC2132] with | The Parameter Request List (PRL) option is defined in [RFC2132] with | |||
option code 61. It list the parameters requested from the server by | option code 61. It list the parameters requested from the server by | |||
the client. Different implementations request different | the client. Different implementations request different | |||
parameters.[RFC2132] specifies that "the client MAY list the options | parameters.[RFC2132] specifies that "the client MAY list the options | |||
in order of preference." It practice, this means that different | in order of preference." It practice, this means that different | |||
client implementations will request different parameters, in | client implementations will request different parameters, in | |||
different orders. | different orders. | |||
The choice of option numbers and the specific ordering of option | The choice of option numbers and the specific ordering of option | |||
skipping to change at page 16, line 44 | skipping to change at page 17, line 11 | |||
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 link-layer 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.5. 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. Clients interested in privacy SHOULD request addresses using | |||
the requested DHCPv6 transactions, such as Identity Association for | the Identity Association for Non-temporary Addresses Option (IA_NA, | |||
Non-temporary Addresses Option (code 3) or Identity Association for | code 3). | |||
Temporary Addresses Option (code 4). | ||||
The IA_NA option includes an IAID parameter that identifies a unique | ||||
identity association for the interface for which the Address is | ||||
requested. Clients interested in protecting their privacy MUST | ||||
ensure that the IAID does not enable client identification. They | ||||
also need to conform to the requirement of [RFC3315] that the IAID | ||||
for that IA MUST be consistent across restarts of the DHCP client. | ||||
We interpret that as requiring that the IAID MUST be constant for the | ||||
association, as long as the link layer Address remains constant. | ||||
Clients MAY meet the privacy, uniqueness and stability requirement of | ||||
the IAID using by constructing it as the combination of one byte | ||||
encoding the interface number in the system, and three bytes of the | ||||
link layer address. | ||||
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 link-layer 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 link-layer address. | have been explicitly assigned through the current link-layer address. | |||
The interaction between prefix delegation and anonymity require | ||||
further study. For now, the simple solution is to avoid using prefix | ||||
delegation when striving for anonymity. When using the anonymity | ||||
profiles, clients SHOULD NOT use IA_PD, the prefix delegation form of | ||||
address assignment. | ||||
4.5.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, code 4) 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, this is not | there are a number of issues associated with it. First, this is not | |||
a widely used feature, so clients depending solely on temporary | a widely used feature, so clients depending solely on temporary | |||
addresses may lock themselves out of service. Secondly, [RFC3315] | addresses may lock themselves out of service. Secondly, [RFC3315] | |||
does not specify any lifetime or lease length for temporary | does not specify any lifetime or lease length for temporary | |||
addresses. Therefore support for renewing temporary addresses may | addresses. Therefore support for renewing temporary addresses may | |||
vary between client implementations, including not being supported at | vary between client implementations, including not being supported at | |||
all. Finally, by requesting temporary addresses a client reveals its | all. Finally, by requesting temporary addresses a client reveals its | |||
desire for privacy and potentially risks countermeasures as described | desire for privacy and potentially risks countermeasures as described | |||
in Section 2.5. | in Section 2.5. | |||
Clients interested in their privacy SHOULD NOT use IA_TA. They | Because of these Clients interested in their privacy SHOULD NOT use | |||
should simply send an IA_NA with a randomized IAID. This, along with | IA_TA. | |||
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 | ||||
long as needed. To get a new address, it can send Request message | ||||
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 | ||||
lease for the old IAID value. Once a new address is assigned, the | ||||
address obtained using the older IAID value can be released safely, | ||||
using the Release message or it may simply be allowed to time out. | ||||
This solution may not work if the server enforces specific policies, | The addresses obtained according to Section 4.5 are temporary in | |||
e.g. only one address per client. If client does not succeed in | nature, and will be discarded when the link layer address is changed. | |||
receiving a second address using a new IAID, it may release the first | They thus meet most of the use cases of the temporary addresses | |||
one (using the old IAID) and then retry asking for a new address. | defined in [RFC4941]. Clients interested in their privacy should not | |||
publish their IPv6 addresses in the DNS or otherwise associate them | ||||
with name services, and thus do not normally need two classes of | ||||
addresses, one public, one temporary. | ||||
From the Operating System perspective, addresses obtained using this | The use of mechanisms to allocate several IPv6 addresses to a client | |||
technique SHOULD be treated as temporary as specified in [RFC4941]. | while preserving privacy is for further study. | |||
4.5.2. Prefix delegation | ||||
The interaction between prefix delegation and anonymity require | ||||
further study. For now, the simple solution is to avoid using prefix | ||||
delegation when striving for anonymity. When using the anonymity | ||||
profiles, clients SHOULD NOT use IA_PD, the prefix delegation form of | ||||
address assignment. | ||||
4.6. Option Request Option | 4.6. Option Request Option | |||
The Option Request Option (ORO) is defined in [RFC3315] with option | The Option Request Option (ORO) is defined in [RFC3315] with option | |||
code 6. It specifies the options that the client is requesting from | code 6. It specifies the options that the client is requesting from | |||
the server. The choice of requested options and the order of | the server. The choice of requested options and the order of | |||
encoding of these options in the ORO can be used to fingerprint the | encoding of these options in the ORO can be used to fingerprint the | |||
client. | client. | |||
The client willing to protect its privacy SHOULD only request a | The client willing to protect its privacy SHOULD only request a | |||
skipping to change at page 21, line 9 | skipping to change at page 21, line 38 | |||
strict ordering. | strict ordering. | |||
7. Changed the requirement in Section 4.6 to allow "increasing order | 7. Changed the requirement in Section 4.6 to allow "increasing order | |||
of option codes" as an alternative to "randomized order of | of option codes" as an alternative to "randomized order of | |||
options". | options". | |||
8. In Section 4.5.1 revised the language stating lack of support for | 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 | renewing temporary addresses, as RFC 3315 does in fact specify a | |||
mechanism for doing so. | mechanism for doing so. | |||
Changes from draft-03 to draft-04 address comments received during | ||||
Working Group Last Call: | ||||
1. In Section 3, tightened the normative language and the use of | ||||
message codes. | ||||
2. In Section 3.3, clarified the reference to the INIT-REBOOT | ||||
scenario. | ||||
3. Revised the writing of Section 4.5 for greater clarity. | ||||
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. | |||
skipping to change at page 22, line 37 | skipping to change at page 23, line 32 | |||
[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-07 (work in progress), August | 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-07 (work | draft-ietf-6man-ipv6-address-generation-privacy-08 (work | |||
in progress), June 2015. | in progress), September 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 DHCPv4", draft-ietf-dhc-dhcp-privacy-01 | considerations for DHCPv4", draft-ietf-dhc-dhcp-privacy-01 | |||
(work in progress), August 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-01 (work in progress), August 2015. | dhcpv6-privacy-01 (work in progress), August 2015. | |||
End of changes. 34 change blocks. | ||||
83 lines changed or deleted | 114 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/ |