Skip to main content

Implications of Randomized Link Layers Addresses for IPv6 Address Assignment
draft-huitema-6man-random-addresses-01

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Author Christian Huitema
Last updated 2015-08-04
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-huitema-6man-random-addresses-01
Network Working Group                                         C. Huitema
Internet-Draft                                                 Microsoft
Updates: 7217, 4941 (if approved)                         August 4, 2015
Intended status: Standards Track
Expires: February 5, 2016

   Implications of Randomized Link Layers Addresses for IPv6 Address
                               Assignment
               draft-huitema-6man-random-addresses-01.txt

Abstract

   Hosts may assign random link-layer addresses to network interfaces in
   an attempt to increase privacy and reduce trackability.  Careless
   assignment of IPv6 addresses may negate the privacy advantages of
   random link-layer addresses.  We propose simple solutions to ensure
   that IPv6 addresses do change whenever the link layer addresses
   change.

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 February 5, 2016.

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

Huitema                 Expires February 5, 2016                [Page 1]
Internet-Draft    Random Link Layer and IPv6 Addresses       August 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
     1.1.  Requirements  . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Randomized link-layer addresses . . . . . . . . . . . . . . .   3
     2.1.  Randomized link-layer address format  . . . . . . . . . .   4
     2.2.  Link-layer address life time  . . . . . . . . . . . . . .   4
   3.  Privacy respecting opaque identifiers . . . . . . . . . . . .   4
     3.1.  Update to RFC 7217  . . . . . . . . . . . . . . . . . . .   5
   4.  Privacy compatible Temporary IIDs . . . . . . . . . . . . . .   6
     4.1.  Update to RFC 4941  . . . . . . . . . . . . . . . . . . .   6
   5.  Considerations on IPv6 address assignment . . . . . . . . . .   7
     5.1.  IEEE-identifier-based IIDs  . . . . . . . . . . . . . . .   7
     5.2.  Static, manually configured IIDs  . . . . . . . . . . . .   7
     5.3.  Constant, semantically opaque IIDs  . . . . . . . . . . .   8
     5.4.  DHCPv6 generation of IIDs . . . . . . . . . . . . . . . .   8
     5.5.  Transition/co-existence technologies  . . . . . . . . . .   8
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   8.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   8
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   The IPv6 Maintenance Working Group is in the process of approving a
   recommending the use of [RFC7217] for the construction of stable IPv6
   identifiers [I-D.ietf-6man-ipv6-address-generation-privacy].  The
   mechanism is designed to prevent address scanning or device
   identification through the use of "opaque" identifiers.  It prevents
   location tracking by making sure that the same device uses different
   identifiers at different locations.  However, a strict implementation
   of [RFC7217] results in stable identifiers, which remain always the
   same for a given device and a given location.  This is in fact a
   design goal of [RFC7217].

   Privacy conscious users will not agree with this design goal.
   Suppose for example users who don't want being tracked when they
   visit an public place at different times.  They will configure their
   device to use different link layer addresses on the different visits,
   using a form of MAC Address Randomization.  However, if their devices
   implement a strict version of [RFC7217], the IPv6 addresses will

Huitema                 Expires February 5, 2016                [Page 2]
Internet-Draft    Random Link Layer and IPv6 Addresses       August 2015

   contain stable identifiers.  The stable identifiers will re-enable
   the tracking that MAC Address Randomization would have prevented.

   Some systems also use temporary IPv6 addresses, as defined by
   [RFC4941].  These randomized addresses are defined by generating a
   randomized interface identifier at controlled intervals, and then
   using this identifier in conjunction with prefixes advertised by
   routers to construct addresses with limited life time.  Even with
   this short life time, the randomized interface identifier could
   remain constant while the link layer addresses changes with MAC
   Address Randomization.  This would enable tracking between successive
   network connections, even if the MAC Address changed.

   The purpose of this document is to recommend specific guidelines for
   the use of [RFC7217] and [RFC4941], in order to make it maintain the
   privacy benefits of MAC Address Randomization.  Section 2 presents
   the address randomization mechanisms.  Section 3 presents the
   guidelines for use of [RFC7217].  Section 4 presents the guidelines
   for use of [RFC4941].  Section 5 reviews the other address formats
   commonly used, and their interaction with MAC Address Randomization.

