Internet DRAFT - draft-herbert-ipv6-prefix-address-privacy

draft-herbert-ipv6-prefix-address-privacy



 



INTERNET-DRAFT                                                T. Herbert
Intended Status: Informational                                Quantonium
Expires: August 2018                                                    
                                                                        
                                                                        
                                                       February 20, 2018


               Privacy in IPv6 Network Prefix Assignment
              draft-herbert-ipv6-prefix-address-privacy-00


Abstract

   This document discusses privacy concerns around network prefix
   assignment in IPv6. It evaluates the privacy threat, proposes a set
   of ideal criteria for strong privacy, and suggests solutions to
   achieve a high degree of privacy in addressing.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html


Copyright and License Notice

   Copyright (c) 2018 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
 


T. Herbert              Expires August 24, 2018                 [Page 1]

INTERNET DRAFTdraft-herbert-ipv6-prefix-address-privacy-00February 20, 2018


   (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
   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  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2  The privacy concern . . . . . . . . . . . . . . . . . . . . . .  3
   3  Prior work  . . . . . . . . . . . . . . . . . . . . . . . . . .  4
     3.1 SLAAC and DHCPv6-PD  . . . . . . . . . . . . . . . . . . . .  4
     3.2 Privacy addresses  . . . . . . . . . . . . . . . . . . . . .  4
     3.3 Privacy in IPv6 address generation mechanisms  . . . . . . .  5
     3.4 Host address availability recommendations  . . . . . . . . .  6
     3.5 IPWAVE . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
   4  Practical effects . . . . . . . . . . . . . . . . . . . . . . .  7
     4.1  Mobile networks . . . . . . . . . . . . . . . . . . . . . .  7
     4.2  Connected cars  . . . . . . . . . . . . . . . . . . . . . .  7
     4.3  Privacy implications of NAT . . . . . . . . . . . . . . . .  8
     4.4  Exploit to defeat prefix rotation . . . . . . . . . . . . .  8
   5  Criteria for strong privacy . . . . . . . . . . . . . . . . . .  9
   6  Identifier/locator split solution . . . . . . . . . . . . . . . 10
     6.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     6.2 Scaling identifier/locator address assignment  . . . . . . . 11
       6.2.1 Scaling the amount of mapping state  . . . . . . . . . . 11
         6.2.1.1 Hybrid address assignment  . . . . . . . . . . . . . 11
         6.2.1.2 Hidden aggregation . . . . . . . . . . . . . . . . . 11
       6.2.2 Scaling bulk address assignment  . . . . . . . . . . . . 12
         6.2.2.1 Bulk assignment using DHCPv6 . . . . . . . . . . . . 12
         6.2.2.2 Hidden aggregation assignment  . . . . . . . . . . . 13
       6.2.3 Practicality of hidden aggregation methods . . . . . . . 13
     6.3 Law enforcement considerations . . . . . . . . . . . . . . . 14
   7  Security considerations . . . . . . . . . . . . . . . . . . . . 15
   8  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     8.1  Normative References  . . . . . . . . . . . . . . . . . . . 16
     8.2  Informative References  . . . . . . . . . . . . . . . . . . 16
   9  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 17
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17






 


T. Herbert              Expires August 24, 2018                 [Page 2]

INTERNET DRAFTdraft-herbert-ipv6-prefix-address-privacy-00February 20, 2018


1  Introduction

   This document discusses privacy of network prefix assignment in IPv6.

   A common address assignment method is for a network to assign
   prefixes to devices. SLAAC and DHCP-PD are two mechanisms for doing
   this. In the common case of a /64 assignment (as in SLAAC) the device
   generates IIDs (interface identifiers) to create individual addresses
   within an assigned prefix. While significant effort has gone into IID
   generation techniques to protect privacy ([RFC4941], [RFC7721]), the
   privacy aspects of the prefix itself have not been fully examined.

   This document is focused on privacy within the network layer and
   specifically with privacy in addressing. There are many other privacy
   issues that arise from persistent identifiers used in higher (and
   lower) protocol layers (MAC address, session IDs, certificates,
   etc.). Discussion of these are out of scope for this document,
   however it is clear that to achieve a level of privacy that users
   deserve all layers will need to be considered. 

2  The privacy concern

   In the original IPv6 addressing model, subnets (links) were assigned
   a sixty-four bit prefix [RFC4291]. Hosts in the subnet would then
   generate IIDs that are combined with the subnet prefix to create IPv6
   addresses. This model was subsequently extended to assign network
   prefixes, such as /64s, to general purpose hosts ([RFC3314],
   [RFC7934]).

   When a prefix is assigned to an end host, the prefix becomes an
   identifier for the host. So, if two such addresses have the same
   prefix (i.e. same upper sixty-four bits) then they can be assumed to
   refer to the same host. The IID portion of the addresses (lower
   sixty-four bits) are immaterial in this inference, so IID generation
   techniques don't affect the ability to make correlations.

   The fact that two addresses can be correlated to be from the same
   host implies the privacy concern. If an attacker knows that a network
   provider assigns /64 prefixes to end hosts, as is common in mobile
   networks, then it can deduce that two addresses in the provider
   prefix sharing the same sixty-four bit prefix refer to the same host.
   This correlation can be made between addresses of different flows
   independently of IIDs in those addresses. Furthermore, with a little
   more information (see Section 4.3), an attacker may not only deduce
   two addresses refer to the same end host, but also may be able to
   discover the identities of individuals in communications.


 


T. Herbert              Expires August 24, 2018                 [Page 3]

INTERNET DRAFTdraft-herbert-ipv6-prefix-address-privacy-00February 20, 2018


3  Prior work

   Several RFCs describe prefix assignment mechanisms and the privacy
   and security considerations for them.

3.1 SLAAC and DHCPv6-PD

   SLAAC [RFC4862] and DHCPv6-PD [RFC3633] are mechanisms to assign
   network prefixes to devices. Their respective specifications do not
   address privacy issues of prefix assignment. Security considerations
   are focused on the mechanisms.

3.2 Privacy addresses

   [RFC4941] addresses issues with persistent identifiers in IPv6. It
   describes the risks of extended use of the same identifier, and
   recommends using random interface identifiers and changing addresses
   periodically to deter inferences to reveal identify, location, or
   other privacy sensitive attributes of parties in communication.
   Addresses created by following RFC4941 recommendations are often
   called "privacy addresses".

   RFC4941 is mostly concerned with privacy and security aspects of IID
   generation. It mentions the problem of privacy of network prefixes in
   passing:

       Although it might appear that changing an address regularly in
       such environments would be desirable to lessen privacy concerns,
       it should be noted that the network prefix portion of an address
       also serves as a constant identifier.  All nodes at, say, a home,
       would have the same network prefix, which identifies the
       topological location of those nodes. This has implications for
       privacy, though not at the same granularity as the concern that
       this document addresses. Specifically, all nodes within a home
       could be grouped together for the purposes of collecting
       information.  If the network contains a very small number of
       nodes, say, just one, changing just the interface identifier will
       not enhance privacy at all, since the prefix serves as a constant
       identifier.

   Nevertheless, it's reasonable that some of the recommendations could
   be extrapolated to apply to prefix assignment for providing privacy.
   For instance, RFC4941 suggests to periodically do address rotation by
   generating a new IID. Conceivably, a node could periodically request
   a new network prefix via SLAAC. The new prefix would be randomized so
   that no correlation can be drawn between it and the old prefix.


 


T. Herbert              Expires August 24, 2018                 [Page 4]

INTERNET DRAFTdraft-herbert-ipv6-prefix-address-privacy-00February 20, 2018


   As for the frequency of changing addresses, RFC4941 states:

       having large numbers of clients change their address on a daily
       or weekly basis is likely to be sufficient to alleviate most
       privacy concerns.

   The statement is neither normative nor quantified. Intuitively, one
   might assume that a higher frequency of address rotation reduces the
   probability of privacy being compromised. However, other than the
   case where a different address is used for each flow (see below),
   there is no known way to quantify the relationship between frequency
   of changing addresses and privacy provided to users.

   A second concern with recommendations of RFC4941 is that it is was
   written eleven years ago. The sophistication and capabilities of
   attackers have increased substantially, so recommendations, such as
   changing addresses on a daily or weekly basis, may no longer be
   sufficient even if they were eleven years ago.

   Presumably, one could try to achieve a high degree of privacy by
   changing addresses at a high frequency (every few seconds for
   instance). The effect on privacy is still unquantifiable, however
   there is another problem in the disruption caused by changing
   addresses. An address change would require termination of existing
   flows, so a high frequency of address rotation would constantly
   thrash connections. A potential mitigation would be to allow a host
   to retain network prefixes for which it's still using for flows;
   however, managing that would be cumbersome and likely wouldn't scale
   since hosts could accumulate many prefixes over time.

   The postulated exploit described in Section 4.4 would defeat the
   privacy protection of any frequency of address rotation except for
   the case where a different address is used per flow.

3.3 Privacy in IPv6 address generation mechanisms

   [RFC7721] mainly focuses on security and privacy considerations for
   IID generation. The concern around privacy in network prefix
   assignment is raised: 

       As [RFC4941] notes, if a very small number of nodes (say, only
       one) use a particular prefix for an extended period of time, the
       prefix itself can be used to correlate the host's activities
       regardless of how the IID is generated.  For example, [RFC3314]
       recommends that prefixes be uniquely assigned to mobile handsets
       where IPv6 is used within General Packet Radio Service (GPRS). 
       In cases where this advice is followed and prefixes persist for
       extended periods of time (or get reassigned to the same handsets
 


T. Herbert              Expires August 24, 2018                 [Page 5]

INTERNET DRAFTdraft-herbert-ipv6-prefix-address-privacy-00February 20, 2018


       whenever those handsets reconnect to the same network router),
       hosts' activities could be correlatable for longer periods than
       the analysis below would suggest.

   RFC7721 does not suggest any requirements or guidelines for privacy
   in network prefixes. Similar to RFC4941, RFC7721 frames the problem
   with an unquantified description as using a prefix for "extended
   periods of time".

   Note that RFC7721 points out that mobile handsets are often assigned
   a single prefix. In this case, there is one to one relationship
   between a prefix and device. For a personal device, such as a smart
   phone or tablet, there would then be a one to one relationship
   between a prefix and an individual user.

3.4 Host address availability recommendations

   [RFC7934] recommends that general-purpose hosts are assigned multiple
   globally IPv6 addresses when they attach. RFC7934 advocates prefix
   assignment and /64 assignment with SLAAC in particular.

   RFC7934 includes a section on host tracking (Section 9.1 of RFC7934),
   however this section focuses on facilitating tracking of hosts in
   provider networks to satisfy legal requirements.

   From RFC7934:

     Using SLAAC with a dedicated /64 prefix for each host simplifies
     tracking, as it does not require logging every address formed by
     the host

   RFC7934 references RFC4941, but does not otherwise address issues
   with privacy in prefix assignment.

3.5 IPWAVE

   [IPWAVE] provides the problem statement for IPWAVE. The issue of
   address tracking is raised in the Security Considerations section.
   From the draft:

       To prevent an adversary from tracking a vehicle by with its MAC
       address or IPv6 address, each vehicle should periodically update
       its MAC address and the corresponding IPv6 address as suggested
       in [RFC4086][RFC4941].  Such an update of the MAC and IPv6
       addresses should not interrupt the communications between a
       vehicle and an RSU.

   As in the RFCs cited above, the draft suggests that addresses should
 


T. Herbert              Expires August 24, 2018                 [Page 6]

INTERNET DRAFTdraft-herbert-ipv6-prefix-address-privacy-00February 20, 2018


   be changed periodically, however there is no guidance as to what an
   acceptable frequency of change is to prevent tracking. It is
   noteworthy that address change is expected to not interrupt
   communications.

4  Practical effects

   This section discusses the current characteristics and effects on
   privacy in network prefix assignment to hosts.

4.1  Mobile networks

   Privacy in prefix addressing is of particular concern in mobile
   networks. It is often the case that UEs (devices such as smart
   phones) are assigned a unique /64 prefix that is not shared with
   other devices. As pointed out by RFC4941 and RFC7721, these network
   prefixes allow the device to be tracked through correlations. For
   personal devices, such as smart phones or tablets, correlations on IP
   addresses could be used to infer user identities in communication.
   The correlation to a user may require additional information that
   might be relatively easy to acquire as demonstrated by the exploit
   described in section 4.4.

   Most mobile providers follow the advice of [RFC3314] and assign
   single a /64 to each device. They may implement a method to force a
   device to periodically request a new /64 assignment.

   A sample implementation in a mobile network could assign a /64 prefix
   to each IPv6 PDN, and the same prefix is retained for Idle to Active
   to Idle transitions for the duration of the PDN session. If the UE is
   idle without transmitting/receiving any packets, the PDN session is
   dropped when the Idle Timer expires (e.g. 2 hours) and the prefix
   allocation is released. So in this case the minimum amount of time
   between addresses change is 2 hrs., but a device could keep its
   prefix allocation indefinitely as long as the device remains active.

4.2  Connected cars

   Connected cars are projected to become ubiquitous over the next
   decade. By some estimates there will be 381 million connected cars on
   the road by 2020, and by 2025 all new cars manufactured will be
   connected. Today many vehicles are already connected to the Internet
   via 4G LTE, and in the future they will connect using 5G, WiFi, DSRC
   or other radio technologies. In-vehicle networks connect sensors,
   displays, navigation, entertainment, as well as personal devices
   being used by passengers. 

   Privacy in such a network is potentially a more difficult problem
 


T. Herbert              Expires August 24, 2018                 [Page 7]

INTERNET DRAFTdraft-herbert-ipv6-prefix-address-privacy-00February 20, 2018


   since there are two independent parties that are involved in address
   assignment. The vehicle as a mobile node must be assigned addresses
   by the mobile network, and in turn the vehicle delegates addresses to
   devices attached to the vehicle network.

   A /64 prefix could be assigned to vehicles which is a common mobile
   network assignment. Devices attached to the vehicle network are
   delegated IPv6 address within the prefix assigned to the vehicle.
   This results in all the attached devices sharing fate with respect to
   privacy. For instance, if an attacker is able to determine the
   location of just one device with an assigned prefix, then it can
   infer the location of all devices that share the same prefix. If
   identity of a user can be separately surmised, this raises the
   prospect that location of individuals can be tracked.

   Periodically changing prefixes in this environment is problematic. As
   described in Section 3.2, a prefix change is potentially disruptive
   to communications as this results in an address change for each
   attached device. In the case of a vehicle network, the attached
   devices and applications they are running may be very heterogeneous
   such that their response and recovery for an address change may vary
   significantly. For instance, a laptop might attach to a vehicle
   network. A laptop is not normally considered a "mobile device" like a
   smart phone and many applications they might run don't assume
   addresses constantly change. Periodically changing addresses for
   privacy benefit may wreak havoc on such applications.  

4.3  Privacy implications of NAT

   Network Address Translation (NAT) is a method of remapping one IP
   address space into another by modifying addresses in the IP header of
   packets while they are in transit across a routing node. NAT has been
   extensively deployed to allow hosts that are assigned IPv4 private
   addresses [RFC1918] to communicate with hosts in the global Internet.
   NAT has been used to extend the usefulness of IPv4 in the face of
   address depletion.

   A side effect of NAT (possibly accidental) is that NAT modifies
   addresses such that it obfuscates the identity of the source host
   behind a NAT. With a significant population of users sharing a pool
   of NAT addresses, an external observer can draw little correlation
   based on addresses between flows that have gone through a NAT device.
   The result is that NAT provides strong privacy in addressing. NAT use
   is of particular concern to law enforcement since its privacy
   characteristics complicate criminal investigation [EUROPOL].

4.4  Exploit to defeat prefix rotation

 


T. Herbert              Expires August 24, 2018                 [Page 8]

INTERNET DRAFTdraft-herbert-ipv6-prefix-address-privacy-00February 20, 2018


   As mentioned in a Section 3.2, one might try to provide privacy in
   addressing by changing addresses with a high frequency. The following
   exploit is postulated as a way to defeat the privacy goals of
   periodic address rotation at any frequency except when a different
   address is used for each connection.

   The exploit is:

      o An attacker creates an "always connected" app that provides some
        seemingly benign service and users download the app.

      o The app includes some sort of persistent identity. For instance,
        this could be an account login.

      o The backend server for the app logs the identity and IP address
        of a user each time they connect.

      o When an address change happens, existing connections on the user
        device are disconnected. The app will receive a notification and
        immediately attempt to reconnect using the new source address.

      o The backend server will see the new connection and log the new
        IP address as being associated to the user. Thus, the server has
        a real-time record of users and the IP address they are using.

      o The attacker intercepts packets at some point in the Internet.
        The addresses in the captured packets can be time correlated
        with the server database to deduce identities of parties in
        communications that are unrelated to the app.

5  Criteria for strong privacy

   A set of "ideal" criteria for strong privacy in addressing can be
   established. These criteria are intended to be specific, such that
   when applied to a solution the amount of information that can be
   inferred by correlating addresses is quantifiable.

   The ideal criteria for IPv6 addresses that provide strong privacy
   are:

      o Addresses are composed of a global routing prefix and a suffix
        that is internal to an organization or provider. This is the
        same property for IP addresses [RFC4291].

      o The registry and organization of an address can be determined by
        the network prefix. This is true for any global address. The
        organizational bits in the address should have minimal hierarchy
        to prevent inference. It might be reasonable to have an internal
 


T. Herbert              Expires August 24, 2018                 [Page 9]

INTERNET DRAFTdraft-herbert-ipv6-prefix-address-privacy-00February 20, 2018


        prefix that divides identifiers based on broad geographic
        regions, but detailed information such as location, department
        in an enterprise, or device type should not be encoded in a
        globally visible address.

      o Given two addresses and no other information, the desired
        properties of correlating them are:

        o It can be inferred if they belong to the same organization and
          registry. This is true for any two global IP addresses.

        o It may be inferred that they belong to the same broad
          grouping, such as a geographic region, if the information is
          encoded in the organizational bits of the address.

        o No other correlation can be established. It cannot be inferred
          that the IP addresses address the same node, the addressed
          nodes reside in the same subnet, rack, or department, or that
          the nodes for the two addresses have any geographic proximity
          to one another.

   Note that if NAT is deployed with a sufficiently large population of
   users sharing a pool of IP addresses then these criteria are met.
   Thus NAT can be considered a baseline for strong privacy in
   addressing.

6  Identifier/locator split solution

   This section proposes using identifier/locator split to meet the
   strong privacy criteria for addressing in IPv6.

6.1 Overview

   Identifier/locator split separates the notions of location and
   identity in IP addresses. Identifier addresses are addresses that
   don't contain topological information for routing within a network.
   Nodes are assigned identifier addresses that can be used as endpoints
   in communications. Locator addresses indicate the topological
   location of a logical node. In order to forward a packet to a
   destination with an identifier address, an ingress node for a network
   maps an identifier address to a locator address. A network overlay
   method is used to forward the packet to the location in the network
   of the logical or mobile node.

   Since identifier addresses are non-topological they don't require any
   hierarchy in address assignment beyond the global network prefix.
   Therefore the network can randomly generate identifier addresses
   within a portion of the address in a space of at least sixty-four
 


T. Herbert              Expires August 24, 2018                [Page 10]

INTERNET DRAFTdraft-herbert-ipv6-prefix-address-privacy-00February 20, 2018


   bits.

   Strong privacy in addressing can be achieved by using a different
   randomly generated identifier address for each flow. Conceptually,
   this would entail that the network creates and assigns a unique and
   untrackable address to a host for every flow created by a host. Some
   suggestions for scaling this technique are discussed below.

   Note that this technique parallels what NAT does in that NAT
   effectively creates a different source address per connection. Unlike
   NAT however, address assignments in identifier/locator split are
   stateless in the network and transparent to the end points.  

6.2 Scaling identifier/locator address assignment

   Assigning an address per connection is a potential scaling problem on
   two accounts:

      o The amount of state needed in the mapping system is significant.

      o Bulk host address assignment is inefficient.

6.2.1 Scaling the amount of mapping state

   The amount of state necessary to assign each flow its own unique
   source IP address is equivalent, or at least proportional, to the
   amount of state needed for NAT-- basically this is one state element
   for every connection in the network. So in one sense this solution
   should scale as well as NAT has.

6.2.1.1 Hybrid address assignment

   Not all communications might require strong privacy, so it is
   conceivable that a hybrid approach to address assignment might be
   taken. A network might assign prefixes for use with communications
   that are not privacy sensitive, and may assign singleton addresses
   that meet strong privacy criteria for privacy sensitive
   communications. Assuming that most communications don't need strong
   privacy this could reduce the amount of state needed in the mapping
   system considerably. The decision as to whether strong privacy is
   required for a communication would be made by the user or
   application.

6.2.1.2 Hidden aggregation

   A possible solution to reduce state is to make addresses aggregable,
   but use an aggregation method that is known only by the network
   provider and hidden to the rest of the world. The network could use a
 


T. Herbert              Expires August 24, 2018                [Page 11]

INTERNET DRAFTdraft-herbert-ipv6-prefix-address-privacy-00February 20, 2018


   reversible hash or encryption function to create addresses.

   The input to an address generation function includes a device
   identifier, a secret key, and a generation index.

   The function may have the form:

      Address = Func(key, dev_ident, gen)

   Where "key" is secret to network, "dev_ident" is a network internal
   identifier for a device (roughly equivalent to "identity" in IDEAS),
   and "gen" is generation number 0,1,2,... N. The generation value is
   changed for each invocation to create different addresses for
   assignment to a device.

   When a network ingress node is forwarded a packet it performs the
   inverse function on an address.

   The inverse function has the form:

      (dev_ident, gen) = FuncInv(key, Address)

   The returned dev_ident value is used as the identifier in the mapping
   lookup for a locator address. In this manner, the network can
   generate many addresses to assign to a device where they all share a
   single entry in the mapping system.

6.2.2 Scaling bulk address assignment

   Assigning multiple addresses without aggregation is difficult to
   scale. Each address would need to be individually specified in an
   assignment sent to a host.

6.2.2.1 Bulk assignment using DHCPv6

   DHCPv6 might allow bulk singleton address assignment. As stated in
   [RFC7934]:

        Most DHCPv6 clients only ask for one non-temporary address, but
        the protocol allows requesting multiple temporary and even
        multiple non- temporary addresses, and the server could choose
        to provide multiple addresses.  It is also technically possible
        for a client to request additional addresses using a different
        DHCP Unique Identifier (DUID), though the DHCPv6 specification
        implies that this is not expected behavior ([RFC3315], Section
        9).  The DHCPv6 server will decide whether to grant or reject
        the request based on information about the client, including its
        DUID, MAC address, and more. The maximum number of IPv6
 


T. Herbert              Expires August 24, 2018                [Page 12]

INTERNET DRAFTdraft-herbert-ipv6-prefix-address-privacy-00February 20, 2018


        addresses that can be provided in a single DHCPv6 packet, given
        a typical MTU of 1500 bytes or smaller, is approximately 30.

6.2.2.2 Hidden aggregation assignment

   By extending the concept of hidden aggregation assignment (section
   6.2.1.2), it is conceptually possible that a host could work in
   concert with the network to generate addresses that meet strong
   privacy criteria. In this method, a host autonomously generates
   addresses as needed. The network, but no one outside the network, is
   then able aggregate the addresses as belonging to the device.

   End hosts are generally considered untrusted nodes by the network, so
   they cannot be given access to the network secret key used for the
   address generation function. Public key encryption might be used.

   A host may perform an encryption function to generate addresses:

      Address = Encrypt(pub_key, dev_inet, gen)

   Where "pub_key" is a public key for the network, "dev_ident" is a
   network identifier for the device and is visibile to the device (so
   it may be leaked). "gen" is a generation number 0,1,2,... N. The
   generation value is changed for each invocation to create different
   addresses.

   When a network ingress node is forwarded a packet it decrypts an
   address using the network private key.

   The decryption function has the form:

      (dev_ident, gen) = decrypt(priv_key, Address)

   Where "priv_key" is the secret private key of the network associated
   with the public key. The returned dev_ident value is used as the
   identifier in the mapping lookup for a locator address.

   Note that this method would require an new address assignment
   protocol.

6.2.3 Practicality of hidden aggregation methods

   The premise of hidden aggregation is that only trusted devices in the
   network are able decode the aggregation hidden within IPv6 addresses.
   This implies that the network must keep secrets about the process. In
   the above examples, the secrets are keys used in the hash or
   encryption. The security of the key is then paramount, so techniques
   for key management, rotation, and using different key sets for
 


T. Herbert              Expires August 24, 2018                [Page 13]

INTERNET DRAFTdraft-herbert-ipv6-prefix-address-privacy-00February 20, 2018


   obfuscation are pertinent.

   To perform a mapping lookup a node must apply the inverse address
   generation function to map addresses to locators. This lookup would
   occur in the critical data path so performance is important.
   Encryption and hashing are notoriously time consuming and
   computationally complex functions.

   Some possible mitigating factors for performance impact are:

      o The input to address generation functions is a small amount of
        data and has fixed size. The input is a key (presumably 128 or
        256 bits), part of all of an IPv6 address (128 bits), and a
        generation number (sixteen to twenty-four bits should work).

      o Given that the input is fixed size, specialized hardware might
        be used to optimize performance of the inverse address
        generation function. For instance, modern CPUs include
        instructions to perform crypto [AES-NI]. Since the keys used in
        these functions are secret to the network and there are
        relatively few of them, they might be preloaded into a crypto
        engine to reduce setup costs.

      o The output of an inverse address generation function is
        cacheable. A cache on a device could contain address to locator
        mappings. When the inverse function and lookup on dev_ident are
        performed, a mapping of address to the discovered locator could
        be created in the cache. The device could then map addresses in
        subsequent packets sent on the same flow to the proper locator
        by looking up the address in the cache.

6.3 Law enforcement considerations

   This section discusses law enforcement considerations for host
   tracking when using an identifier/locator split solution for strong
   privacy. NAT is used as a reference point for discussion.

   There are two sub-problems expressed by law enforcement about NAT
   [EUROPOL]:

      1) It is difficult to map a NAT address and port back to a user.

      2) Many Internet servers do not log the client source port of
         connections.

   The first problem is one of maintaining a log of NAT mappings. If the
   log contains the inner address, outer address and port, and timestamp
   when the NAT mapping was created-- then given the log and a NATed
 


