One document matched: draft-huitema-6man-random-addresses-03.xml

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [

<!ENTITY rfc2119 PUBLIC ''
   'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc4291 PUBLIC ''
   'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4291.xml'>
<!ENTITY rfc4941 PUBLIC ''
   'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4941.xml'>
<!ENTITY rfc7217 PUBLIC ''
   'http://xml.resource.org/public/rfc/bibxml/reference.RFC.7217.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-anonymity-profile 
SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-dhc-anonymity-profile.xml">

]>

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc compact="yes"?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>

<!-- Expand crefs and put them inline -->
<?rfc comments='yes' ?>
<?rfc inline='yes' ?>

<rfc category="std" 
     docName="draft-huitema-6man-random-addresses-03.txt" 
     ipr="trust200902">

<front>
    <title abbrev="Random Link Layer and IPv6 Addresses">
      Implications of Randomized Link Layers Addresses for IPv6 Address Assignment
    </title>

   <author fullname="Christian Huitema" initials="C." surname="Huitema">
      <organization>Microsoft</organization>
      <address>
        <postal>
          <street> </street>
          <city>Redmond</city>
          <code>98052</code>
          <region>WA</region>
          <country>U.S.A.</country>
        </postal>
        <email>huitema@microsoft.com</email>
      </address>
    </author>

    <date year="2016" />

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

<middle>
<section title="Introduction">
<t>
   The IPv6 Maintenance Working Group is reviewing the privacy properties of various
   IPv6 address generation mechanisms <xref target="I-D.ietf-6man-ipv6-address-generation-privacy" />.
   At the same time, this working group has proposed in <xref target="RFC7217" /> 
   a method for the construction of stable IPv6 identifiers. The
   method defined in <xref target="RFC7217" /> 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 <xref target="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 <xref target="RFC7217" />.
</t>
<t>
   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, as discussed in <xref target="macRandomSection"/>.  
   However, if their devices
   implement a strict version of <xref target="RFC7217" />, the IPv6 addresses will
   contain stable identifiers.  The stable identifiers will re-enable
   the tracking that MAC Address Randomization would have prevented.
</t>
<t>
   Some systems also use temporary IPv6 addresses, as defined by
   <xref target="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.
</t>
<t>
   The purpose of this document is to recommend specific guidelines for
   the use of <xref target="RFC7217" /> and <xref target="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 <xref target="RFC7217" />.  Section 4 presents the guidelines
   for use of <xref target="RFC4941" />.  Section 5 reviews the other address formats
   commonly used, and their interaction with MAC Address Randomization.
</t>
<section title="Requirements">
<t>
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 <xref target="RFC2119" />.
</t>
</section>
</section>

<section title="Randomized link-layer addresses" anchor="macRandomSection" >
<t>
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. 
</t>
<t>
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, and in several other lcation since that, as reported in <xref target="IETFMACRandom" />, and
is also studied in <xref target="IEEE802PRSG" />. MAC Address Randomization will defend against trackers that
just "listen to the airwaves," but tracking can be re-enabled if the trackers can obtain other device
identifiers. We are concerned here with the use of IPv6 addresses for such tracking.
</t>
<t>
From a privacy point of view, it is clear that MAC Addresses and IPv6 addresses and DHCP identifiers shall evolve in synchrony. 
For example, if the MAC 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. 
</t>

<section title="Randomized link-layer address format" anchor="macFormat" >
<t>
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:
</t>
<t>
<list style="number">
<t>
Set the the "u" (universal/local) bit to 1 (local).
</t>
<t>
Set the the "g" (individual/group) bit to 0 (individual).
</t>
<t>
Pick random values for all the other bits.
</t>
</list>
</t>
</section>

<section title="Link-layer address life time" >
<t>
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.  
</t>
<t>
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.
</t>
<t>
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
<xref target="RFC7217" />.
</t>
</section>

</section>

<section title="Privacy respecting opaque identifiers" >
<t>
<xref target="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" 
chosen by the implementer.
</t>
<t>
Most sources for the Net_IFace parameter listed in Appendix A of
<xref target="RFC7217" /> will result in stable identifiers, independent 
of the link-layer address. This is useful in some deployment cases. For example, 
if the network interface card of a server is swapped, the specified 
algorithm will ensure that the server's IPv6 address do not change.
However, applying the same algorithm for mobile devices
enable tracking over time of a device that 
repeatedly visits the same location, despite attempts by
the host to use different random link-layer address values. 
</t>
<t>
   Tracking over time is prevented 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.
   The IPv6 addresses will change whenever the link layer addresses
   change.  Hosts that return to the same network without changing their
   link layer addresses will reuse the same IPv6 address.  This SHOULD
   be the default solution for hosts implementing Link-layer Address
   Randomization.
</t>
<t>
   Of course, this behavior could violate the statement regarding the
   Net_Iface parameter selection in Section 5 of <xref target="RFC7217"/>:
</t>
<t>
<list>
<t>
      It MUST be constant across system bootstrap sequences and other
      network events (e.g., bringing another interface up or down).
</t>
</list>
</t>
<t>
   Although <xref target="RFC7217"/> isn't very specific about "other network events",
   it seems that it generally intends to not change for events like
   changing a link-layer address.  For example, there is a specific
   statement about servers in section 5:
</t>
<t>
<list>
<t>
      ... a server-oriented operating system might prefer Net_Iface
      identifiers that are attached to system slots/ports, such that
      replacement of a NIC does not result in an IPv6 address change.