1.1.  Requirements

   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
   document, are to be interpreted as described in [RFC2119].

2.  Randomized link-layer addresses

   Mobile nodes can be tracked using multiple identifiers, the most
   prominent being the MAC addresses.  For example, when devices use Wi-
   Fi connectivity, they place the MAC address in the header of all the
   packets that they transmit.  Standard implementation of Wi-Fi use
   unique 48 bit MAC addresses, assigned to the devices according to
   procedures defined by IEEE 802.  Even when the Wi-Fi packets are
   encrypted, the portion of the header containing the addresses will be
   sent in clear text.  Tracking devices can "listen to the airwaves" to
   find out what devices are transmitting near them.

   The obvious solution is to "randomize" the MAC address.  Before
   connecting to a particular network, the device replaces the MAC
   address with a randomly drawn 48 bit value.  MAC address
   randomization was successfully tried at the IETF in Honolulu in
   November 2014 [IETFMACRandom].  However, we have to consider the
   linkage between MAC addresses and IPv6 addresses.

   From a privacy point of view, it is clear that MAC Addresses and IPv6
   addresses need to evolve in synchrony.  For example, if the MAC

Huitema                 Expires February 5, 2016                [Page 3]
Internet-Draft    Random Link Layer and IPv6 Addresses       August 2015

   address changes and the IID portion of the IPv6 address stays
   constant, then it is really easy to correlate old and new MAC
   address.  Conversely, if the IID changes but the MAC address remains
   constant, the old and new identifiers and addresses can be correlated
   by listening to the link's traffic.

2.1.  Randomized link-layer address format

   At the time of this writing, there is no standard way to construct
   randomized link layer addresses, but many implementations use the
   following algorithm for IEEE 802 48 bit MACs:

      Set the the "u" (universal/local) bit to 1 (local).

      Set the the "g" (individual/group) bit to 0 (individual).

      Pick random values for all the other bits.

2.2.  Link-layer address life time

   This document makes the hypothesis that randomized link layer
   addresses are chosen just prior to the connection to a link.  Hosts
   are expected to maintain the same link-layer address for the duration
   of the connection.

   There are circumstances where a host may decide to reset its link
   layer address while maintaining an attachment to a link.  For
   example, a host Ethernet interface may remain "plugged in" while the
   interface driver is reset to use a new MAC address.  These conditions
   will be considered equivalent to disconnecting and then reconnecting
   with a new link layer address.  The previously used IPv6 addresses
   will be discarded, and a new set of addreses will be assigned.

   There are circonstances where a host may decide to reconnect to a
   particular link using the same link-layer address as for a previous
   attachment.  In this case, the assignment algorithm will normally
   result in assigning the same IPv6 address as in the previous session,
   except under exceptional circumstances such as resetting the "secret
   key" used in [RFC7217].

3.  Privacy respecting opaque identifiers

   [RFC7217] specifies an algorithm that generates, for each network
   interface, a unique random IID per IPv6 link.  The privacy properties
   of that algorithm depends on the specific source of the "Net_Iface"
   parameter chosen by the implementer.

Huitema                 Expires February 5, 2016                [Page 4]
Internet-Draft    Random Link Layer and IPv6 Addresses       August 2015

   Most sources for the Net_IFace parameter listed in Appendix A of
   [RFC7217] will result in stable identifiers, independent of the link-
   layer address.  This will enable tracking over time of a host that
   repeatedly visits the same location, despite any attempts by the host
   to use different random link-layer address values.  In fact, the
   stable IIDs will enable correlation of different link-layer addresses
   to the same host identity.

   Tracking over time is mitigated if the Net_IFace parameter is set to
   the current link layer address.  In that case, the stable addresses
   will have exactly the same lifetime as the link-layer identifiers.
   This SHOULD be the default solution for hosts implementing MAC
   Address Randomization.

   Some hosts are static by nature.  This is for example the case of
   servers.  For such hosts, address stability is probably more
   important than preventing tracking over time.  Such hosts should
   probably not attempt to configure random link layer addresses.  They
   MAY want use a more stable sources for the Net_IFace than the link
   address programmed in the network interface card, as explained in
   [RFC7217].

