[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00                                                            
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


   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

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

2.  Terminology

   This document uses the term "Stable identifier" as defined in

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",
   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

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

   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

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

              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

              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, "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

   [RFC4649]  Volz, B., "Dynamic Host Configuration Protocol for IPv6
              (DHCPv6) Relay Agent Remote-ID Option", RFC 4649, August

   [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

   [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

   [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

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

   Email: tomasz.mrugalski@gmail.com

   Suresh Krishnan
   8400 Decarie Blvd.
   Town of Mount Royal, QC

   Phone: +1 514 345 7900 x42871
   Email: suresh.krishnan@ericsson.com

Mrugalski & Krishnan   Expires September 10, 2015               [Page 9]