draft-ietf-dhc-dhcp-privacy-04.txt   draft-ietf-dhc-dhcp-privacy-05.txt 
dhc S. Jiang dhc S. Jiang
Internet-Draft Huawei Technologies Co., Ltd Internet-Draft Huawei Technologies Co., Ltd
Intended status: Informational S. Krishnan Intended status: Informational S. Krishnan
Expires: August 17, 2016 Ericsson Expires: August 24, 2016 Ericsson
T. Mrugalski T. Mrugalski
ISC ISC
February 14, 2016 February 21, 2016
Privacy considerations for DHCP Privacy considerations for DHCP
draft-ietf-dhc-dhcp-privacy-04 draft-ietf-dhc-dhcp-privacy-05
Abstract Abstract
DHCP is a protocol that is used to provide addressing and DHCP is a protocol that is used to provide addressing and
configuration information to IPv4 hosts. This document discusses the configuration information to IPv4 hosts. This document discusses the
various identifiers used by DHCP and the potential privacy issues. various identifiers used by DHCP and the potential privacy issues.
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
skipping to change at page 1, line 35 skipping to change at page 1, line 35
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 17, 2016. This Internet-Draft will expire on August 24, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 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
skipping to change at page 2, line 31 skipping to change at page 2, line 31
4. Existing Mechanisms That Affect Privacy . . . . . . . . . . . 7 4. Existing Mechanisms That Affect Privacy . . . . . . . . . . . 7
4.1. DNS Updates . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. DNS Updates . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Allocation strategies . . . . . . . . . . . . . . . . . . 7 4.2. Allocation strategies . . . . . . . . . . . . . . . . . . 7
5. Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Device type discovery . . . . . . . . . . . . . . . . . . 8 5.1. Device type discovery . . . . . . . . . . . . . . . . . . 8
5.2. Operating system discovery . . . . . . . . . . . . . . . 8 5.2. Operating system discovery . . . . . . . . . . . . . . . 8
5.3. Finding location information . . . . . . . . . . . . . . 9 5.3. Finding location information . . . . . . . . . . . . . . 9
5.4. Finding previously visited networks . . . . . . . . . . . 9 5.4. Finding previously visited networks . . . . . . . . . . . 9
5.5. Finding a stable identity . . . . . . . . . . . . . . . . 9 5.5. Finding a stable identity . . . . . . . . . . . . . . . . 9
5.6. Pervasive monitoring . . . . . . . . . . . . . . . . . . 9 5.6. Pervasive monitoring . . . . . . . . . . . . . . . . . . 9
5.7. Finding client's IP address or hostname . . . . . . . . . 9 5.7. Finding client's IP address or hostname . . . . . . . . . 10
5.8. Correlation of activities over time . . . . . . . . . . . 10 5.8. Correlation of activities over time . . . . . . . . . . . 10
5.9. Location tracking . . . . . . . . . . . . . . . . . . . . 10 5.9. Location tracking . . . . . . . . . . . . . . . . . . . . 10
5.10. Leasequery & bulk leasequery . . . . . . . . . . . . . . 10 5.10. Leasequery & bulk leasequery . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 11 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . 11 10.1. Normative References . . . . . . . . . . . . . . . . . . 11
10.2. Informative References . . . . . . . . . . . . . . . . . 12 10.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
Dynamic Host Configuration Protocol (DHCP) [RFC2131] is a protocol Dynamic Host Configuration Protocol (DHCP) [RFC2131] is a protocol
that is used to provide addressing and configuration information to that is used to provide addressing and configuration information to
IPv4 hosts. DHCP uses several identifiers that could become a source IPv4 hosts. DHCP uses several identifiers that could become a source
for gleaning information about the IPv4 host. This information may for gleaning information about the IPv4 host. This information may
include device type, operating system information, location(s) that include device type, operating system information, location(s) that
the device may have previously visited, etc. This document discusses the device may have previously visited, etc. This document discusses
the various identifiers used by DHCP and the potential privacy issues the various identifiers used by DHCP and the potential privacy issues
skipping to change at page 3, line 25 skipping to change at page 3, line 25
considered less important as they are typically open for public considered less important as they are typically open for public
services. And, it is generally assumed that relay agent to server services. And, it is generally assumed that relay agent to server
communication is protected from casual snooping, as that communication is protected from casual snooping, as that
communication occurs in the provider's backbone. Nevertheless, the communication occurs in the provider's backbone. Nevertheless, the
topics involving relay agents and servers are explored to some topics involving relay agents and servers are explored to some
degree. However, future work may want to further explore privacy of degree. However, future work may want to further explore privacy of
DHCP servers and relay agents. DHCP servers and relay agents.
2. Requirements Language and Terminology 2. Requirements Language and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", Naming convention from [RFC2131] and related is used throughout this
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document.
document are to be interpreted as described in [RFC2119]. When these
words are not in ALL CAPS (such as "should" or "Should"), they have
their usual English meanings, and are not to be interpreted as
[RFC2119] key words.
In addition the following terminology is used: In addition the following terminology is used:
Stable identifier - Any property disclosed by a DHCP client that Stable identifier - Any property disclosed by a DHCP client that
does not change over time or changes very infrequently and is does not change over time or changes very infrequently and is
unique for said client in a given context. Examples include unique for said client in a given context. Examples include
MAC address, client-id, and a hostname. Some identifiers may MAC address, client-id, and a hostname. Some identifiers may
be considered stable only under certain conditions, for be considered stable only under certain conditions, for
example one client implementation may keep its client-id example one client implementation may keep its client-id
stored in stable storage while another may generate it on the stored in stable storage while another may generate it on the
skipping to change at page 8, line 4 skipping to change at page 8, line 4
favored in deployments that prefer performance. However, it makes favored in deployments that prefer performance. However, it makes
the allocated addresses very predictable. Also, since the addresses the allocated addresses very predictable. Also, since the addresses
allocated tend to be clustered at the beginning of an available pool, allocated tend to be clustered at the beginning of an available pool,
it makes scanning attacks much easier. it makes scanning attacks much easier.
Identifier-based allocation - some server implementations may choose Identifier-based allocation - some server implementations may choose
to allocate an address that is based on one of the available to allocate an address that is based on one of the available
identifiers, e.g., client identifier or MAC address. It is also identifiers, e.g., client identifier or MAC address. It is also
convenient, as a returning client is very likely to get the same convenient, as a returning client is very likely to get the same
address. Those properties are convenient for system administrators, address. Those properties are convenient for system administrators,
so DHCP server implementors are often requested to implement it. The so DHCP server implementers are often requested to implement it. The
downside of such allocation is that the client has a very stable IP downside of such allocation is that the client has a very stable IP
address. That means that correlation of activities over time, address. That means that correlation of activities over time,
location tracking, address scanning and OS/vendor discovery apply. location tracking, address scanning and OS/vendor discovery apply.
This is certainly an issue in DHCPv6, but due to a much smaller This is certainly an issue in DHCPv6, but due to a much smaller
address space is almost never a problem in DHCP. address space is almost never a problem in DHCP.
Hash allocation - it's an extension of identifier-based allocation. Hash allocation - it's an extension of identifier-based allocation.
Instead of using the identifier directly, it is hashed first. If the Instead of using the identifier directly, it is hashed first. If the
hash is implemented correctly, it removes the flaw of disclosing the hash is implemented correctly, it removes the flaw of disclosing the
identifier, a property that eliminates susceptibility to address identifier, a property that eliminates susceptibility to address
skipping to change at page 9, line 37 skipping to change at page 9, line 37
An attacker might use a stable identity gleaned from DHCP messages to An attacker might use a stable identity gleaned from DHCP messages to
correlate activities of a given client on unrelated networks. The correlate activities of a given client on unrelated networks. The
Client FQDN option, the Subscriber ID option, and the Client ID Client FQDN option, the Subscriber ID option, and the Client ID
option can serve as long-lived identifiers of DHCP clients. The option can serve as long-lived identifiers of DHCP clients. The
Client FQDN option can also provide an identity that can easily be Client FQDN option can also provide an identity that can easily be
correlated with web server activity logs. correlated with web server activity logs.
5.6. Pervasive monitoring 5.6. Pervasive monitoring
This is an enhancement, or a combination of most of the Pervasive Monitoring [RFC7258] is widespread (and often covert)
aforementioned mechanisms. An operator who controls a non-trivial surveillance through intrusive gathering of protocol artefacts,
number of access points or network segments, may use obtained including application content, or protocol metadata such as headers.
information about a single client and observe the client's habits. An operator who controls a non-trivial number of access points or
Although users may not expect true privacy from their operators, the network segments, may use obtained information about a single client
information that is set up to be monitored by users' service and observe the client's habits. Although users may not expect true
operators may also be gathered by an adversary who monitors a wide privacy from their operators, the information that is set up to be
range of networks and develops correlations from that information. monitored by users' service operators may also be gathered by an
adversary who monitors a wide range of networks and develops
correlations from that information.
5.7. Finding client's IP address or hostname 5.7. Finding client's IP address or hostname
Many DHCP deployments use DNS Updates [RFC4702] that put a client's Many DHCP deployments use DNS Updates [RFC4702] that put a client's
information (current IP address, client's hostname) into the DNS, information (current IP address, client's hostname) into the DNS,
where it is easily accessible by anyone interested. Client ID is where it is easily accessible by anyone interested. Client ID is
also disclosed, albeit in not easily accessible form (SHA-256 digest also disclosed, albeit in not easily accessible form (SHA-256 digest
of the client-id). Although SHA-256 is considered irreversible, DHCP of the client-id). As SHA-256 is considered irreversible, DHCP
client ID can't be converted back to client-id. However, SHA-256 client ID can't be converted back to client-id. However, SHA-256
digest can be used as an unique identifier that is accessible by any digest can be used as an unique identifier that is accessible by any
host. host.
5.8. Correlation of activities over time 5.8. Correlation of activities over time
As with other identifiers, an IP address can be used to correlate the As with other identifiers, an IP address can be used to correlate the
activities of a host for at least as long as the lifetime of the activities of a host for at least as long as the lifetime of the
address. If that address was generated from some other, stable address. If that address was generated from some other, stable
identifier and that generation scheme can be deduced by an attacker, identifier and that generation scheme can be deduced by an attacker,
skipping to change at page 11, line 33 skipping to change at page 11, line 37
DHCP. As such, no dedicated discussion is needed. DHCP. As such, no dedicated discussion is needed.
8. IANA Considerations 8. IANA Considerations
This draft does not request any IANA action. This draft does not request any IANA action.
9. Acknowledgements 9. Acknowledgements
The authors would like to thank the valuable comments made by Stephen The authors would like to thank the valuable comments made by Stephen
Farrell, Ted Lemon, Ines Robles, Russ White, Christian Huitema, Farrell, Ted Lemon, Ines Robles, Russ White, Christian Huitema,
Bernie Volz, Jinmei Tatuya, Marcin Siodelski, Christian Schaefer, and Bernie Volz, Jinmei Tatuya, Marcin Siodelski, Christian Schaefer,
other members of DHC WG. Robert Sparks, Peter Yee, and other members of DHC WG.
This document was produced using the xml2rfc tool [RFC7749].
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", [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>.
[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)", "Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, DOI 10.17487/RFC2136, April 1997, RFC 2136, DOI 10.17487/RFC2136, April 1997,
<http://www.rfc-editor.org/info/rfc2136>. <http://www.rfc-editor.org/info/rfc2136>.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
skipping to change at page 13, line 43 skipping to change at page 13, line 48
[RFC6926] Kinnear, K., Stapp, M., Desetti, R., Joshi, B., Russell, [RFC6926] Kinnear, K., Stapp, M., Desetti, R., Joshi, B., Russell,
N., Kurapati, P., and B. Volz, "DHCPv4 Bulk Leasequery", N., Kurapati, P., and B. Volz, "DHCPv4 Bulk Leasequery",
RFC 6926, DOI 10.17487/RFC6926, April 2013, RFC 6926, DOI 10.17487/RFC6926, April 2013,
<http://www.rfc-editor.org/info/rfc6926>. <http://www.rfc-editor.org/info/rfc6926>.
[RFC7724] Kinnear, K., Stapp, M., Volz, B., and N. Russell, "Active [RFC7724] Kinnear, K., Stapp, M., Volz, B., and N. Russell, "Active
DHCPv4 Lease Query", RFC 7724, DOI 10.17487/RFC7724, DHCPv4 Lease Query", RFC 7724, DOI 10.17487/RFC7724,
December 2015, <http://www.rfc-editor.org/info/rfc7724>. December 2015, <http://www.rfc-editor.org/info/rfc7724>.
[RFC7749] Reschke, J., "The "xml2rfc" Version 2 Vocabulary",
RFC 7749, DOI 10.17487/RFC7749, February 2016,
<http://www.rfc-editor.org/info/rfc7749>.
Authors' Addresses Authors' Addresses
Sheng Jiang Sheng Jiang
Huawei Technologies Co., Ltd Huawei Technologies Co., Ltd
Q14, Huawei Campus, No.156 Beiqing Road Q14, Huawei Campus, No.156 Beiqing Road
Hai-Dian District, Beijing, 100095 Hai-Dian District, Beijing, 100095
P.R. China P.R. China
Email: jiangsheng@huawei.com Email: jiangsheng@huawei.com
Suresh Krishnan Suresh Krishnan
Ericsson Ericsson
8400 Decarie Blvd. 8400 Decarie Blvd.
Town of Mount Royal, QC Town of Mount Royal, QC
Canada Canada
Phone: +1 514 345 7900 x42871 Phone: +1 514 345 7900 x42871
Email: suresh.krishnan@ericsson.com Email: suresh.krishnan@ericsson.com
Tomek Mrugalski Tomek Mrugalski
 End of changes. 14 change blocks. 
29 lines changed or deleted 29 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/