3.1.  Update to RFC 7217

   Section 5 of [RFC7217], Net_Iface selection, is modified as follow:

      Replace "MUST" by "SHOULD" in the text:

      It SHOULD be constant across system bootstrap sequences and other
      network events (e.g., bringing another interface up or down).

      Immediately after that, add:

      It MAY change if the system administrator decides so explicitly,
      e.g. by implementing Link Layer Address Randomization.  This can
      be achieved by selecting the Current Link Layer Address for Net-
      Iface parameter.

   The following text is added to Appendix A, section A.3, Link-Layer
   Addresses:

      Link-Layer addresses will change dynamically in systems that
      implement Link Layer Address Randomization.  This will cause IIDs
      to change whenever the Link Address changes, which is very
      desirable for privacy.

Huitema                 Expires February 5, 2016                [Page 5]
Internet-Draft    Random Link Layer and IPv6 Addresses       August 2015

4.  Privacy compatible Temporary IIDs

   As stated in [I-D.ietf-6man-ipv6-address-generation-privacy], "a host
   that uses only a temporary address mitigates all four threats.  Its
   activities may only be correlated for the lifetime a single temporary
   address."  There is however a condition.  If the lifetime of the
   temporary address exceeds the lifetime of the random link layer
   address, then correlation of successive link-layer addresses become
   possible, effectively enabling a form of tracking.

   If a host uses both temporary and stable addresses, the privacy
   properties are those of the particular stable addresses.  This is
   also true is a host uses temporary addresses and configure but doen't
   use a stable address.  The address configuration will require
   performing duplicate address detection, generating at least a few
   packets on the local links.  Observing this packets, an on-link
   attacker can correlate the link-layer address with the stable
   address.  If the stable address includes a constant identifier, then
   the benefits of using random link-local addresses will be negated.

   This situation is anticipated somewhat in the specification of
   temporary addresses.  Section 3.5 of [RFC4941] specifies procedure
   for the regeneration of interface identifiers.  The last paragraph of
   that section specifies:

      ... when an interface connects to a new link, a new randomized
      interface identifier SHOULD be generated immediately together with
      a new set of temporary addresses.

   That condition is however not sufficient to cover the case of a
   device that re-connects to the same link with a new randomized link
   local addresses.

4.1.  Update to RFC 4941

   The word "Finally" should be removed from the last paragraph of
   section 3.5.

   The following text should be added at the end of section 3.5:

      Finally, when an interface is reconfigured to use a new link-layer
      address, a new randomized interface identifier SHOULD be generated
      immediately together with a new set of temporary addresses.  This
      reconfiguration ill happen for example as a consequence of MAC
      Address Randomization.

Huitema                 Expires February 5, 2016                [Page 6]
Internet-Draft    Random Link Layer and IPv6 Addresses       August 2015

5.  Considerations on IPv6 address assignment

   Several IPv6 address assignment methods have been defined over time.
   We review here these methods in light of link layer address
   randomization, using the same nomenclature as
   [I-D.ietf-6man-ipv6-address-generation-privacy].

5.1.  IEEE-identifier-based IIDs

   IEEE-identifier-based IIDs could be derived from randomized link
   layer ID, using the algorithm specified in Appendix A of [RFC4291].

   If the IIDs are constructed using the random link layer addresses,
   and if the random link layer addresses are constructed using the
   algorithm specified in Section 2.1, then the issues described in
   section 3 of [I-D.ietf-6man-ipv6-address-generation-privacy] are
   somewhat mitigated, but many concerns remain.  The correlation over
   time still be possible for the lifetime of the link layer address,
   and the location tracking will only be mitigated if link layer
   addresses do change with location.

   In addition to the lifetime and location tracking concerns, there is
   also a "scope" issue with IEEE-identifier-based IIDs.  The practice
   will export the link-layer address value to all places where the IPv6
   address is used.  This increase the potential "surface" for privacy
   attacks, and is not desirable.

   There is a small probability of collision between IIDs derived from
   random link layer addresses and IIDs obtained through the sematically
   opaque, cryptographically generated, or temporary assignment methods.
   The "u" bit is set to global for globally assigned link layer
   addresses, but set to "local" for both random link layer addresses
   and for IIDs derived through some random process.  The collision risk
   is however very small, and may not be a practical concern.

5.2.  Static, manually configured IIDs

   Because static, manually configured IIDs are stable, both correlation
   and location tracking are possible for the life of the address.
   Using randomized link-local addresses doesn't change that.

   In practice, static assignment and link-layer address randomization
   address different scenarios.  Static assignments are typically used
   for static hosts, while randomization is typically used for mobile
   hosts.

Huitema                 Expires February 5, 2016                [Page 7]
Internet-Draft    Random Link Layer and IPv6 Addresses       August 2015

5.3.  Constant, semantically opaque IIDs

   This address assignment method allows correlation and location
   tracking because the IID is constant across IPv6 links and time.
   Using randomized link-local addresses doesn't change that.  In fact,
   the constant values allow for correlation between the random link-
   local address and the host's identity, removing most of privacy value
   of random link-layer addresses.

   Section 4.3 of [I-D.ietf-6man-ipv6-address-generation-privacy]
   addresses the general case of systems generating constant IID using
   the algorithms specified in [RFC4941], mentioning the implementation
   of this algorithm in Windows.  Tests on the Windows platform show
   that the "constant" IIDs do in fact change if the link layer address
   is changed to a random value, and thus do in fact preserve the
   privacy value of random link-layer addresses.

5.4.  DHCPv6 generation of IIDs

   When using DHCPv6 in conjunction with random link layer addresses,
   implementers SHOULD follow the recommendations of
   [I-D.ietf-dhc-anonymity-profile].

5.5.  Transition/co-existence technologies

   Transition technologies typically embed an IPv4 address in a
   specifically formatted IPv6 address.  Tracking over time becomes
   possible if the IPv4 address has a longer lifetime than the random
   link-layer address.

   To mitigate the potential tracking issues with embedded IPv4
   addresses, hosts using random link-local addresses SHOULD implement
   the DHCPv4 profile specified in [I-D.ietf-dhc-anonymity-profile].

6.  Security Considerations

   This whole document concerns the privacy and security properties of
   different IPv6 address generation mechanisms.

7.  IANA Considerations

   This draft does not require any IANA action.

8.  Acknowledgments

   The inspiration for this draft came from the authors of
   [I-D.ietf-6man-ipv6-address-generation-privacy], Alissa Cooper,

Huitema                 Expires February 5, 2016                [Page 8]
Internet-Draft    Random Link Layer and IPv6 Addresses       August 2015

   Fernando Gont, and Dave Thaler.  Philip Homburg and other memebrs of
   the 6Man working group provided valuable comments.

9.  References

9.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>.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, DOI 10.17487/RFC4291, February
              2006, <http://www.rfc-editor.org/info/rfc4291>.

   [RFC4941]  Narten, T., Draves, R., and S. Krishnan, "Privacy
              Extensions for Stateless Address Autoconfiguration in
              IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
              <http://www.rfc-editor.org/info/rfc4941>.

   [RFC7217]  Gont, F., "A Method for Generating Semantically Opaque
              Interface Identifiers with IPv6 Stateless Address
              Autoconfiguration (SLAAC)", RFC 7217,
              DOI 10.17487/RFC7217, April 2014,
              <http://www.rfc-editor.org/info/rfc7217>.

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-07 (work
              in progress), June 2015.

   [I-D.ietf-dhc-anonymity-profile]
              Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity
              profile for DHCP clients", draft-ietf-dhc-anonymity-
              profile-01 (work in progress), June 2015.

   [IETFMACRandom]
              Zuniga, JC., "MAC Privacy", November 2014,
              <http://www.ietf.org/blog/2014/11/mac-privacy/>.

Huitema                 Expires February 5, 2016                [Page 9]
Internet-Draft    Random Link Layer and IPv6 Addresses       August 2015

Author's Address

   Christian Huitema
   Microsoft
   Redmond, WA  98052
   U.S.A.

   Email: huitema@microsoft.com

Huitema                 Expires February 5, 2016               [Page 10]