Internet DRAFT - draft-mrugalski-dhc-dhcpv6-privacy-mitigation
draft-mrugalski-dhc-dhcpv6-privacy-mitigation
dhc T. Mrugalski
Internet-Draft ISC
Updates: 3315 (if approved) S. Krishnan
Intended status: Standards Track Ericsson
Expires: September 10, 2015 March 9, 2015
Mitigation of Privacy Concerns in DHCPv6
draft-mrugalski-dhc-dhcpv6-privacy-mitigation-00
Abstract
There is work ongoing in the dhc working group that discusses the
various identifiers used by DHCPv6 and the potential privacy
implications. This draft explores several migitation techniques that
could be used to address the privacy issues in DHCPv6. This draft is
expected to evolve significantly over time, but the ultimate goal is
to standardize mitigation techniques the DHC working group considers
useful.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 10, 2015.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Mrugalski & Krishnan Expires September 10, 2015 [Page 1]
Internet-Draft DHCPv6 Privacy Concerns Mitigation March 2015
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Client Mitigation Techniques . . . . . . . . . . . . . . . . 3
3.1. Not disclose the desire for privacy . . . . . . . . . . . 3
3.2. Use randomized DUIDs . . . . . . . . . . . . . . . . . . 3
3.3. Do not send Confirm messages . . . . . . . . . . . . . . 4
3.4. Obtain temporary addresses . . . . . . . . . . . . . . . 4
3.5. Do not request the FQDN Option . . . . . . . . . . . . . 5
3.6. Randomize ordering of Options in messages and in the ORO 5
3.7. Anonymous Information-Request . . . . . . . . . . . . . . 6
4. Server Mitigation Techniques . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
9.1. Normative References . . . . . . . . . . . . . . . . . . 7
9.2. Informative References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
DHCPv6 [RFC3315] is a protocol that is used to provide addressing and
configuration information to IPv6 hosts. The DHCPv6 protocol uses
several identifiers that could become a source for gleaning
additional information about the IPv6 host. This information may
include device type, operating system information, location(s) that
the device may have previously visited, etc.
[I-D.ietf-dhc-dhcpv6-privacy] discusses the various identifiers used
by DHCPv6 and the potential privacy issues [RFC6973]. This document
proposes
2. Terminology
This document uses the term "Stable identifier" as defined in
[I-D.ietf-dhc-dhcpv6-privacy]
Mrugalski & Krishnan Expires September 10, 2015 [Page 2]
Internet-Draft DHCPv6 Privacy Concerns Mitigation March 2015
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
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.
3. Client Mitigation Techniques
3.1. Not disclose the desire for privacy
A naive approach to privacy would be to simply disclose the desire to
protect one's privacy, e.g. by sending requests for temporary
addresses or defining a new type of temporary DUID that would be
changing over time. This is not workable in a large number of cases
as it is possible that the network operator (or other entities that
have access to the operator's network) might be actively
participating in surveillance and anti-privacy, willingly or not.
Simply revealing the desire for privacy, could cause the attacker to
react by triggering additional surveillance or monitoring mechanisms.
Therefore we feel that it is preferable to not disclose one's desire
for privacy. This preference leads to some important implications.
In particular, we make an effort to make the mitigation techniques
difficult to distinguish from regular client behaviors, if at all
possible.
3.2. Use randomized DUIDs
One of the primary privacy concerns is that a client is disclosing a
stable identifier (the DUID) that can be use for tracking and
profiling. The most common way of disclosing client's MAC/hardware
address in DHCPv6 is to use DUID type LLT (link-layer with time) or
LL (link-layer). Another DUID of type UUID is also bad in this
regard, as its the UUID may contain additional information about the
device it is tied to.
Discussion: As stated in Section 3.1, the desire for privacy should
not be explicitly advertised. Therefore a new DUID type is not
recommended here.
PROPOSAL: The clients that want to protect their privacy SHOULD
generate a new randomized DUID-LLT every time they attach to a new
link or detect a possible link change event. The exact details are
left up to implementors, but there are several factors should be
taken into consideration. The DUID type SHOULD be set to 1 (DUID-
LLT). Hardware type SHOULD be set appropriately to the hardware
type. Time MAY be set to current time, but this will reveal the fact
that the DUID is newly generated. Implementors interested in hiding
Mrugalski & Krishnan Expires September 10, 2015 [Page 3]
Internet-Draft DHCPv6 Privacy Concerns Mitigation March 2015
this fact MAY use a time stamp from the past. e.g. a random timestamp
from the previous year could be a good value. In the most common
cases the link-layer address is based on MAC. The first three octets
are composed of the OUI (Organizationally Unique Identifier) that is
expected to have a value assigned to a real organization. See
[IEEE-OUI] for currently assigned values. Using a value that is
unassigned may disclose the fact that a DUID is randomized. Using a
value that belongs to a third party may have legal implications.
3.3. Do not send Confirm messages
The [RFC3315] requires clients to send a Confirm message when they
attach to a new link to verify whether the addressing and
configuration information they previously received is still valid.
When these clients send Confirm messages, they include any IAs
assigned to the interface that may have moved to a new link, along
with the addresses associated with those IAs. By examining the
addresses in the Confirm message an attacker can trivially identify
the previous point(s) of attachment.
PROPOSAL: Clients interested in protecting their privacy SHOULD NOT
send Confirm messages and instead directly try to acquire addresses
on the new link.
3.4. Obtain temporary addresses
[RFC3315] defines a special container (IA_TA) for requesting
temporary addresses. This is a good mechanism in principle, but
there are a number of issues associated with it. First, this is not
widely used feature, so clients depending solely on temporary
addresses may lock themselves out of service. Secondly, [RFC3315]
does not specify any renewal mechanisms for temporary addresses.
Therefore support for renewing temporary addresses may vary between
server implementations, including not being supported at all.
Finally, by requesting temporary addresses a client reveals its
desire for privacy and potentially risks countermeasures as described
in Section 3.1.
Mrugalski & Krishnan Expires September 10, 2015 [Page 4]
Internet-Draft DHCPv6 Privacy Concerns Mitigation March 2015
PROPOSAL: Clients interested in their privacy SHOULD not use IA_TA.
They should simply send an IA_NA with a randomized IAID. This, along
with the mitigation technique discussed in Section 3.2, 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 proposal 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
technique SHOULD be treated as temporary as specified in [RFC4941].
3.5. Do not request the FQDN Option
A typical client uses FQDN option, defined in [RFC4704] to negotiate
with a server the DNS entries that should be updated. In the
process, the client typically reveals its hostname and possibly its
home domain. Server, depending on configured policies, may accept or
override the name with network specific information.
PROPOSAL: Clients SHOULD avoid disclosing their hostnames, as the
hostnames may contain personally identifying information (e.g.
"Tomek's laptop"). Even if the hostname does not contain personally
identifying information, it can still be used as a stable identifier
for tracking. Therefore a client SHOULD not send FQDN option at all.
This ensures that the host does not expose a stable identifier, but
also implies that the host will not have a resolvable DNS name.
Should DNS name be useful, a client SHOULD send a randomly generated
hostname, consisting of a single label. The server is expected to
append the domain name and return FQDN to the client. Client can
then use this FQDN as its temporary hostname that will be discarded
once its location changes or the client chooses to assume a new
identity.
3.6. Randomize ordering of Options in messages and in the ORO
A DHCPv6 client may reveal other types of information, besides unique
identifiers. There are many ways a DHCPv6 client can perform certain
actions and the specifics can be used to fingerprint the client.
This may not reveal the identity of a client, but may provide
Mrugalski & Krishnan Expires September 10, 2015 [Page 5]
Internet-Draft DHCPv6 Privacy Concerns Mitigation March 2015
additional information, such as the device type, vendor type or OS
type and in some cases specific version.
One specific method used for fingerprinting utilizes the order in
which options are included in the message. Another related technique
utilizes the order in which option codes are included in an ORO
(Option Request Option).
PROPOSAL: The client willing to protect its privacy SHOULD randomize
options order before sending any DHCPv6 message. Such a client
SHOULD also randomly shuffle the option codes order in ORO.
3.7. Anonymous Information-Request
According to [RFC3315], a DHCPv6 client typically includes its client
identifier in most of the messages it sends. There is one exception,
however. Client is allowed to omit its client identifier when
sending Information-Request.
PROPOSAL: When using stateless DHCPv6, clients wanting to protect
their privacy SHOULD not include client identifiers in their
Information-Request messages. This will prevent the server from
specifying client-specific options if it is configured to do so, but
the need for anonymity precludes such options anyway.
4. Server Mitigation Techniques
TODO: - don't send GEOLOCATION options to anyone who asks (preferably
don't sent that option at all); - if running on mobile device,
possibly change its server-id when its link flips; - don't send FQDN
options if you don't intend to do actual DNS Updates; -
5. Security Considerations
The use of randomized DUIDs and IAIDs allows malicious clients to
exhaust address and prefix pools on DHCPv6 servers by simply
requesting more and more addresses/prefixes. This attack is
certainly possible already in today's networks, but this document
provides a *legitimate* use case for random DUIDs and IAIDs making
countermeasures more difficult. In addition to exhausting configured
address and prefix pools, these clients may also cause increased
state (and hence resource utilization) on the DHCPv6 servers.
Mrugalski & Krishnan Expires September 10, 2015 [Page 6]
Internet-Draft DHCPv6 Privacy Concerns Mitigation March 2015
6. Privacy Considerations
This document at its entirety discusses privacy considerations in
DHCPv6. As such, no separate section about this is needed.
7. IANA Considerations
This draft does not request any IANA action.
8. Acknowledgements
The authors would like to thanks the valuable comments made by
Stephen Farrell, Ted Lemon, Ines Robles, Russ White, Christian
Schaefer and other members of DHC WG.
This document was produced using the xml2rfc tool [RFC2629].
9. References
9.1. Normative References
[I-D.ietf-dhc-dhcpv6-privacy]
Krishnan, S., Mrugalski, T., and S. Jiang, "Privacy
considerations for DHCPv6", draft-ietf-dhc-
dhcpv6-privacy-00 (work in progress), February 2015.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
9.2. Informative References
[I-D.ietf-6man-ipv6-address-generation-privacy]
Cooper, A., Gont, F., and D. Thaler, "Privacy
Considerations for IPv6 Address Generation Mechanisms",
draft-ietf-6man-ipv6-address-generation-privacy-03 (work
in progress), January 2015.
[IEEE-OUI]
IEEE, "Organizationally Unique Identifiers
http://www.ieee.org/netstorage/standards/oui.txt", .
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999.
Mrugalski & Krishnan Expires September 10, 2015 [Page 7]
Internet-Draft DHCPv6 Privacy Concerns Mitigation March 2015
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003.
[RFC4580] Volz, B., "Dynamic Host Configuration Protocol for IPv6
(DHCPv6) Relay Agent Subscriber-ID Option", RFC 4580, June
2006.
[RFC4649] Volz, B., "Dynamic Host Configuration Protocol for IPv6
(DHCPv6) Relay Agent Remote-ID Option", RFC 4649, August
2006.
[RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for
IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN)
Option", RFC 4704, October 2006.
[RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol
(DHCPv4 and DHCPv6) Option for Civic Addresses
Configuration Information", RFC 4776, November 2006.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, September 2007.
[RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng,
"DHCPv6 Leasequery", RFC 5007, September 2007.
[RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, February
2009.
[RFC5970] Huth, T., Freimann, J., Zimmer, V., and D. Thaler, "DHCPv6
Options for Network Boot", RFC 5970, September 2010.
[RFC6225] Polk, J., Linsner, M., Thomson, M., and B. Aboba, "Dynamic
Host Configuration Protocol Options for Coordinate-Based
Location Configuration Information", RFC 6225, July 2011.
[RFC6355] Narten, T. and J. Johnson, "Definition of the UUID-Based
DHCPv6 Unique Identifier (DUID-UUID)", RFC 6355, August
2011.
[RFC6939] Halwasia, G., Bhandari, S., and W. Dec, "Client Link-Layer
Address Option in DHCPv6", RFC 6939, May 2013.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973, July
2013.
Mrugalski & Krishnan Expires September 10, 2015 [Page 8]
Internet-Draft DHCPv6 Privacy Concerns Mitigation March 2015
Authors' Addresses
Tomek Mrugalski
Internet Systems Consortium, Inc.
950 Charter Street
Redwood City, CA 94063
USA
Email: tomasz.mrugalski@gmail.com
Suresh Krishnan
Ericsson
8400 Decarie Blvd.
Town of Mount Royal, QC
Canada
Phone: +1 514 345 7900 x42871
Email: suresh.krishnan@ericsson.com
Mrugalski & Krishnan Expires September 10, 2015 [Page 9]