T. Herbert              Expires August 24, 2018                [Page 14]

INTERNET DRAFTdraft-herbert-ipv6-prefix-address-privacy-00February 20, 2018


   packet, the original sender can be revealed. Note that NAT logs are
   kept internal to the provider network, and securing them is the
   responsibility of the provider. The same model can be applied to
   identifier/locator split where the infrastructure keeps a log of
   identifier to locator mappings and a timestamp for when they were
   created.

   In the second problem, the source port is needed to be logged in
   servers in order correlate a flow to an entry in the NAT logs of a
   provider. The source port is relevant to a NAT mapping; however, in
   identifier/locator split it's not since identification of a host node
   contained with an address. Therefore the client source port is not
   required for tracking users in an identifier/locator solution.

7  Security considerations

   The subject of this draft is privacy assigning network prefixes.
   Implicit to this is that any address assignment technique requires
   security on the parties entities involved.

   In the identifier/locator split the mapping of identifier to locator
   is privacy sensitive information. The locator may very well imply the
   geo location of a device. As such, it is recommended that locators
   that might contain accurate location information are strictly
   contained within a trusted infrastructure. 

   In mobile environments, it is natural to group identifiers
   (addresses) together that have the same attributes [IDGROUP]. For
   instance, if as in section 6.1 a different source address is used for
   each flow, all of the addresses assigned to a device form a group.
   When the device moves, all of the addresses move with it; this can be
   efficiently implemented as single operation on the mapping system.
   The group information is thus privacy sensitive information that must
   be secured by the infrastructure to prevent use of the information to
   make inferences of identity similar to /64 assignment.

   Hidden aggregation is a means of grouping identifiers together
   similar to the above description. The secret keys used in these
   algorithms are thus critical information that must be kept secure.
   Security by obscurity should be avoided here, divulging the algorithm
   used to generate addresses should not reduce security or privacy.

   End hosts must implement appropriate security to ensure privacy. For
   instance, if an address is assigned per flow as described in Section
   6.2, applications must be isolated from one another so that they
   cannot infer addresses or privacy properties of other applications
   running within the same system. Also, if a host is completely
   compromised then that fact should not impact the privacy and security
 


