draft-mrugalski-dhc-dhcpv6-privacy-mitigation.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc3315 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3315.xml">
<!ENTITY rfc3633 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3633.xml">
<!ENTITY rfc4580 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4580.xml">
<!ENTITY rfc4649 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4649.xml">
<!ENTITY rfc4704 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4704.xml">
<!ENTITY rfc4776 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4776.xml">
<!ENTITY rfc4941 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4941.xml">
<!ENTITY rfc6355 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6355.xml">
<!ENTITY rfc6939 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6939.xml">
<!ENTITY rfc6973 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6973.xml">
<!ENTITY I-D.ietf-6man-ipv6-address-generation-privacy SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-6man-ipv6-address-generation-privacy.xml">
<!ENTITY I-D.ietf-dhc-dhcpv6-privacy SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-dhc-dhcpv6-privacy.xml">

]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no"?>
<?rfc strict="yes"?>
<?rfc compact="yes"?>
<rfc category="std" docName="draft-mrugalski-dhc-dhcpv6-privacy-mitigation-00"
     updates="3315" ipr="trust200902">
  <front>
    <title abbrev="DHCPv6 Privacy Concerns Mitigation">Mitigation of Privacy
    Concerns in DHCPv6</title>

    <author fullname="Tomek Mrugalski" initials="T." surname="Mrugalski">
      <organization abbrev="ISC">Internet Systems Consortium,
      Inc.</organization>

      <address>
        <postal>
          <street>950 Charter Street</street>
          <city>Redwood City</city>
          <region>CA</region>
          <code>94063</code>
          <country>USA</country>
        </postal>
        <email>tomasz.mrugalski@gmail.com</email>
      </address>
    </author>

    <author fullname="Suresh Krishnan" initials="S." surname="Krishnan">
      <organization>Ericsson</organization>

      <address>
        <postal>
          <street>8400 Decarie Blvd.</street>
          <city>Town of Mount Royal</city>
          <region>QC</region>
          <country>Canada</country>
        </postal>
        <phone>+1 514 345 7900 x42871</phone>
        <email>suresh.krishnan@ericsson.com</email>
      </address>
    </author>

    <!--
    <author fullname="Sheng Jiang" initials="S." surname="Jiang">
      <organization>Huawei Technologies Co., Ltd</organization>
      <address>
        <postal>
          <street>Q14, Huawei Campus, No.156 BeiQing Road</street>
          <city>Hai-Dian District, Beijing</city>
          <region></region>
          <code>100095</code>
          <country>P.R. China</country>
        </postal>
        <email>jiangsheng@huawei.com</email>
      </address>
    </author> -->

    <!--
    <author fullname="Bernie Volz" initials="B" surname="Volz">
      <organization abbrev="Cisco">Cisco Systems, Inc.</organization>
      <address>
        <postal>
          <street>1414 Massachusetts Ave</street>
          <city>Boxborough, MA  01719</city>
          <region></region>
          <code></code>
          <country>USA</country>
        </postal>
        <email>volz@cisco.com</email>
      </address>
    </author> -->

    <!--
    <author fullname="Christian Huitema" initials="C" surname="Huitema">
      <organization>Microsoft</organization>
      <address>
        <email>huitema@microsoft.com</email>
      </address>
    </author> -->


    <date/>

    <area>Internet</area>
    <workgroup>dhc</workgroup>

    <abstract>
      <t>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.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="intro" title="Introduction">
      <t>DHCPv6 <xref target="RFC3315"></xref> 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. <xref
      target="I-D.ietf-dhc-dhcpv6-privacy" /> discusses the various
      identifiers used by DHCPv6 and the potential privacy issues
      <xref target="RFC6973"></xref>. This document proposes </t>

    </section>

    <section title="Terminology">
      <t>This document uses the term "Stable identifier" as defined in <xref
      target="I-D.ietf-dhc-dhcpv6-privacy" /></t>

      <t>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 <xref
      target="RFC2119"></xref>. 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 <xref target="RFC2119"></xref> key words.</t>
    </section>

    <section title="Client Mitigation Techniques">

      <section anchor="desire" title="Not disclose the desire for privacy">
	<t>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.</t>
      </section>

      <section anchor="random-duid" title="Use randomized DUIDs">
	<t>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.</t>
	<t>Discussion: As stated in <xref target="desire"/>, the
	desire for privacy should not be explicitly
	advertised. Therefore a new DUID type is not recommended
	here.</t>

	<t>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 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 <xref
	target="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.</t>
      </section>

      <section title="Do not send Confirm messages">
	<t>The <xref target="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.</t>

	<t>PROPOSAL: Clients interested in protecting their privacy
	SHOULD NOT send Confirm messages and instead directly try to
	acquire addresses on the new link.</t>
      </section>

      <section title="Obtain temporary addresses">
	<t><xref target="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, <xref target="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 <xref target="desire"/>.</t>

	<t>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
	<xref target="random-duid"/>, 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.</t>

	<t>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.</t>

	<t>From the Operating System perspective, addresses obtained
	using this technique SHOULD be treated as temporary as
	specified in <xref target="RFC4941" />.</t>
      </section>

      <section title="Do not request the FQDN Option">
	<t>A typical client uses FQDN option, defined in <xref
	target="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.</t>

	<t>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.</t>
      </section>

      <section title="Randomize ordering of Options in messages and in the ORO">
	<t>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 additional information,
	such as the device type, vendor type or OS type and in some cases
	specific version.</t>

	<t>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).</t>

	<t>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.</t>

	<!-- tomek: I also briefly thought about paranoid type of
	a client that could ask in ORO for other random options.
	That would be sort of fun, but may have adverse effects in the
	long term. There may be options defined in the future that
	could affect how DHCPv6 operates (e.g. client supporting
	feature X should request option Y.). So this has a potential
	for too much (random) breakage in the future. -->
      </section>

      <section title="Anonymous Information-Request">
	<t>According to <xref target="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.</t>

	<t>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.</t>
      </section>

    </section>


    <section title="Server Mitigation Techniques">
      <t>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;
      - </t>
    </section>

    <section anchor="security" title="Security Considerations">
      <t>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.</t>
    </section>

    <section anchor="privacy-consider" title="Privacy Considerations">
      <t>This document at its entirety discusses privacy considerations in
      DHCPv6. As such, no separate section about this is needed.</t>
    </section>

    <section title="IANA Considerations">
      <t>This draft does not request any IANA action.</t>
    </section>

    <section anchor="acks" title="Acknowledgements">
      <t>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.</t>

      <t>This document was produced using the xml2rfc tool <xref
      target="RFC2629"></xref>.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      &rfc2119;

      &rfc3315;

      &I-D.ietf-dhc-dhcpv6-privacy;

    </references>

    <references title="Informative References">
      &rfc3633;

      <?rfc include='reference.RFC.2629'?>

      &rfc4580;

      &rfc4649;

      &rfc4704;

      &rfc4776;

      &rfc4941;

      <?rfc include='reference.RFC.5007'?>

      <?rfc include='reference.RFC.5460'?>

      <?rfc include='reference.RFC.5970'?>

      <?rfc include='reference.RFC.6225'?>

      &rfc6355;

      &rfc6939;

      &rfc6973;

      &I-D.ietf-6man-ipv6-address-generation-privacy;

      <reference anchor="IEEE-OUI">
        <front>
          <title>Organizationally Unique Identifiers
          http://www.ieee.org/netstorage/standards/oui.txt</title>

          <author>
            <organization>IEEE</organization>
          </author>

          <date />
        </front>
      </reference>

    </references>
  </back>
</rfc>