draft-ietf-dhc-anonymity-profile-04.txt   draft-ietf-dhc-anonymity-profile-05.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: April 4, 2016 ISC Expires: July 16, 2016 ISC
S. Krishnan S. Krishnan
Ericsson Ericsson
October 2, 2015 January 13, 2016
Anonymity profile for DHCP clients Anonymity profile for DHCP clients
draft-ietf-dhc-anonymity-profile-04.txt draft-ietf-dhc-anonymity-profile-05.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.
draft updates RFC4361.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 4, 2016. This Internet-Draft will expire on July 16, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 35 skipping to change at page 2, line 34
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 field . . . . . . . . . . . . . . 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 Option . . . . . . . . . . . . . . 12 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 . . . . . . . 15 4.1. 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 . . . . . . . . . . . . . 16 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 . . . . . . . . . . . . . . . 17 4.5. Address assignment options . . . . . . . . . . . . . . . 17
4.5.1. Obtain temporary addresses . . . . . . . . . . . . . 17 4.5.1. Obtain temporary addresses . . . . . . . . . . . . . 17
4.5.2. Prefix delegation . . . . . . . . . . . . . . . . . . 18 4.5.2. Prefix delegation . . . . . . . . . . . . . . . . . . 18
4.6. Option Request Option . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . 19 4.7. Authentication Option . . . . . . . . . . . . . . . . . . 19
skipping to change at page 14, line 39 skipping to change at page 14, line 39
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 on The choice between the stateful and stateless scenarios 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 disclosures 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 send. 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. Option encoding and avoiding fingerprinting 4.1. Avoiding fingerprinting
There are many choices for implementing DHCPv6 messages. As There are many choices for implementing DHCPv6 messages. As
explained in Section 3.1, these choices can be use to fingerprint the explained in Section 3.1, these choices can be use to fingerprint the
client. 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 However, this guidance alone may not be sufficient to prevent
fingerprinting from revealing information, such as the device type, fingerprinting from revealing information, such as the device type,
vendor type or OS type and in some cases specific version, or from vendor type or OS type and in some cases specific version, or from
revealing whether the client is using the anonymity profile. revealing whether the client is using the anonymity profile.
skipping to change at page 17, line 22 skipping to change at page 17, line 22
the Identity Association for Non-temporary Addresses Option (IA_NA, the Identity Association for Non-temporary Addresses Option (IA_NA,
code 3). code 3).
The IA_NA option includes an IAID parameter that identifies a unique The IA_NA option includes an IAID parameter that identifies a unique
identity association for the interface for which the Address is identity association for the interface for which the Address is
requested. Clients interested in protecting their privacy MUST requested. Clients interested in protecting their privacy MUST
ensure that the IAID does not enable client identification. They ensure that the IAID does not enable client identification. They
also need to conform to the requirement of [RFC3315] that the IAID also need to conform to the requirement of [RFC3315] that the IAID
for that IA MUST be consistent across restarts of the DHCP client. 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 We interpret that as requiring that the IAID MUST be constant for the
association, as long as the link layer Address remains constant. association, as long as the link layer address remains constant.
Clients MAY meet the privacy, uniqueness and stability requirement of Clients MAY meet the privacy, uniqueness and stability requirement of
the IAID using by constructing it as the combination of one byte the IAID by constructing it as the combination of one byte encoding
encoding the interface number in the system, and three bytes of the the interface number in the system, and the first three bytes of the
link layer address. 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.
4.5.1. Obtain temporary addresses 4.5.1. Obtain temporary addresses
skipping to change at page 22, line 5 skipping to change at page 21, line 49
Working Group Last Call: Working Group Last Call:
1. In Section 3, tightened the normative language and the use of 1. In Section 3, tightened the normative language and the use of
message codes. message codes.
2. In Section 3.3, clarified the reference to the INIT-REBOOT 2. In Section 3.3, clarified the reference to the INIT-REBOOT
scenario. scenario.
3. Revised the writing of Section 4.5 for greater clarity. 3. Revised the writing of Section 4.5 for greater clarity.
Changes from draft-04 to draft-05 address comments received after
Working Group Last Call:
1. Changed the title of Section 4.1 to "Avoiding fingerprinting" to
align with Section 3.1.
2. Fixed editing nits in Section 4.5, and added specification that
the IAID is composed of the interface identifier and the first
three bytes of the HW address. This matches the implementation
in Windows 10, and insures that variations will not be used to
fingerprint the client software.
3. Dropping "This draft updates RFC4361" from the Abstract, since
this draft does not actually update RFC4361.
4. Pruned the list of normative references.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-dhc-rfc3315bis]
Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
Richardson, M., Jiang, S., and T. Lemon, "Dynamic Host
Configuration Protocol for IPv6 (DHCPv6) bis", draft-ietf-
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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", [RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 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
Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997,
<http://www.rfc-editor.org/info/rfc2132>.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration Protocol C., and M. Carney, "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
2003, <http://www.rfc-editor.org/info/rfc3315>. 2003, <http://www.rfc-editor.org/info/rfc3315>.
[RFC3925] Littlefield, J., "Vendor-Identifying Vendor Options for
Dynamic Host Configuration Protocol version 4 (DHCPv4)",
RFC 3925, DOI 10.17487/RFC3925, October 2004,
<http://www.rfc-editor.org/info/rfc3925>.
[RFC4361] Lemon, T. and B. Sommerfeld, "Node-specific Client
Identifiers for Dynamic Host Configuration Protocol
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, Domain Name (FQDN) Option", RFC 4702,
DOI 10.17487/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
IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN)
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,
DOI 10.17487/RFC4861, September 2007, DOI 10.17487/RFC4861, September 2007,
<http://www.rfc-editor.org/info/rfc4861>. <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, DOI 10.17487/RFC4941, September 2007, IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
<http://www.rfc-editor.org/info/rfc4941>. <http://www.rfc-editor.org/info/rfc4941>.
skipping to change at page 23, line 26 skipping to change at page 23, line 16
[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-07 (work in progress), August draft-ietf-6man-default-iids-08 (work in progress),
2015. October 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-08 (work draft-ietf-6man-ipv6-address-generation-privacy-08 (work
in progress), September 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-02
(work in progress), August 2015. (work in progress), December 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-02 (work in progress), December 2015.
[I-D.ietf-dhc-rfc3315bis]
Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
Richardson, M., Jiang, S., and T. Lemon, "Dynamic Host
Configuration Protocol for IPv6 (DHCPv6) bis", draft-ietf-
dhc-rfc3315bis-02 (work in progress), October 2015.
[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/>.
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997,
<http://www.rfc-editor.org/info/rfc2132>.
[RFC3925] Littlefield, J., "Vendor-Identifying Vendor Options for
Dynamic Host Configuration Protocol version 4 (DHCPv4)",
RFC 3925, DOI 10.17487/RFC3925, October 2004,
<http://www.rfc-editor.org/info/rfc3925>.
[RFC4361] Lemon, T. and B. Sommerfeld, "Node-specific Client
Identifiers for Dynamic Host Configuration Protocol
Version Four (DHCPv4)", RFC 4361, DOI 10.17487/RFC4361,
February 2006, <http://www.rfc-editor.org/info/rfc4361>.
[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, Preboot eXecution Environment (PXE)", RFC 4578,
DOI 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>.
[RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for
IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN)
Option", RFC 4704, DOI 10.17487/RFC4704, October 2006,
<http://www.rfc-editor.org/info/rfc4704>.
[RFC6355] Narten, T. and J. Johnson, "Definition of the UUID-Based [RFC6355] Narten, T. and J. Johnson, "Definition of the UUID-Based
DHCPv6 Unique Identifier (DUID-UUID)", RFC 6355, DHCPv6 Unique Identifier (DUID-UUID)", RFC 6355,
DOI 10.17487/RFC6355, August 2011, DOI 10.17487/RFC6355, August 2011,
<http://www.rfc-editor.org/info/rfc6355>. <http://www.rfc-editor.org/info/rfc6355>.
[RFC7618] Cui, Y., Sun, Q., Farrer, I., Lee, Y., Sun, Q., and M. [RFC7618] Cui, Y., Sun, Q., Farrer, I., Lee, Y., Sun, Q., and M.
Boucadair, "Dynamic Allocation of Shared IPv4 Addresses", Boucadair, "Dynamic Allocation of Shared IPv4 Addresses",
RFC 7618, DOI 10.17487/RFC7618, August 2015, RFC 7618, DOI 10.17487/RFC7618, August 2015,
<http://www.rfc-editor.org/info/rfc7618>. <http://www.rfc-editor.org/info/rfc7618>.
 End of changes. 21 change blocks. 
43 lines changed or deleted 59 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/