</t>
</list>
</t>
<t>
   This is indeed a fine recommendation for static servers, for which
   <xref target="RFC7217"/> provides a reasonable tradeoff between stability and
   privacy.  But for mobile hosts, the tradeoff is a bit different.  We
   expect these mobile hosts to implement <xref target="RFC7217"/> as recommended by
   the IETF, but to also require more privacy than static servers.  It
   turns out that a minimal update to <xref target="RFC7217"/> would make it suitable
   for these mobile hosts.  The will keep the full benefits of stable
   opaque identifiers when the link-layer address is stable, and the
   expected privacy when the link-layer address is randomized.  This
   simple update is proposed in the next section.
</t>

<section title="Update to RFC 7217" >
<t>
   Section 5 of [RFC7217], Net_Iface selection, is modified as follow:
</t>
<t>
<list>
<t>
      Replace "MUST" by "SHOULD" in the text:
</t>
<t>
      It SHOULD be constant across system bootstrap sequences and other
      network events (e.g., bringing another interface up or down).
</t>
<t>
      Immediately after that, add:
</t>
<t>
      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.
</t>
</list>
</t>
<t>
   The following text is added to Appendix A, section A.3, Link-Layer
   Addresses:
</t>
<t>
<list>
<t>
      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.
</t>
</list>
</t>
</section>
</section>

<section title="Privacy compatible Temporary Addresses" >
<t>
As stated in <xref target="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 becomes possible,
effectively enabling a form of tracking.
</t>
<t>
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.
</t>
<t>
   This situation is anticipated somewhat in the specification of
   temporary addresses.  Section 3.5 of <xref target="RFC4941"/> specifies procedure
   for the regeneration of interface identifiers.  The last paragraph of
   that section specifies:
</t>
<t>
<list>
<t>
      ... 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.
</t>
</list>
</t>
<t>
   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.
</t>

<section title="Update to RFC 4941" >
<t>
   The word "Finally" should be removed from the last paragraph of
   section 3.5.
</t>
<t>
   The following text should be added at the end of section 3.5:
</t>
<t>
<list>
<t>
      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.  The
      previously assigned addresses SHOULD be marked as expired, not
      just deprecated.  This reconfiguration will happen for example as
      a consequence of link-layer address randomization.
</t>
</list>
</t>
</section>
</section>


<section title=" Other IPv6 Address Assigment methods">

<t>
The previous sections reviewed the use of stable addresses [RFC7217]
   and temporary addresses [RFC4941].  Several other 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].

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 
<xref target="I-D.ietf-6man-ipv6-address-generation-privacy" />.
</t>

<section title="IEEE-identifier-based IIDs" >
<t>
IEEE-identifier-based IIDs could be derived from randomized link layer ID, using the algorithm
specified in Appendix A of <xref target="RFC4291" />.
</t>
<t>
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 <xref target="macFormat" />, then the issues described in section 3
of <xref target="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.
</t>
<t>
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.
</t>
<t>
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.
</t>
</section>

<section title="Static, manually configured IIDs" >
<t>
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.
</t>
<t>
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.
</t>
</section>

<section title="Constant, semantically opaque IIDs" >
<t>
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.
</t>
<t>
Section 4.3 of <xref target="I-D.ietf-6man-ipv6-address-generation-privacy" /> 
addresses the general case of systems generating constant IID using 
the algorithms specified in <xref target="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.
</t>
</section>





<section title="DHCPv6 generation of IIDs" >
<t>
When using DHCPv6 in conjunction with random link layer addresses,
implementers SHOULD follow the recommendations of  
<xref target="I-D.ietf-dhc-anonymity-profile" />.
</t>
</section>

<section title="Transition/co-existence technologies" >
<t>
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.
</t>
<t>
To mitigate the potential tracking issues with embedded
IPv4 addresses, hosts using random link-local addresses
SHOULD implement the DHCPv4 profile specified in
<xref target="I-D.ietf-dhc-anonymity-profile" />.
</t>
</section>

</section>

<section title="Security Considerations">
<t> 
This whole document concerns the privacy and security properties of
   different IPv6 address generation mechanisms.
</t>
</section>

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

<section title="Acknowledgments">
    <t> 
The inspiration for this draft came from the authors of <xref target="I-D.ietf-6man-ipv6-address-generation-privacy"/>, 
Alissa Cooper, Fernando Gont, and Dave Thaler. Philip Homburg and other members of
   the 6Man working group provided valuable comments.
    </t>
</section>
</middle>

<back>
<references title="Normative References">
    &rfc2119;
    &rfc4291;
    &rfc4941;
    &rfc7217;
</references>

<references title="Informative References">
    &I-D.ietf-6man-ipv6-address-generation-privacy;
    &I-D.ietf-dhc-anonymity-profile;

    <reference anchor="IETFMACRandom" target="http://www.it.uc3m.es/cjbc/papers/pdf/2015_bernardos_cscn_privacy.pdf">
        <front>
            <title>Wi-Fi Internet connectivity and privacy: hiding your tracks on the wireless Internet</title>
            <author initials="CJ" surname="Bernardos" fullname="Carlos J. Bernardos" />
            <author initials="JC" surname="Zuniga" fullname="Juan Carlos Zuniga" />
            <author initials="P" surname="O'Hanlon" fullname="Piers O'Hanlon" />
            <date month="October" year="2015" />
        </front>
    </reference>

<reference anchor="IEEE802PRSG" target="http://www.ieee802.org/PrivRecsg/">
<front>
<title>
IEEE 802 EC Privacy Recommendation Study Group
</title>
<author>
<organization>IEEE 802 EC PRSG</organization>
</author>
<date month="Dec" year="2015" /> 
</front>
</reference>


</references>  

</back>
</rfc>