T. Herbert              Expires August 24, 2018                [Page 15]

INTERNET DRAFTdraft-herbert-ipv6-prefix-address-privacy-00February 20, 2018


   of other hosts and applications within a network.




8  References

8.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, <https://www.rfc-
             editor.org/info/rfc2119>.

   [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
             (IPv6) Specification", STD 86, RFC 8200, DOI
             10.17487/RFC8200, July 2017, <https://www.rfc-
             editor.org/info/rfc8200>.

8.2  Informative References

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

   [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy
             Considerations for IPv6 Address Generation Mechanisms", RFC
             7721, DOI 10.17487/RFC7721, March 2016, <https://www.rfc-
             editor.org/info/rfc7721>.

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

   [RFC3314] Wasserman, M., Ed., "Recommendations for IPv6 in Third
             Generation Partnership Project (3GPP) Standards", RFC 3314,
             DOI 10.17487/RFC3314, September 2002, <https://www.rfc-
             editor.org/info/rfc3314>.

   [RFC7934] Colitti, L., Cerf, V., Cheshire, S., and D. Schinazi, "Host
             Address Availability Recommendations", BCP 204, RFC 7934,
             DOI 10.17487/RFC7934, July 2016, <https://www.rfc-
             editor.org/info/rfc7934>.

   [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
             Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862,
             September 2007, <https://www.rfc-editor.org/info/rfc4862>.
 


T. Herbert              Expires August 24, 2018                [Page 16]

INTERNET DRAFTdraft-herbert-ipv6-prefix-address-privacy-00February 20, 2018


   [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
             Host Configuration Protocol (DHCP) version 6", RFC 3633,
             DOI 10.17487/RFC3633, December 2003, <https://www.rfc-
             editor.org/info/rfc3633>.

   [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
             C., and M. Carney, "Dynamic Host Configuration Protocol for
             IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2003,
             <https://www.rfc-editor.org/info/rfc3315>.

   [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
             and E. Lear, "Address Allocation for Private Internets",
             BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
             <https://www.rfc-editor.org/info/rfc1918>.

   [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
             C., and M. Carney, "Dynamic Host Configuration Protocol for
             IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2003,
             <https://www.rfc-editor.org/info/rfc3315>.

   [EUROPOL] EUROPOL/EC3 to delegations of the Council of the European
             Union, "Carrier-Grade Network Address Translation (CGN) and
             the Going Dark Problem", January 2017

   [AES-NI]  Gueron, S., "Intel Advanced Encryption Standard (AES) New
             Instructions", <https://software.intel.com/sites/
             default/files/article/165683/aes-wp-2012-09-22-v01.pdf>

   [IDGROUP] Herbert, T., "Identifier groups", draft-herbert-idgroups-
             00

9  Acknowledgments

   The author would like to thank Robert Moskowitz for insightful
   comments and contributions to this draft.


Authors' Addresses

   Tom Herbert
   Quantonium
   Santa Clara, CA
   USA

   Email: tom@quantonium.net






T. Herbert              Expires August 24, 2018                [Page 17]