Problem Statement for Secure End to End Privacy in IdLoc Systems
Deutsche Telekom
Deutsche-Telekom-Allee 7
D-64295 Darmstadt
Germany
Dirk.von-Hugo@telekom.de
Denpel Informatique
sarikaya@ieee.org
Telecom ParisTech
ggx@gigix.net
CEA, LIST
alexandre.petrescu@gmail.com
Soongsil University
gomjae@dcn.ssu.ac.kr
NEC
Umberto.Fattore@neclab.eu
Efficient and service aware flexible end-to-end routing in future
communication networks is achieved by routing protocol approaches
making use of Identifier Locator separation systems. Since these systems require a correlation between identifiers and location which
might allow tracking and misusage of individuals' identities and locations such operation demands for highly secure measures to
preserve privacy of users and devices. This document tries to
identify and describe typical use cases and derive thereof
a problem statement describing issues and challenges for application of privacy preserving Identifier-Locator
split (PidLoc) approaches.
Forthcoming future communication systems which are currently under
specification by various SDOs (Standards Development Organizations) try to achieve higher
resource efficiency and flexibility as compared to currently deployed
and operated networks. Independent of specific access technologies,
multiple applications shall be served with different levels of policy-driven mobility support and quality of service in terms of bandwidth,
latency, error probability, etc. Current practice of IP address usage
includes semantics as session identification as well as entity location
and name resolution. Many networking and information processing
related topics as cloud computing, software defined networking, network
function virtualization, logical network slicing, and convergence of
multiple heterogeneous access and transport technologies call for new
approaches towards service specific and optimized packet routing.
Promising proposals are Identifier Locator (Id-Loc) separation systems
like Identifier Locator Addressing (ILA) , Identifier-Locator Network
Protocol (ILNP) , Locator/ID Separation Protocol (LISP)
, and others.
Architectures and protocols for these approaches are already documented
in detail and are under continuous evolution in different WGs. This
document on the other hand attempts to identify potential issues with
respect to real-world deployment scenarios, which may demand for implementations of the above-mentionned Id-Loc systems. In particular, this document focuses on issues related to threats due to privacy violation of devices and their users, as well as location detection and movement tracking, where specific countermeasures may be needed.
To provide a problem statement this draft documents common aspects and
differences of several Id-Loc approaches from a high-level perspective
and describes a set of use cases resulting in identified issues and challenges concerning privacy and security. A set of requirements as outcome of a detailed analysis of these both generic and use cases specific questions will be provided in a companion document.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
Identifier: An identifier is information allowing to unambiguously
identify an entity or an entity group within a given scope. An
identifier is the equivalent of an End-point IDentifier (EID) in The Locator/ID Separation Protocol (LISP).
It may or may not be visible in communications.
Locator: A locator is a routable network address. It may be
associated with an identifier and used for communication on the network
layer according to identifier locator split principle. A locator is the
equivalent of a Routing Locator (RLOC) in LISP or an IP address in
other cases.
Identifier represents a communication end-point of an entity and may not be routable.
Locator also represents a communication end-point, however, it is a routable network address. Because entities indentified by an Identifier can move the association between Identifiers and Locators may be ephimeral. A database called a mapping system needs to be used for
Identifier to Locator mapping. Identifiers are mapped to locators for reachability purposes.
A mapping system has to handle mobility by updating the identifier to locator mappings in the database.
To start the communication, a device needs to know the identifier of the destination, hence it relies on a identifier lookup process to obtain the associated locator(s).
Note that both identifier and locator may be carried in clear in packet headers, depending on the specific technology used and the level of security/provacy enforced.
Usage of identifiers readily available for public access raises privacy issues.
For public entities, it may be desirable to have their fully qualified domain names or
host names available for public lookups by the clients, however, this is not the case in
general for all identifiers, e.g. for individuals roaming in a mobile network.
Identifier-Locator Network Protocol (ILNP) is a host-
based approach enabling mobility using mechanisms that are only
deployed in end-systems and do not require any router changes.
Identifier-Locator Addressing (ILA) uses address
transformation proposing to split an IPv6 address in 64-bit
identifier (lower address bits) and locator (higher address bits)
portions. The locator part is determined dynamically from a mapping
table that maintains associations between the location-independent
identifiers and topologically significant locators.
ILA is currently deployed in commercially available cloud systems such as Facebook and Google which are Layer 3 based. Also
A kernel implementation of ILA is available in Linux distribution. ILA does not require any transport layer (UDP/TCP)
changes.
Locator/Id Separation Protocol (LISP) is based on a map-and-encap approach, which provides a level of indirection for routing
and addressing performed at specific ingress/egress routers at the LISP domain boundaries. Such border routers performing LISP encapsulation at the packet's source stub network are indicated as Ingress Tunnel Routers (ITRs), while border routers at the packet's destination stub network are called Egress Tunnel Routers (ETRs), all of them are indicated by the general term xTRs. In order to obtain mappings used for encapsulation operation, xTRs query the mapping system in order to obtain all mappings related to a certain EID only when necessary (usually, but not exclusively, at the beginning of a new flow transmission).
The LISP control plane protocol allows to
support several different mapping systems (e.g., LISP+ALT and LISP-DDT ).
More than that, it can actually also be applied to various other data plane protocols.
The collection of use cases shall serve as starting point to identify different issues and challenges allowing for later derivation of
requirements to future solutions providing privacy and security in
generic Identifier Locator Split approaches.
Sensors and other connected things in the industry are usually not
personal items (e.g. wearables) potentially revealing an indiduals
sensitive information. Yet, industrial connected objects are business assets which should be detected/accessed
only by authorised intra-company entities. Since the huge amount of
these things (massive IoT) as well as the typical energy and bandwidth
constraints of battery-powered devices may pose a challenge to
traditional routing and security measures, privacy enabled Id-Loc
split approaches are proposed as a viable approach here,
.
In Industrial IoT, there are very strong reasons to not share the ID/Locator binding with third parties, i.e. retain the privacy. This can be achieved in a number of ways such as: using an ID/locator system but using some fixed anchor pointas a locator; injecting routing prefixes for the ID prefixes into the normal routing system and use proxy indirection; providing limited ID/Locator exposure. These are just examples, more approaches should be explored in order to find which one is the most suitable in the context of industrial IoT.
Upcoming new truly universal communication via so-called 5G systems
will demand for much more than (just) higher bandwidth and lower
latency. Integration of heterogeneous multiple access technologies
(both wireless and wireline) controlled by a common converged core
network and the evolution to service-based flexile functionalities
instead of hard-coded network functions calls for new protocols both
on control and user (data) plane. While Id-Loc approach would serve
well here, the challenge to provide a unique level of security and
privacy even for a lightweight routing and forwarding mechanism - allowing for ease of deployment and migration from existing operational network architecture - remains to be solved.
The cloud, i.e. a set of distributed data centers for processing and
storage connected via high speed transmission paths, is seen as
logical location for content and also for virtualized network
function instances and shall provide measures for easy re-location
and migration of these instances deployed as e.g. containers or
virtual machines. Id-Loc split routing protocols are proposed for
usage here as in ILA and LISP while the topology of the cloud components and logical
correlations shall be invisible from outside.
In a cloud, an upstream IP address does not necessarily belong to the actual service location, but
a gateway or load balancer. So, the locator or also ID reveal the location with the accuracy of a data center, not
the function taking a service request. This issue also manifests itself in today's LTE as
PGWs are in a data center binding UEs' IP addresses which are from the network of the data center.
In vehicular networks use cases (e.g. for a future C-ITS, i.e.
Cooperative Intelligent Transport Systems) there are some problems related to
privacy. Cars are mandated to beacon CAM messages (cooperative awareness message - also denoted
as basic service message, BSM)
very frequently (more
than 1 per second). These messages contain identifiers such as MAC
addresses. They are unique and visible in the public oui.txt file.
They can be tracked. But these are MAC addresses, not IP addresses.
If, in the future, cars beacon Router Advertisements as well, then there
is a risk in the source address of these RAs - the LL. They are usually
formed out of the MAC address, even though recent RFC7217 give
suggestion of using a random ID in the IID (Interface Identifiers)
(rather than the MAC
address); the RFC stays silent about the prefix length; since the
RFC7217 method covers also the LL addresses, and requires them to be
RFC4291-like (64bit length), that random ID is still of fixed length
(64). Longer than 64 IIDs may benefit privacy, since crypto attacks on
them would be harder.
A variable length IID in link-local addresses may help create a flexible
identifier-locator split thus increasing privacy.
In addition C-ITS shall also allow to improve vehicular network based
services as e.g. predict traffic congestion along the route and
propose a re-direction towards alternative routes, or predict network
coverage along the foreseen path to adapt a critical service. This
on the other hand demands for knowledge of the actual route, i.e.
tracking of the vehicle. As was shown in even anonymizing
sometimes does not prevent from privacy breaches. ...
Strong access control to ID/LOC mapping system(e.g. using longer and variable
length of IID, crypto-ID, etc.) has some tradeoffs between enhancing privacy and increasing delay.
Furthermore, in the vehicular network, reducing delay is also very important issue
because vehicle moves too fast to have enough time to configure.
For V2V communication, using temporary identifier between two vehicles can be one solution to prevent privacy.
When we think of the example for V2V communication, most of their data includes current traffic condition, speed, or accident
information which are not related to identify their unique device information.
can be one good solution to provide anonymity.
In , they suggest MAC address pseudonym in which
MAC address is changed periodically.
This section concludes on both common and specific issues and challenges in PIdLoc to
allow for derivation of requirements to potential solutions serving for a gap analysis
to be documented in upcoming drafts, e.g. (I-D.xyz-pidloc-reqs).
Anonymizing NYC Taxi Data: Does It Matter?