idnits 2.17.1 draft-iannone-pidloc-privacy-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (January 23, 2020) is 1548 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-38) exists of draft-ietf-lisp-rfc6830bis-30 == Outdated reference: A later version (-31) exists of draft-ietf-lisp-rfc6833bis-27 ** Downref: Normative reference to an Experimental RFC: RFC 6740 ** Downref: Normative reference to an Experimental RFC: RFC 6836 ** Downref: Normative reference to an Informational RFC: RFC 7348 ** Downref: Normative reference to an Experimental RFC: RFC 8111 -- Possible downref: Non-RFC (?) normative reference: ref. '3GPP' Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Iannone 3 Internet-Draft Telecom Paris 4 Intended status: Standards Track D. von Hugo 5 Expires: July 26, 2020 Deutsche Telekom 6 B. Sarikaya 7 Denpel Informatique 8 E. Nordmark 9 Zededa 10 January 23, 2020 12 Privacy issues in Identifier/Locator Separation Systems 13 draft-iannone-pidloc-privacy-00 15 Abstract 17 There exist several protocols and proposals that leverage on the 18 Identifier/Locator split paradigm, having some form of control plane 19 by which participating nodes can share their current Identifier-to- 20 Location information with their peers. This document explores some 21 of the privacy considerations for such a type of system. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on July 26, 2020. 40 Copyright Notice 42 Copyright (c) 2020 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Keywords and Terminology . . . . . . . . . . . . . . . . . . 3 59 3. Identifier Locator Split Protocols and Use-Cases . . . . . . 4 60 3.1. Identifier Locator Separation Protocols . . . . . . . . . 4 61 3.2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 5 62 4. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 5. Threats against Privacy . . . . . . . . . . . . . . . . . . . 7 64 5.1. Location Privacy . . . . . . . . . . . . . . . . . . . . 7 65 5.2. Movement Privacy . . . . . . . . . . . . . . . . . . . . 7 66 6. Not everybody all the time . . . . . . . . . . . . . . . . . 7 67 6.1. Optimized Routing . . . . . . . . . . . . . . . . . . . . 8 68 6.2. Family and Friends . . . . . . . . . . . . . . . . . . . 8 69 6.3. Business Assets . . . . . . . . . . . . . . . . . . . . . 8 70 7. Boundary between ID/locator part and rest of Internet . . . . 9 71 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 72 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 73 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 76 1. Introduction 78 When the IP address is separated, one way or another, into an 79 identifier and a locator, there is typically the need to be able to 80 look up an identifier to find possible locators which can be used to 81 reach the identified endpoint. If such a system (think a distributed 82 database) was publicly available, then this would introduce 83 additional privacy considerations which do not exist in the absence 84 of the ID/locator split. Think for instance if identifiers are 85 assigned to devices such as mobile phones which have a strong binding 86 with an individual. Having the location of such identifier publicly 87 available implies make the individual whereabouts public. 89 Without an ID/locator split, a device is already providing its IP 90 address (in the form of a source address) to any network device along 91 the path, and also to the remote endpoint. That endpoint in 92 particular might use IP geolocation databases to get a pretty good 93 idea of where its peer is located, for instance to offer information 94 and/or advertising relevant to that location. 96 However, in such scenario, when a device (e.g., a laptop or 97 smartphone connected over WiFi) moves (e.g., from home to a coffee 98 shop) the IP address changes. This makes it harder for network 99 devices along the paths to realize that it is the same mobile 100 device. And if the mobile device is not retaining cookies or logged 101 into websites, those remote peers would also have some difficulty 102 determining whether it is the same mobile device. Furthermore, a 103 mobile device which is using typical cellular network technologies 104 ends up with an IP address, at least as seen by remote peers outside 105 of the cellular network, which is associated with the cellular 106 operator but does not necessarily indicate a particular location of 107 the mobile device. 109 Note that even if the IP address isn't always useful to track a 110 mobile device today, there are several mechanisms higher in the stack 111 which can do this. For instance cookies or SSL sessions, 112 applications which share GPS location, or operators who offer 113 additional location information (for instance based on which cellular 114 base station a mobile device is using) to business partners. 116 Promising proposals are Identifier Locator (Id-Loc) separation 117 systems like, Identifier-Locator Network Protocol (ILNP) [RFC6740], 118 Locator/ID Separation Protocol (LISP) [I-D.ietf-lisp-rfc6830bis] 119 [I-D.ietf-lisp-rfc6833bis], Virtual eXtensible LAN [RFC7348], and 120 others. 122 Architectures and protocols for these approaches are already 123 documented in detail and are under continuous evolution in different 124 WGs. This document on the other hand attempts to identify potential 125 issues with respect to real-world deployment scenarios, which may 126 demand for implementations of the above-mentioned Id-Loc systems. 127 In particular, this document overviews issues related to threats due 128 to privacy violation of devices and their users, as well as location 129 detection and movement tracking, where specific countermeasures may 130 be needed. 132 2. Keywords and Terminology 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 136 "OPTIONAL" in this document are to be interpreted as described in BCP 137 14 [RFC2119] [RFC8174] when, and only when, they appear in all 138 capitals, as shown here. 140 Identifier: An identifier is information allowing to unambiguously 141 identify an entity or an entity group within a given scope. An 142 identifier is the equivalent of an End-point IDentifier (EID) in The 143 Locator/ID Separation Protocol (LISP). It may or may not be visible 144 in communications. 146 Locator: A locator is a routable network address. It may be 147 associated with an identifier and used for communication on the 148 network layer according to identifier locator split principle. A 149 locator is the equivalent of a Routing Locator (RLOC) in LISP or an 150 IP address in other cases. 152 3. Identifier Locator Split Protocols and Use-Cases 154 3.1. Identifier Locator Separation Protocols 156 Identifier represents a communication end-point of an entity and may 157 not be routable. Locator also represents a communication end-point, 158 however, it is a routable network address. Because entities 159 identified by an Identifier can move the association between 160 Identifiers and Locators may be ephemeral. A database called a 161 mapping system needs to be used for Identifier to Locator mapping. 162 Identifiers are mapped to locators for reachability purposes. A 163 mapping system has to handle mobility by updating the identifier to 164 locator mappings in the database. 166 To start the communication, a device needs to know the identifier of 167 the destination, hence it relies on a identifier lookup process to 168 obtain the associated locator(s). Note that both identifier and 169 locator may be carried in clear in packet headers, depending on the 170 specific technology used and the level of security/privacy enforced. 172 Usage of identifiers readily available for public access raises 173 privacy issues. For public entities, it may be desirable to have 174 their fully qualified domain names or host names available for public 175 lookups by the clients, however, this is not the case in general for 176 all identifiers, e.g. for individuals roaming in a mobile network. 178 3.1.1. ILNP 180 Identifier-Locator Network Protocol (ILNP) [RFC6740] is a host-based 181 approach enabling mobility using mechanisms that are only deployed in 182 end-systems and do not require any router changes. 184 3.1.2. VxLAN 186 Virtual Extensible LAN (VXLAN) [RFC7348] is a network virtualization 187 technology that attempts to address the scalability problems 188 associated with large cloud computing deployments. It uses a VLAN- 189 like encapsulation technique to encapsulate layer 2 Ethernet frames 190 within layer 4 UDP datagrams, using 4789 as the default IANA-assigned 191 destination UDP port number. VXLAN endpoints, which terminate VXLAN 192 tunnels and may be either virtual or physical switch ports, are known 193 as VXLAN tunnel endpoints (VTEPs) and can be considered the locators 194 of the devices in the extended VLAN. 196 3.1.3. LISP 198 Locator/Id Separation Protocol (LISP) [I-D.ietf-lisp-rfc6830bis] 199 [I-D.ietf-lisp-rfc6833bis] is based on a map-and-encap approach, 200 which provides a level of indirection for routing and addressing 201 performed at specific ingress/egress routers at the LISP domain 202 boundaries. Such border routers performing LISP encapsulation at the 203 packet's source stub network are indicated as Ingress Tunnel Routers 204 (ITRs), while border routers at the packet's destination stub network 205 are called Egress Tunnel Routers (ETRs), all of them are indicated by 206 the general term xTRs. In order to obtain mappings used for 207 encapsulation operation, xTRs query the mapping system in order to 208 obtain all mappings related to a certain EID only when necessary 209 (usually, but not exclusively, at the beginning of a new flow 210 transmission). The LISP control plane protocol 211 [I-D.ietf-lisp-rfc6833bis] allows to support several different 212 mapping systems (e.g., LISP+ALT [RFC6836] and LISP-DDT [RFC8111]). 213 More than that, it can actually also be applied to various other data 214 plane protocols. 216 3.2. Use Cases 218 The collection of use-cases shall serve as an overview of possible 219 Loc-ID split application and help in identifying different issues in 220 privacy and security in generic Identifier Locator Split approaches. 222 3.2.1. Industrial IoT 224 Sensors and other connected things in the industry are usually not 225 personal items (e.g. wearables) potentially revealing an individuals 226 sensitive information. Yet, industrial connected objects are 227 business assets which should be detected/accessed only by authorised 228 intra-company entities. Since the huge amount of these things 229 (massive IoT) as well as the typical energy and bandwidth constraints 230 of battery-powered devices may pose a challenge to traditional 231 routing and security measures. 233 In Industrial IoT, there are very strong reasons to not share the ID/ 234 Locator binding with third parties, i.e. retain the privacy. This 235 can be achieved in a number of ways such as: using an ID/locator 236 system but using some fixed anchor point as a locator; injecting 237 routing prefixes for the ID prefixes into the normal routing system 238 and use proxy indirection; providing limited ID/Locator exposure. 240 These are just examples, more approaches should be explored in order 241 to find which one is the most suitable in the context of industrial 242 IoT. 244 3.2.2. 5G Use Case 246 Upcoming new truly universal communication via so-called 5G systems 247 will demand for much more than (just) higher bandwidth and lower 248 latency. Integration of heterogeneous multiple access technologies 249 (both wireless and wireline) controlled by a common converged core 250 network and the evolution to service-based flexile functionalities 251 instead of hard-coded network functions calls for new protocols both 252 on control and user (data) plane. While Id-Loc approach would serve 253 well here, the challenge to provide a unique level of security and 254 privacy even for a lightweight routing and forwarding mechanism - 255 allowing for ease of deployment and migration from existing 256 operational network architecture - remains to be solved. 258 3.2.3. Cloud Use Case 260 The cloud, i.e. a set of distributed data centers for processing and 261 storage connected via high-speed transmission paths, is seen as 262 logical location for content and also for virtualized network 263 function instances and shall provide measures for easy re-location 264 and migration of these instances deployed as e.g. containers or 265 virtual machines. Id-Loc split routing protocols are proposed for 266 usage here as in VXLAN [RFC7348] and LISP [I-D.ietf-lisp-rfc6830bis] 267 [I-D.ietf-lisp-rfc6833bis] while the topology of the cloud components 268 and logical correlations shall be invisible from outside. 270 In a cloud, an upstream IP address does not necessarily belong to the 271 actual service location, but a gateway or load balancer. So, the 272 locator or also ID reveal the location with the accuracy of a data 273 center, not the function taking a service request. This issue also 274 manifests itself in today's 4G cellular networks (LTE/EPS) as the 275 Packet Data Network Gateways (PGWs) [3GPP] interfacing the Internet 276 are often realised already virtually in a data center, binding 277 UEs' IP addresses which are from the network of the data center. 279 4. Assumptions 281 We assume that there are benefits associated with sharing ID to 282 locator mappings with some peers sometimes. Those benefits can be 284 o Lower latency and higher bandwidth: If two peer devices have some 285 locators which are topologically closer, then sharing all the 286 locators means that the devices can find a shorter path (fewer hops 287 and/or shorter round-trip time), or find a path, which offers higher 288 throughput, then if the devices only shared some form of default 289 locator. 291 o Higher availability and robustness: If two peer devices share all 292 their locators, then if there is some network outage the devices 293 can autonomously discover a working path using the different 294 locator pairs. 296 However, those benefits do not imply that it is a good idea to always 297 share all of the locators with everybody. That would make tracking 298 by third parties trivial. 300 A device can obfuscate itself by, instead of using a single long- 301 lived identifier, using multiple short-lived identifiers. In that 302 case the value to the ID/locator binding for any particular 303 identifier would be lower. However, this assumes that the device can 304 ensure no relation between the different identifiers it is using, 305 either concurrently or over time. Also, some of the benefits above 306 implicitly assume that there can be some long-lived sessions or 307 associations between pairs of identifiers. For instance, if a device 308 would need to go fetch the current identifier of its peer from some 309 removed system, then it might not experience improved robustness since 310 that fetch might depend on the failed external connectivity. Thus we 311 believe that we can explore the core of the ID/locator privacy issue 312 by looking at long-lived identifiers. 314 5. Threats against Privacy 316 There seem to be at least two different privacy threats relating to 317 ID/locator mapping systems. 319 5.1. Location Privacy 321 If a third party can at any time determine the IP location of some 322 identifier, then the device can at one point be IP geolocated at 323 home, and later a coffee shop. 325 5.2. Movement Privacy 327 If a third party can determine that an identifier has changed 328 locator(s) at time T, then even without knowing the particular 329 locators before and after, it can correlate this movement event with 330 other information (e.g., security cameras) to create a binding 331 between the identifier and a person. 333 6. Not everybody all the time 335 In order to see the benefits about but minimizing the privacy 336 implication one can explore limiting to which peers and when the ID/ 337 locator binding are exposed. 339 A few initial examples help illustrate this. 341 6.1. Optimized Routing 343 If some operator of a network where there is a large amount of 344 mobility wants to ensure efficient routing, then an ID/locator split 345 approach might make sense. Such a system can potentially be limited 346 to the set of devices (routers etc.) which are under the operators 347 control. If this is the case, then the ID/locator mapping system can 348 provide access control so that only those trusted devices can access 349 the mappings. 351 Note that from a privacy perspective this isn't any different than 352 the same operator using a link-state routing protocol to share host 353 routes for all the mobile devices. In that case all participants in 354 the link-state protocol can determine the location (attached to which 355 router) and notice any mobility events. Of course, there are 356 significant non-privacy differences between those two approaches. 358 Exposing the ID/locator mapping to attached devices (e.g., any mobile 359 devices which wouldn't be trusted to participate in the link-state 360 routing counterpart approach), will change the privacy implications. 362 6.2. Family and Friends 364 There are cases where it is quite reasonable to share location 365 information with other family members or friends. For instance, 366 young children might run applications which enable their parents to 367 track them on their way to/from school. And I might share my 368 location with friends so we can more easily find each other while out 369 in town. 371 Today such location sharing happens at an application layer using GPS 372 coordinates. But while such sharing is in effect, it wouldn't be 373 unreasonable to also consider sharing IP locators to make it more 374 efficient or more robust to e.g., route a video feed from one device 375 to another. 377 6.3. Business Assets 379 In the area of Industrial IoT there are cases where an asset owner 380 might want to ensure that their assets can communicate efficiently 381 and robustly. In many cases those assets might be decoupled from any 382 persons, but there can still be strong reasons to not share the ID/ 383 locator binding with third parties, such as enabling competitors to 384 determine the number of deployed devices in a particular IP prefix. 386 7. Boundary between ID/locator part and rest of Internet 388 If the access to the ID/locator mapping is restricted as suggested 389 above, then most of the potential peer devices would not have access 390 to the ID/locator mappings. This means that there has to be a 391 demarcation point between the part of the network which can access 392 the ID/locator mappings for a particular identifier and the one which 393 can not. There might be several choices how to handle this such as 394 still using an ID/locator system but pointing to a locator for some 395 fixed anchor point, or injecting routing prefixes for the ID prefixes 396 into the normal routing system, or not providing any stable locators 397 across this boundary; only allow ephemeral IP addresses per session 398 or otherwise limited exposure. 400 8. Security Considerations 402 This document discusses privacy considerations, but does not explore 403 any security considerations. 405 9. IANA Considerations 407 There are no IANA actions needed for this document. 409 10. References 411 [I-D.ietf-lisp-rfc6830bis] 412 Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. 413 Cabellos-Aparicio, "The Locator/ID Separation Protocol 414 (LISP)", draft-ietf-lisp-rfc6830bis-30 (work in progress), 415 January 2020. 417 [I-D.ietf-lisp-rfc6833bis] 418 Farinacci, D., Maino, F., Fuller, V., and A. Cabellos- 419 Aparicio, "Locator/ID Separation Protocol (LISP) Control- 420 Plane", draft-ietf-lisp-rfc6833bis-27 (work in progress), 421 January 2020. 423 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 424 Requirement Levels", BCP 14, RFC 2119, 425 DOI 10.17487/RFC2119, March 1997, 426 . 428 [RFC6740] Atkinson, RJ. and SN. Bhatti, "Identifier-Locator Network 429 Protocol (ILNP) Architectural Description", RFC 6740, 430 DOI 10.17487/RFC6740, November 2012, 431 . 433 [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, 434 "Locator/ID Separation Protocol Alternative Logical 435 Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836, 436 January 2013, . 438 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 439 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 440 eXtensible Local Area Network (VXLAN): A Framework for 441 Overlaying Virtualized Layer 2 Networks over Layer 3 442 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 443 . 445 [RFC8111] Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. 446 Smirnov, "Locator/ID Separation Protocol Delegated 447 Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111, 448 May 2017, . 450 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 451 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 452 May 2017, . 454 [3GPP] 3GPP TS 23.401: "General Packet Radio Service (GPRS) 455 enhancements for Evolved Universal Terrestrial Radio 456 Access Network (E-UTRAN) access", 457 459 Authors' Addresses 461 Luigi Iannone 462 Telecom Paris 464 Email: ggx@gigix.net 466 Dirk von Hugo 467 Deutsche Telekom 469 D-64295 Darmstadt 470 Germany 472 Email: Dirk.von-Hugo@telekom.de 474 Behcet Sarikaya 475 Denpel Informatique 477 Email: sarikaya@ieee.org 478 Erik Nordmark 479 Zededa 480 Santa Clara, CA 481 USA 483 Email: nordmark@sonic.net