idnits 2.17.1 draft-xyz-pidloc-ps-02.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. 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 (June 3, 2019) is 1782 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) == Unused Reference: 'I-D.ietf-intarea-tunnels' is defined on line 371, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-lisp-sec' is defined on line 399, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-intarea-tunnels-09 == Outdated reference: A later version (-30) exists of draft-ietf-ipwave-vehicular-networking-09 ** Downref: Normative reference to an Informational draft: draft-ietf-ipwave-vehicular-networking (ref. 'I-D.ietf-ipwave-vehicular-networking') == Outdated reference: A later version (-16) exists of draft-ietf-lisp-eid-anonymity-06 ** Downref: Normative reference to an Experimental draft: draft-ietf-lisp-eid-anonymity (ref. 'I-D.ietf-lisp-eid-anonymity') == Outdated reference: A later version (-38) exists of draft-ietf-lisp-rfc6830bis-26 == Outdated reference: A later version (-31) exists of draft-ietf-lisp-rfc6833bis-24 == Outdated reference: A later version (-29) exists of draft-ietf-lisp-sec-18 ** Downref: Normative reference to an Experimental RFC: RFC 6740 ** Downref: Normative reference to an Experimental RFC: RFC 6836 ** Downref: Normative reference to an Experimental RFC: RFC 8111 Summary: 6 errors (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. von Hugo 3 Internet-Draft Deutsche Telekom 4 Intended status: Standards Track B. Sarikaya 5 Expires: December 5, 2019 Denpel Informatique 6 L. Iannone 7 Telecom ParisTech 8 A. Petrescu 9 CEA, LIST 10 K. Sun 11 Soongsil University 12 U. Fattore 13 NEC 14 June 3, 2019 16 Problem Statement for Secure End to End Privacy in IdLoc Systems 17 draft-xyz-pidloc-ps-02 19 Abstract 21 Efficient and service aware flexible end-to-end routing in future 22 communication networks is achieved by routing protocol approaches 23 making use of Identifier Locator separation systems. Since these 24 systems require a correlation between identifiers and location which 25 might allow tracking and misusage of individuals' identities and 26 locations such operation demands for highly secure measures to 27 preserve privacy of users and devices. This document tries to 28 identify and describe typical use cases and derive thereof a problem 29 statement describing issues and challenges for application of privacy 30 preserving Identifier-Locator split (PidLoc) approaches. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on December 5, 2019. 49 Copyright Notice 51 Copyright (c) 2019 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 68 3. Identifier Locator Separation Protocols . . . . . . . . . . . 4 69 3.1. ILNP . . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3.2. ILA . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 3.3. LISP . . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 3.4. Privacy in IdLoc Protocols . . . . . . . . . . . . . . . 5 73 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6 74 4.1. Industrial IoT . . . . . . . . . . . . . . . . . . . . . 6 75 4.2. 5G Use Case . . . . . . . . . . . . . . . . . . . . . . . 6 76 4.3. Cloud Use Case . . . . . . . . . . . . . . . . . . . . . 7 77 4.4. Vehicular Networks . . . . . . . . . . . . . . . . . . . 7 78 5. PIdLoc Issues and Challenges . . . . . . . . . . . . . . . . 8 79 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 80 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 81 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 82 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 85 1. Introduction 87 Forthcoming future communication systems which are currently under 88 specification by various SDOs (Standards Development Organizations) 89 try to achieve higher resource efficiency and flexibility as compared 90 to currently deployed and operated networks. Independent of specific 91 access technologies, multiple applications shall be served with 92 different levels of policy-driven mobility support and quality of 93 service in terms of bandwidth, latency, error probability, etc. 94 Current practice of IP address usage includes semantics as session 95 identification as well as entity location and name resolution. Many 96 networking and information processing related topics as cloud 97 computing, software defined networking, network function 98 virtualization, logical network slicing, and convergence of multiple 99 heterogeneous access and transport technologies call for new 100 approaches towards service specific and optimized packet routing. 102 Promising proposals are Identifier Locator (Id-Loc) separation 103 systems like Identifier Locator Addressing (ILA) 104 [I-D.herbert-intarea-ila], Identifier-Locator Network Protocol (ILNP) 105 [RFC6740], Locator/ID Separation Protocol (LISP) 106 [I-D.ietf-lisp-rfc6830bis] [I-D.ietf-lisp-rfc6833bis], and others. 108 Architectures and protocols for these approaches are already 109 documented in detail and are under continuous evolution in different 110 WGs. This document on the other hand attempts to identify potential 111 issues with respect to real-world deployment scenarios, which may 112 demand for implementations of the above-mentionned Id-Loc systems. 113 In particular, this document focuses on issues related to threats due 114 to privacy violation of devices and their users, as well as location 115 detection and movement tracking, where specific countermeasures may 116 be needed. 118 To provide a problem statement this draft documents common aspects 119 and differences of several Id-Loc approaches from a high-level 120 perspective and describes a set of use cases resulting in identified 121 issues and challenges concerning privacy and security. A set of 122 requirements as outcome of a detailed analysis of these both generic 123 and use cases specific questions will be provided in a companion 124 document. 126 2. Conventions and Terminology 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in RFC 2119 [RFC2119]. 132 Identifier: An identifier is information allowing to unambiguously 133 identify an entity or an entity group within a given scope. An 134 identifier is the equivalent of an End-point IDentifier (EID) in The 135 Locator/ID Separation Protocol (LISP). It may or may not be visible 136 in communications. 138 Locator: A locator is a routable network address. It may be 139 associated with an identifier and used for communication on the 140 network layer according to identifier locator split principle. A 141 locator is the equivalent of a Routing Locator (RLOC) in LISP or an 142 IP address in other cases. 144 3. Identifier Locator Separation Protocols 146 Identifier represents a communication end-point of an entity and may 147 not be routable. Locator also represents a communication end-point, 148 however, it is a routable network address. Because entities 149 identified by an Identifier can move the association between 150 Identifiers and Locators may be ephemeral. A database called a 151 mapping system needs to be used for Identifier to Locator mapping. 152 Identifiers are mapped to locators for reachability purposes. A 153 mapping system has to handle mobility by updating the identifier to 154 locator mappings in the database. 156 To start the communication, a device needs to know the identifier of 157 the destination, hence it relies on a identifier lookup process to 158 obtain the associated locator(s). Note that both identifier and 159 locator may be carried in clear in packet headers, depending on the 160 specific technology used and the level of security/privacy enforced. 162 Usage of identifiers readily available for public access raises 163 privacy issues. For public entities, it may be desirable to have 164 their fully qualified domain names or host names available for public 165 lookups by the clients, however, this is not the case in general for 166 all identifiers, e.g. for individuals roaming in a mobile network. 168 3.1. ILNP 170 Identifier-Locator Network Protocol (ILNP) [RFC6740] is a host- based 171 approach enabling mobility using mechanisms that are only deployed in 172 end-systems and do not require any router changes. 174 3.2. ILA 176 Identifier-Locator Addressing (ILA) [I-D.herbert-intarea-ila] uses 177 address transformation proposing to split an IPv6 address in 64-bit 178 identifier (lower address bits) and locator (higher address bits) 179 portions. The locator part is determined dynamically from a mapping 180 table that maintains associations between the location-independent 181 identifiers and topologically significant locators. 183 ILA is currently deployed in commercially available cloud systems 184 such as Facebook and Google which are Layer 3 based. Also A kernel 185 implementation of ILA is available in Linux distribution. ILA does 186 not require any transport layer (UDP/TCP) changes. 188 3.3. LISP 190 Locator/Id Separation Protocol (LISP) [I-D.ietf-lisp-rfc6830bis] 191 [I-D.ietf-lisp-rfc6833bis] is based on a map-and-encap approach, 192 which provides a level of indirection for routing and addressing 193 performed at specific ingress/egress routers at the LISP domain 194 boundaries. Such border routers performing LISP encapsulation at the 195 packet's source stub network are indicated as Ingress Tunnel Routers 196 (ITRs), while border routers at the packet's destination stub network 197 are called Egress Tunnel Routers (ETRs), all of them are indicated by 198 the general term xTRs. In order to obtain mappings used for 199 encapsulation operation, xTRs query the mapping system in order to 200 obtain all mappings related to a certain EID only when necessary 201 (usually, but not exclusively, at the beginning of a new flow 202 transmission). The LISP control plane protocol 203 [I-D.ietf-lisp-rfc6833bis] allows to support several different 204 mapping systems (e.g., LISP+ALT [RFC6836] and LISP-DDT [RFC8111]). 205 More than that, it can actually also be applied to various other data 206 plane protocols. 208 3.4. Privacy in IdLoc Protocols 210 In all of the above protocols of ILNP, ILA and LISP, the identifiers 211 are carried in packet headers in clear and therefore preserving 212 identifier's privacy is needed. Otherwise private information such 213 as the location and content of the communication can be revealed. 215 In case of ILNP, public DNS can be used to by the end nodes to access 216 the destination identifier for a given Fully Qualified Domain Name 217 (FQDN). However the same node also gets the locator values raising 218 serious privacy issues in the control plane. As for the data plane, 219 both source locator and identifier need to be privacy protected and 220 techniques such as locator rewriting and ephemeral-use identifiers, 221 respectively are suggested. 223 In the control plane, ILA exhibits similar privacy issues if the ILA 224 mapping system defining identifier locator mappings can publicly be 225 accessed. In ILA, privacy is addressed in the data plane by way of 226 UE simultaneously using different addresses for different connections 227 chosen from a block of addresses. 229 In LISP mapping system, the lack of privacy support in the control 230 plane for a given identifier value exists due to the use of DNS, as 231 in ILNP. In the data plane, privacy addressing by way of UE 232 simultaneously using different addresses for different connections 233 chosen from a block of addresses can be used as in ILA. 235 4. Use Cases 237 The collection of use cases shall serve as starting point to identify 238 different issues and challenges allowing for later derivation of 239 requirements to future solutions providing privacy and security in 240 generic Identifier Locator Split approaches. 242 4.1. Industrial IoT 244 Sensors and other connected things in the industry are usually not 245 personal items (e.g. wearables) potentially revealing an individual's 246 sensitive information. Yet, industrial connected objects are 247 business assets which should be detected/accessed only by authorised 248 intra-company entities. Since the huge amount of these things 249 (massive IoT) as well as the typical energy and bandwidth constraints 250 of battery-powered devices may pose a challenge to traditional 251 routing and security measures, privacy enabled Id-Loc split 252 approaches are proposed as a viable approach here, 253 [I-D.nordmark-id-loc-privacy]. 255 In Industrial IoT, there are very strong reasons to not share the ID/ 256 Locator binding with third parties, i.e. retain the privacy. This 257 can be achieved in a number of ways such as: using an ID/locator 258 system but using some fixed anchor points a locator; injecting 259 routing prefixes for the ID prefixes into the normal routing system 260 and use proxy indirection; providing limited ID/Locator exposure. 261 These are just examples, more approaches should be explored in order 262 to find which one is the most suitable in the context of industrial 263 IoT. 265 4.2. 5G Use Case 267 Upcoming new truly universal communication via so-called 5G systems 268 will demand for much more than (just) higher bandwidth and lower 269 latency. Integration of heterogeneous multiple access technologies 270 (both wireless and wireline) controlled by a common converged core 271 network and the evolution to service-based flexile functionalities 272 instead of hard-coded network functions calls for new protocols both 273 on control and user (data) plane. While Id-Loc approach would serve 274 well here, the challenge to provide a unique level of security and 275 privacy even for a lightweight routing and forwarding mechanism - 276 allowing for ease of deployment and migration from existing 277 operational network architecture - remains to be solved. 279 4.3. Cloud Use Case 281 The cloud, i.e. a set of distributed data centers for processing and 282 storage connected via high speed transmission paths, is seen as 283 logical location for content and also for virtualized network 284 function instances and shall provide measures for easy re-location 285 and migration of these instances deployed as e.g. containers or 286 virtual machines. Id-Loc split routing protocols are proposed for 287 usage here as in ILA [I-D.herbert-intarea-ila] and LISP 288 [I-D.ietf-lisp-rfc6830bis] [I-D.ietf-lisp-rfc6833bis] while the 289 topology of the cloud components and logical correlations shall be 290 invisible from outside. 292 In a cloud, an upstream IP address does not necessarily belong to the 293 actual service location, but a gateway or load balancer. So, the 294 locator or also ID reveal the location with the accuracy of a data 295 center, not the function taking a service request. This issue also 296 manifests itself in today's LTE as PGWs are in a data center binding 297 UEs' IP addresses which are from the network of the data center. 299 4.4. Vehicular Networks 301 In vehicular networks use cases (e.g. for a future C-ITS, i.e. 302 Cooperative Intelligent Transport Systems) there are some problems 303 related to privacy. Cars are mandated to beacon CAM messages 304 (cooperative awareness message - also denoted as basic service 305 message, BSM) very frequently (more than 1 per second). These 306 messages contain identifiers such as MAC addresses. They are unique 307 and visible in the public oui.txt file. They can be tracked. But 308 these are MAC addresses, not IP addresses. 310 If, in the future, cars beacon Router Advertisements as well, then 311 there is a risk in the source address of these RAs - the link local 312 (LL) address. They are usually formed out of the MAC address, even 313 though recent RFC7217 [RFC7217] give suggestion of using a random ID 314 in the IID (Interface Identifiers) (rather than the MAC address); the 315 RFC stays silent about the prefix length; since the RFC7217 method 316 covers also the LL addresses, and requires them to be RFC4291-like 317 (64bit length), that random ID is still of fixed length (64). Longer 318 than 64 IIDs may benefit privacy, since crypto attacks on them would 319 be harder. 321 A variable length IID in link-local addresses may help create a 322 flexible identifier-locator split thus increasing privacy. 324 In addition C-ITS shall also allow to improve vehicular network based 325 services as e.g. predict traffic congestion along the route and 326 propose a re-direction towards alternative routes, or predict network 327 coverage along the foreseen path to adapt a critical service. This 328 on the other hand demands for knowledge of the actual route, i.e. 329 tracking of the vehicle. As was shown in [NYC_cab] even anonymizing 330 sometimes does not prevent from privacy breaches. ... 332 Strong access control to ID/LOC mapping system(e.g. using longer and 333 variable length of IID, crypto-ID, etc.) has some tradeoffs between 334 enhancing privacy and increasing delay. Furthermore, in the 335 vehicular network, reducing delay is also very important issue 336 because vehicle moves too fast to have enough time to configure. 338 For V2V communication, using temporary identifier between two 339 vehicles can be one solution to prevent privacy. When we think of 340 the example for V2V communication, most of their data includes 341 current traffic condition, speed, or accident information which are 342 not related to identify their unique device information. 343 [I-D.ietf-lisp-eid-anonymity] can be one good solution to provide 344 anonymity. In [I-D.ietf-ipwave-vehicular-networking], they suggest 345 MAC address pseudonym in which MAC address is changed periodically. 347 5. PIdLoc Issues and Challenges 349 This section concludes on both common and specific issues and 350 challenges in PIdLoc to allow for derivation of requirements to 351 potential solutions serving for a gap analysis to be documented in 352 upcoming drafts, e.g. (I-D.xyz-pidloc-reqs). 354 6. IANA Considerations 356 TBD. 358 7. Security Considerations 360 TBD 362 8. Acknowledgements 364 9. References 366 [I-D.herbert-intarea-ila] 367 Herbert, T. and P. Lapukhov, "Identifier-locator 368 addressing for IPv6", draft-herbert-intarea-ila-01 (work 369 in progress), March 2018. 371 [I-D.ietf-intarea-tunnels] 372 Touch, J. and M. Townsley, "IP Tunnels in the Internet 373 Architecture", draft-ietf-intarea-tunnels-09 (work in 374 progress), July 2018. 376 [I-D.ietf-ipwave-vehicular-networking] 377 Jeong, J., "IP Wireless Access in Vehicular Environments 378 (IPWAVE): Problem Statement and Use Cases", draft-ietf- 379 ipwave-vehicular-networking-09 (work in progress), May 380 2019. 382 [I-D.ietf-lisp-eid-anonymity] 383 Farinacci, D., Pillay-Esnault, P., and W. Haddad, "LISP 384 EID Anonymity", draft-ietf-lisp-eid-anonymity-06 (work in 385 progress), April 2019. 387 [I-D.ietf-lisp-rfc6830bis] 388 Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. 389 Cabellos-Aparicio, "The Locator/ID Separation Protocol 390 (LISP)", draft-ietf-lisp-rfc6830bis-26 (work in progress), 391 November 2018. 393 [I-D.ietf-lisp-rfc6833bis] 394 Fuller, V., Farinacci, D., and A. Cabellos-Aparicio, 395 "Locator/ID Separation Protocol (LISP) Control-Plane", 396 draft-ietf-lisp-rfc6833bis-24 (work in progress), February 397 2019. 399 [I-D.ietf-lisp-sec] 400 Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. 401 Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-18 402 (work in progress), June 2019. 404 [I-D.nordmark-id-loc-privacy] 405 Nordmark, E., "Privacy issues in ID/locator separation 406 systems", draft-nordmark-id-loc-privacy-00 (work in 407 progress), July 2018. 409 [NYC_cab] Douriez, et al., M., "Anonymizing NYC Taxi Data: Does It 410 Matter?", Proc. of IEEE Intl. Conf. on Data Science and 411 Advanced Analytics (DSAA'16) , pp. 140-148, 2016. 413 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 414 Requirement Levels", BCP 14, RFC 2119, 415 DOI 10.17487/RFC2119, March 1997, 416 . 418 [RFC6740] Atkinson, RJ. and SN. Bhatti, "Identifier-Locator Network 419 Protocol (ILNP) Architectural Description", RFC 6740, 420 DOI 10.17487/RFC6740, November 2012, 421 . 423 [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, 424 "Locator/ID Separation Protocol Alternative Logical 425 Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836, 426 January 2013, . 428 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 429 Interface Identifiers with IPv6 Stateless Address 430 Autoconfiguration (SLAAC)", RFC 7217, 431 DOI 10.17487/RFC7217, April 2014, 432 . 434 [RFC8111] Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. 435 Smirnov, "Locator/ID Separation Protocol Delegated 436 Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111, 437 May 2017, . 439 Authors' Addresses 441 Dirk von Hugo 442 Deutsche Telekom 443 Deutsche-Telekom-Allee 7 444 D-64295 Darmstadt 445 Germany 447 Email: Dirk.von-Hugo@telekom.de 449 Behcet Sarikaya 450 Denpel Informatique 452 Email: sarikaya@ieee.org 454 Luigi Iannone 455 Telecom ParisTech 457 Email: ggx@gigix.net 459 Alex Petrescu 460 CEA, LIST 462 Email: alexandre.petrescu@gmail.com 463 Kyoungjae Sun 464 Soongsil University 466 Email: gomjae@dcn.ssu.ac.kr 468 Umberto Fattore 469 NEC 471 Email: Umberto.Fattore@neclab.eu