draft-ietf-dhc-anonymity-profile-01.txt | draft-ietf-dhc-anonymity-profile-02.txt | |||
---|---|---|---|---|
Network Working Group C. Huitema | Network Working Group C. Huitema | |||
Internet-Draft Microsoft | Internet-Draft Microsoft | |||
Updates: 4361 (if approved) T. Mrugalski | Updates: 4361 (if approved) T. Mrugalski | |||
Intended status: Standards Track ISC | Intended status: Standards Track ISC | |||
Expires: January 1, 2016 S. Krishnan | Expires: February 21, 2016 S. Krishnan | |||
Ericsson | Ericsson | |||
June 30, 2015 | August 20, 2015 | |||
Anonymity profile for DHCP clients | Anonymity profile for DHCP clients | |||
draft-ietf-dhc-anonymity-profile-01.txt | draft-ietf-dhc-anonymity-profile-02.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 January 1, 2016. | This Internet-Draft will expire on February 21, 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 22 | skipping to change at page 2, line 22 | |||
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 . . . . . . . . . . . 8 | 2.7. What about privacy for DHCP servers . . . . . . . . . . . 7 | |||
3. Anonymity profile for DHCPv4 . . . . . . . . . . . . . . . . 8 | 3. Anonymity profile for DHCPv4 . . . . . . . . . . . . . . . . 8 | |||
3.1. Client IP address field . . . . . . . . . . . . . . . . . 9 | 3.1. Client IP address field . . . . . . . . . . . . . . . . . 9 | |||
3.2. Requested IP address option . . . . . . . . . . . . . . . 9 | 3.2. Requested IP address option . . . . . . . . . . . . . . . 9 | |||
3.3. Client hardware address . . . . . . . . . . . . . . . . . 9 | 3.3. Client hardware address . . . . . . . . . . . . . . . . . 10 | |||
3.4. Client Identifier Option . . . . . . . . . . . . . . . . 10 | 3.4. Client Identifier Option . . . . . . . . . . . . . . . . 10 | |||
3.5. Host Name Option . . . . . . . . . . . . . . . . . . . . 11 | 3.5. Host Name Option . . . . . . . . . . . . . . . . . . . . 11 | |||
3.6. Client FQDN Option . . . . . . . . . . . . . . . . . . . 11 | 3.6. Client FQDN Option . . . . . . . . . . . . . . . . . . . 12 | |||
3.7. UUID/GUID-based Client Identifier Option . . . . . . . . 12 | 3.7. UUID/GUID-based Client Identifier Option . . . . . . . . 12 | |||
3.8. User and Vendor Class DHCP options . . . . . . . . . . . 12 | 3.8. User and Vendor Class DHCP options . . . . . . . . . . . 13 | |||
4. Anonymity profile for DHCPv6 . . . . . . . . . . . . . . . . 12 | 4. Anonymity profile for DHCPv6 . . . . . . . . . . . . . . . . 13 | |||
4.1. Do not send Confirm messages, unless really sure where . 13 | 4.1. Do not send Confirm messages, unless really sure where . 14 | |||
4.2. Client Identifier DHCPv6 Option . . . . . . . . . . . . . 13 | 4.2. Client Identifier DHCPv6 Option . . . . . . . . . . . . . 14 | |||
4.2.1. Anonymous Information-Request . . . . . . . . . . . . 14 | 4.2.1. Anonymous Information-Request . . . . . . . . . . . . 15 | |||
4.3. Server Identifier Option . . . . . . . . . . . . . . . . 14 | 4.3. Server Identifier Option . . . . . . . . . . . . . . . . 15 | |||
4.4. Address assignment options . . . . . . . . . . . . . . . 15 | 4.4. Address assignment options . . . . . . . . . . . . . . . 15 | |||
4.4.1. Obtain temporary addresses . . . . . . . . . . . . . 15 | 4.4.1. Obtain temporary addresses . . . . . . . . . . . . . 16 | |||
4.5. Option Request Option . . . . . . . . . . . . . . . . . . 16 | 4.5. Option Request Option . . . . . . . . . . . . . . . . . . 16 | |||
4.5.1. Previous option values . . . . . . . . . . . . . . . 16 | 4.5.1. Previous option values . . . . . . . . . . . . . . . 17 | |||
4.6. Authentication Option . . . . . . . . . . . . . . . . . . 16 | 4.6. Authentication Option . . . . . . . . . . . . . . . . . . 17 | |||
4.7. User and Vendor Class DHCPv6 options . . . . . . . . . . 17 | 4.7. User and Vendor Class DHCPv6 options . . . . . . . . . . 17 | |||
4.8. Client FQDN Option . . . . . . . . . . . . . . . . . . . 17 | 4.8. Client FQDN Option . . . . . . . . . . . . . . . . . . . 17 | |||
5. Operational Considerations . . . . . . . . . . . . . . . . . 17 | 5. Operational Considerations . . . . . . . . . . . . . . . . . 18 | |||
6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 | |||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 | |||
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 | 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 | |||
9. Changes from previous versions . . . . . . . . . . . . . . . 18 | 9. Changes from previous versions . . . . . . . . . . . . . . . 18 | |||
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 | |||
10.1. Normative References . . . . . . . . . . . . . . . . . . 18 | 10.1. Normative References . . . . . . . . . . . . . . . . . . 19 | |||
10.2. Informative References . . . . . . . . . . . . . . . . . 19 | 10.2. Informative References . . . . . . . . . . . . . . . . . 20 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 | |||
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 8, line 34 | skipping to change at page 8, line 29 | |||
[I-D.ietf-dhc-dhcp-privacy] and [I-D.ietf-dhc-dhcpv6-privacy]. | [I-D.ietf-dhc-dhcp-privacy] and [I-D.ietf-dhc-dhcpv6-privacy]. | |||
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, Host name, and Parameter Request List | Type, Client Identifier, and Parameter Request List options. It | |||
options. It SHOULD NOT contain any other option. | SHOULD NOT contain any other option. | |||
REQUEST: The anonymized REQUEST messages SHOULD contain the Message | REQUEST: The anonymized REQUEST messages SHOULD contain the Message | |||
Type, Client Identifier, Host name, and Parameter Request List | Type, Client Identifier, Requested IP address and Parameter | |||
options. If the message is in response to an OFFER, it SHOULD | Request List options. If the message is in response to an OFFER, | |||
contain the corresponding Server Identifier option. It SHOULD NOT | it SHOULD contain the corresponding Server Identifier option. It | |||
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, Host name, and Parameter Request List options. | Type, Client Id, and Parameter Request List options. It SHOULD | |||
It SHOULD NOT contain any other option. | 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 | ||||
INFORM messages is discussed in Section 3.5 and Section 3.6. | ||||
3.1. Client IP address field | 3.1. 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 | |||
skipping to change at page 9, line 47 | skipping to change at page 10, line 5 | |||
convenience, an attempt to regain the same IP address that was used | convenience, an attempt to regain the same IP address that was used | |||
in a previous connection. Doing so entails the risk of disclosing an | in a previous connection. Doing so entails the risk of disclosing an | |||
IP address used by the client at a previous location, or with a | IP address used by the client at a previous location, or with a | |||
different MAC Address. | different MAC 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 | ||||
lease is still valid. In that state, the client that is concerned | ||||
with privacy 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 | ||||
previously connected, and if the link layer address did not change, | ||||
the client MAY issue a DHCPREQUEST to try reclaim the current | ||||
address. | ||||
3.3. Client hardware address | 3.3. 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 | |||
skipping to change at page 10, line 47 | skipping to change at page 11, line 20 | |||
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.5. 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. | |||
skipping to change at page 11, line 24 | skipping to change at page 12, line 5 | |||
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 | |||
information on the identity of the device. They are typically chosen | information on the identity of the device. They are typically chosen | |||
to be unique in the context where the device is most often used. If | to be unique in the context where the device is most often used. If | |||
that context is wide enough, in a large company or in a big | that context is wide enough, in a large company or in a big | |||
university, the host name will be a pretty good identifier of the | university, the host name will be a pretty good identifier of the | |||
device. Monitoring services could use that information in | device. Monitoring services could use that information in | |||
conjunction with traffic analysis and quickly derive the identity of | conjunction with traffic analysis and quickly derive the identity of | |||
the device's owner. | the device's owner. | |||
When using the anonymity profile, DHCP clients SHOULD avoid sending | When using the anonymity profile, DHCP clients SHOULD NOT send the | |||
the host name option. If they chose to send the option, DHCP clients | host name option. If they chose to send the option, DHCP clients | |||
MUST always send a non-qualified host name instead of a fully | MUST always send a non-qualified host name instead of a fully | |||
qualified domain name, and MUST obfuscate the host name value. | qualified domain name, and MUST obfuscate the host name value. | |||
When obfuscating the host name, DHCP clients SHOULD construct a | There are many ways to obfuscate a host name. The construction rules | |||
randomized host name by computing a secure hash of a local secret and | SOULD guarantee that a different host name is generated each time the | |||
of the link layer address that will be used in the underlying | link-layer address changes and that the obfuscated host name will not | |||
connection, and then use as the name the hexadecimal representation | reveal the underlying link layer address. The construction SHOULD | |||
of the first 6 bytes of the hash. This procedure ensures that the | generate names that are unique enough to minimize collisions in the | |||
random name will not reveal the underlying link layer address. | local link. Clients MAY use the following algorithm: compute a | |||
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 | ||||
representation of the first 6 bytes of the hash as the obfuscated | ||||
host name. | ||||
There is a potential downside to having a specific name pattern for | ||||
hosts that require anonymity, as explained in Section 2.5. For this | ||||
reason, the above algorithm is just a suggestion. | ||||
3.6. Client FQDN Option | 3.6. 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. | |||
skipping to change at page 15, line 31 | skipping to change at page 16, line 15 | |||
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.4.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, this is not | there are a number of issues associated with it. First of all, this | |||
widely used feature, so clients depending solely on temporary | is not widely used feature. Thus clients cannot count on it to be | |||
addresses may lock themselves out of service. Secondly, [RFC3315] | always available. Secondly, [RFC3315] does not specify any renewal | |||
does not specify any renewal mechanisms for temporary addresses. | mechanisms for temporary addresses. Therefore the support for | |||
Therefore support for renewing temporary addresses may vary between | renewing temporary addresses in server implementations usually varies | |||
server implementations, including not being supported at all. | between poor and non-existent. Finally, a client reveals its desire | |||
Finally, by requesting temporary addresses a client reveals its | for privacy just by requesting temporary addresses, and potentially | |||
desire for privacy and potentially risks countermeasures as described | risks countermeasures as described in Section 2.5. | |||
in Section 2.5. | ||||
Clients interested in their privacy SHOULD NOT use IA_TA. They | Clients interested in their privacy SHOULD NOT use the 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.3, 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 other one. This will | with a new randomized IAID before releasing the older 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, | address obtained using the older IAID value can be released safely or | |||
using the Release message or it may simply be allowed to time out. | be allowed to time out. | |||
This solution may not work if the server enforces specific policies, | ||||
e.g. only one address per client. If client does not succeed in | ||||
receiving a second address using a new IAID, it may release the first | ||||
one (using an old IAID) and then retry asking for a new address. | ||||
From the Operating System perspective, addresses obtained using this | From the Operating System perspective, addresses obtained using this | |||
technique SHOULD be treated as temporary as specified in [RFC4941]. | technique SHOULD be treated as temporary addresses as specified in | |||
[RFC4941]. | ||||
Note that this solution may not work if the server enforces specific | ||||
policies such as providing only one address per client. If client | ||||
does not succeed in obtaining a second address using a new IAID, it | ||||
needs to release the first one (using an old IAID) and then retry | ||||
asking for a new address. | ||||
4.5. Option Request Option | 4.5. Option Request Option | |||
A DHCPv6 client may reveal other types of information, besides unique | A DHCPv6 client may reveal other types of information, besides unique | |||
identifiers. There are many ways a DHCPv6 client can perform certain | identifiers. There are many ways a DHCPv6 client can perform certain | |||
actions and the specifics can be used to fingerprint the client. | actions and the specifics can be used to fingerprint the client. | |||
This may not reveal the identity of a client, but may provide | This may not reveal the identity of a client, but may provide | |||
additional information, such as the device type, vendor type or OS | additional information, such as the device type, vendor type or OS | |||
type and in some cases specific version. | type and in some cases specific version. | |||
skipping to change at page 17, line 28 | skipping to change at page 18, line 11 | |||
the client. As explained in Section 3.6 they MAY use a local-only | the client. As explained in Section 3.6 they MAY use a local-only | |||
FQDN by combining a host name derived from the link layer address and | FQDN by combining a host name derived from the link layer address and | |||
a suffix advertised by the local DHCP server. | 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. Implementers should be careful to only use the anonymity | address. | |||
profile when privacy trumps management considerations. | ||||
Clients using the anonymity profile in general consume more | Clients using the anonymity profile may be consuming more resources. | |||
resources. For example when they change MAC address and request for | For example when they change MAC address and request for a new IP, | |||
a new IP, the old one is still marked as leased by the server. | the old one is still marked as leased by the server. | |||
Implementers SHOULD provide a way for clients to control when the | ||||
anonymity profile is used, and when standard behavior is preferred. | ||||
Implementers MAY implement this control by tying use of the anonymity | ||||
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. | |||
skipping to change at page 18, line 31 | skipping to change at page 19, line 17 | |||
when roaming between access points on the same network. | when roaming between access points on the same network. | |||
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-00 (work in progress), March 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, March 1997. | |||
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC | [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC | |||
2131, March 1997. | 2131, DOI 10.17487/RFC2131, March 1997, | |||
<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, March 1997. | Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, | |||
<http://www.rfc-editor.org/info/rfc2132>. | ||||
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., | [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., | |||
and M. Carney, "Dynamic Host Configuration Protocol for | and M. Carney, "Dynamic Host Configuration Protocol for | |||
IPv6 (DHCPv6)", RFC 3315, July 2003. | IPv6 (DHCPv6)", RFC 3315, July 2003. | |||
[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, October 2004. | RFC 3925, DOI 10.17487/RFC3925, October 2004, | |||
<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, February 2006. | Version Four (DHCPv4)", RFC 4361, DOI 10.17487/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, October 2006. | Domain Name (FQDN) Option", RFC 4702, DOI 10.17487/ | |||
RFC4702, October 2006, | ||||
<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, October 2006. | |||
[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. | September 2007. | |||
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy | [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy | |||
skipping to change at page 19, line 32 | skipping to change at page 20, line 24 | |||
[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-04 (work in progress), June | draft-ietf-6man-default-iids-05 (work in progress), July | |||
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-03 (work | |||
in progress), June 2015. | in progress), January 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 DHCP", draft-ietf-dhc-dhcp-privacy-00 | |||
(work in progress), February 2015. | (work in progress), February 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-00 (work in progress), February 2015. | |||
skipping to change at page 20, line 20 | skipping to change at page 21, line 9 | |||
[IEEE-OUI] | [IEEE-OUI] | |||
IEEE, "Organizationally Unique Identifiers | IEEE, "Organizationally Unique Identifiers | |||
http://www.ieee.org/netstorage/standards/oui.txt", | http://www.ieee.org/netstorage/standards/oui.txt", | |||
<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, "Dynamic Host Configuration | [RFC4578] Johnston, M. and S. Venaas, Ed., "Dynamic Host | |||
Protocol (DHCP) Options for the Intel Preboot eXecution | Configuration Protocol (DHCP) Options for the Intel | |||
Environment (PXE)", RFC 4578, November 2006. | Preboot eXecution Environment (PXE)", RFC 4578, DOI | |||
10.17487/RFC4578, November 2006, | ||||
<http://www.rfc-editor.org/info/rfc4578>. | ||||
[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, | September 2008, <http://www.winlab.rutgers.edu/~gruteser/ | |||
<http://www.winlab.rutgers.edu/~gruteser/papers/ | papers/brik_paradis.pdf>. | |||
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. 38 change blocks. | ||||
79 lines changed or deleted | 118 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/ |