| Network Working Group | E. Nordmark |
| Internet-Draft | Zededa |
| Intended status: Standards Track | July 2, 2018 |
| Expires: January 3, 2019 |
Privacy issues in ID/locator separation systems
draft-nordmark-id-loc-privacy-00
There exists several protocols and proposals for identifier/locator split which have some form of control plane by which participating nodes can use to share their current id to locator information with their peers. This document explores some of the privacy considerations for such a system.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 3, 2019.
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 (https://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.
When the IP address is separated, one way or another, into an identifier and a locator there is typically a need to be able to look up an identifier to find possible locators which can be used to reach the identified endpoint. If such a system (think distributed database) was publicly available while identifiers are assigned to devices such as mobile phones which have a strong binding with an individual, then this would introduce additional privacy considerations which do not exist in the absence of the ID/locator split.
Without an ID/locator split a device is already providing its IP address (in the form of a source address) to any network device along the path, and also to the remote endpoint. That endpoint in particular might use IP geolocation databases to get a pretty good idea of where its peer is located, for instance to offer information and/or advertising relevant to that location.
However, such such a device (e.g., a laptop or smartphone connected over WiFi) move e.g., from home to a coffee shop, the IP address changes. This makes it harder for network devices along the paths to realize that the its is the same mobile device. And if the mobile device is not retaining cookies or logged into websites, those remote peers would also have some difficulty determining it is the same mobile device. Furthermore, a mobile device which is using typical cellular network technologies end up with an IP address, at least as seen by remote peers outside of the cellular network, which is associated with the cellular operator but does not necessarily indicate a particular location of the mobile device.
Note that even if the IP address isn't always useful to track a mobile device today, there are several mechanisms higher in the stack which can do this. For instance cookies or SSL sessions, applications which share GPS location, or operators who offer additional location information (for instance based on which cellular base station a mobile device is using) to business partners.
With that baseline in mind, let's look at what additional privacy considerations can be introduced by a system which provides ID to locator mappings.
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC2119].
We assume that there are benefits associated with sharing ID to locator mappings with some peers sometimes. Those benefits can be
However, those benefits do not imply that it is a good idea to always share all of the locators with everybody. That would make tracking by third parties trivial.
A device can obfuscate itself by, instead of using a single long-lived identifier, using multiple short-lived identifiers. In that case the value to the ID/locator binding for any particular identifier would be lower. However, this assumes that the device can ensure unlinkablity between the different identifiers it is using either concurrently or over time. Also, some of the benefits above implicitly assume that there can be some long-lived sessions or associations between pairs of identifiers. For instance, if a device would need to go fetch the current identifier of its peer from some remove system, then it might not experience improved robustness since that fetch might depend on the failed external connectivity. Thus we believe that we can explore the core of the ID/locator privacy issue by looking at long-lived identifiers.
This is the first version of this draft so this is very preliminary. But there seems to be at least two different privacy threats relating to ID/locator mapping systems.
If a third party can at any time determine the IP location of some identifier, then the device can at one point be IP geolocated at home, and later a coffee shop.
If a third party can determine that an identifier has changed locator(s) at time T, then even without knowing the particular locators before and after, it can correlate this movement event with other information (e.g., security cameras) to create a binding between the identifier and a person.
In order to see the benefits about but minimizing the privacy implication one can explore limiting to which peers and when the ID/locator binding are exposed.
A few initial examples help illustrate this.
If some operator of a network where there is a large amount of mobility wants to ensure efficient routing, then a ID/locator split approach might make sense. Such a system can potentially be limited to the set of devices (routers etc) which are under the operators control. If this is the case, then the ID/locator mapping system can provide access control so that only those trusted devices can access the mappings.
Note that from a privacy perspective this isn't any different than the same operator using a link-state routing protocol to share host routes for all the mobile devices. In that case all participants in the link-state protocol can determine the location (attached to which router) and notice any mobility events. Of course, there are significant non-privacy differences between those two approaches.
Exposing the ID/locator mapping to attached devices (e.g., any mobile devices which wouldn't be trusted to participate in the link-state routing counterpart approach), will change the privacy implications.
There are cases where it is quite reasonable to share location information with other family members or friends. For instance, young children might run applications which enable their parents to track them on their way to/from school. And I might share my location with friends so we can more easily find each other while out on town.
Today such location sharing happens at an application layer using GPS coordinates. But while such sharing is in effect, it wouldn't be unreasonable to also consider sharing IP locators to make it more efficient or more robust to e.g., route a video feed from one device to another.
In the area of Industrial IoT there are cases where an asset owner might want to ensure that their assets can communicate efficiently and robustly. In many cases those assets might be decoupled from any persons, but there can still be strong reasons to not share the ID/locator binding with third parties, such as enabling competitors to determine the number of deployed devices in a particular IP prefix.
If the access to the ID/locator mapping are restricted as suggested above, then most of the potential peer devices would not have access to the ID/locator mappings. This means that there has to be a demarcation point between the part of the network which can access the ID/locator mappings for a particular identifier and the one which can not. There might be several choices how to handle this such as still using an ID/locator system but pointing a locator for some fixed anchor point, or injecting routing prefixes for the ID prefixes into the normal routing system, or not providing any stable locators across this boundary; only allow ephemeral IP addresses per session or otherwise limited exposure.
This document discusses privacy considerations, but does not explore any security considerations.
There are no IANA actions needed for this document.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |