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, . [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . 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, . [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, . [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, . [RFC3314] Wasserman, M., Ed., "Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards", RFC 3314, DOI 10.17487/RFC3314, September 2002, . [RFC7934] Colitti, L., Cerf, V., Cheshire, S., and D. Schinazi, "Host Address Availability Recommendations", BCP 204, RFC 7934, DOI 10.17487/RFC7934, July 2016, . [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, . 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, . [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, . [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, . [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, . [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", [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]