idnits 2.17.1 draft-padma-ideas-problem-statement-03.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 3, 2017) is 2489 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 6830 (Obsoleted by RFC 9300, RFC 9301) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Pillay-Esnault, Ed. 3 Internet-Draft Huawei 4 Intended status: Informational M. Boucadair 5 Expires: January 4, 2018 Orange 6 G. Fioccola 7 Telecom Italia 8 C. Jacquenet 9 Orange 10 A. Nennker 11 Deutsche Telekom 12 July 3, 2017 14 Problem Statement for Identity Enabled Networks 15 draft-padma-ideas-problem-statement-03 17 Abstract 19 This problem statement examines how existing protocols that separate 20 identifiers from their location may benefit from the concept of 21 identity. The proposal laid out herein advocates for a standardized 22 identity/identifier network infrastructure that provides a framework 23 to support identity services in addition to enhancing existing 24 identifier/location mapping and resolution services. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on January 4, 2018. 43 Copyright Notice 45 Copyright (c) 2017 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 62 3. Key Problems . . . . . . . . . . . . . . . . . . . . . . . . 5 63 3.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 3.1.1. Tracking Prevention . . . . . . . . . . . . . . . . . 5 65 3.1.2. Privacy against Eavesdroppers . . . . . . . . . . . . 5 66 3.1.3. Identifier Right to be Forgotten . . . . . . . . . . 6 67 3.2. Common Infrastructure and Primitives . . . . . . . . . . 6 68 3.3. Allocation Schemes Guidance . . . . . . . . . . . . . . . 7 69 4. Scopes . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 4.1. In Scope . . . . . . . . . . . . . . . . . . . . . . . . 7 71 4.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . . 8 72 4.3. Future Studies . . . . . . . . . . . . . . . . . . . . . 8 73 5. Relationship between IDEAS and other IETF Working Groups . . 8 74 5.1. LISP WG . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 5.2. HIP WG . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 5.3. NVO3 WG . . . . . . . . . . . . . . . . . . . . . . . . . 9 77 6. Companion Documents . . . . . . . . . . . . . . . . . . . . . 9 78 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 79 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 80 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 81 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 82 11. Informative References . . . . . . . . . . . . . . . . . . . 10 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 85 1. Introduction 87 While the separation of identifier from the location is not a new 88 concept, existing solutions such as Host Identity Protocol (HIP) 89 [RFC7401] , Location/Separation Protocol (LISP) [RFC6830] and 90 Identifier-Locator Addressing (ILA) [ILA] for IPv6, may benefit from 91 a higher layer abstraction that separates the identity of an entity 92 from its associated identifier(s). 94 In identifier and Location split protocols, identifiers (IDf) are 95 used for decoupling the identifier and the location information at 96 the network layer. Typically, a IDf represents an end-point 97 communication tied to an entity. Usually, IDfs are long-lived and 98 may or may not be routable. However, locators (LOC) may be transient 99 and associated with the location of the entity. The LOCs are 100 routable network addresses (e.g. IPv4, IPv6 addresses). The IDfs 101 are mapped to LOCs for forwarding purposes. Modification of LOC 102 information is handled by an a mapping system that updates the IDf/ 103 LOC mappings. 105 In order to communicate with a device, the initiator relies on a 106 mapping system that is designed to process lookup requests on a 107 network IDf and return the LOC(s). While the mapping system fulfills 108 its functionality, this mode of operation has some drawbacks. 110 The entities update the system with their (IDf,LOC) bindings. In 111 some cases, it may register the LOC of a forwarding element such as a 112 proxy or HIP Rendezvous Server. Regardless, it is assumed that once 113 the entities have registered their (IDF,LOC(s)) tuple to the system, 114 this information is available to all with access to the mapping 115 system. Any request for this information would then be readily 116 available without any discrimination. For example, a public entity 117 needs to have its IDf public to be discovered by clients. However, 118 it might not be always desirable that some devices (e.g. home 119 cameras) are visible to all without any control. 121 Privacy and security requirements of entities suggest the use of some 122 mechanism to authenticate entities that can dynamically discover them 123 and prevent unwanted communication. In existing architectures it is 124 possible to authenticate IDf, however they are not permanently 125 attached to the entity. This is crucial in a multi-provider and/or 126 multi-domain scenario, related for example to a complex end-to-end 127 service. 129 Therefore the concept of an identity(IDy) tied to an entity and to 130 its lifecycle should be considered. The IDy is intended to be used 131 for identifying and authenticating an entity. Likewise, the IDy 132 information should not be carried in clear in packet headers. The 133 Section 3 of this document will describe how this IDy may be used. 135 Furthermore, it would be beneficial to generalize this Identity 136 concept across protocols that may benefit from it. Therefore there 137 is a need for a system which shares some common control plane for 138 services commonly used such as look-ups or updates. 140 This document examines the possible changes and improvements needed 141 to address these challenges in Identity Enabled networkS (IDEAS). It 142 describes the problem statement and advocates for a standardized 143 extensible common control plane for IDf/LOC protocols that supports: 145 Identity services (including registration and authentication) 147 Management of access credentials based on IDy 149 Look-ups with restrictions 151 Mapping, and resolution services on IDfs 153 2. Definition of Terms 155 Entity: An entity is a communication endpoint. It can be a 156 device, a node, or a (software) process, that needs to be 157 identified and locatable/reachable. Such entity will have one or 158 more communication interfaces. An entity may have multiple IDfs 159 simultaneously that are NOT associated with any particular 160 interface(s). It is reached by the resolution of one or more of 161 its IDfs to one or more LOCs. 163 Identity (IDy): The essence of "being" of a specific entity. An 164 IDy is not to be confused with an IDf: while an IDf may be used to 165 refer to an entity, an IDf's lifecycle is not necessarily tied to 166 the lifecycle of the IDy it is referencing. On the other hand, 167 the IDy's lifecycle is inherently tied to the lifecycle of the 168 entity itself. 170 Identifier (IDf): An IDf denotes information to unambiguously 171 identify an entity or an entity group within a given scope. An 172 IDf is the equivalent of an End point identifier (EID) in LISP or 173 Host Identity Tag (HIT) in HIP. It may be visible in 174 communications. 176 Locator (LOC): A locator is a routable network address. It may be 177 associated with an IDf and used for communication on the network 178 layer according to LOC/IDf split principle. A LOC is the 179 equivalent of a Routing Locator (RLOC) in LISP or an IP address in 180 HIP. 182 Metadata (META): Data associated with an IDy and its IDfs in the 183 framework. The metadata is to be used for storing long-lived slow 184 changing information such as the nature of the entity (e.g. camera 185 or phone). 187 IDy/IDf mapping: One IDy may be associated to multiple IDfs. The 188 IDfs are mapped to one IDy. 190 Identifier-based: When an entity is only reachable through one or 191 more communication access then a protocol or a solution is said to 192 be identifier-based if it uses an ID-LOC decoupling and a mapping 193 system (MS) as base components of the architecture. 195 GeneRic Identity Services (GRIDS): GRIDS is a set of services to 196 manage the lifecycle of ID[y|f]s, to map and resolve IDfs and 197 LOCs, and to associate META with entities. It is a distributed 198 system that stores the IDy, IDf, the associated LOC(s), and META 199 in the form of tuples (ID, LOC, and META). Meta queries are 200 supported and queries are restricted to authenticated and 201 authorized IDys. 203 IDentity Enabled Networks (IDEAS): IDEAS are networks that support 204 the IDf/IDy decoupling as well as IDf /LOC decoupling using GRIDS. 205 Reaching an entity is achieved by the resolution of IDf(s) to 206 LOC(s). 208 Scope: Domain of applicability or usability of an IDfs and IDys. 209 The scope may be global or limited, e.g., considered local with 210 geographic proximity or private within an administrative domain. 212 3. Key Problems 214 3.1. Privacy 216 3.1.1. Tracking Prevention 218 Access to a mapping system may reveal the location and other 219 sensitive information about an entity to the requestor of a look-up 220 on an IDf. Repeated look-ups on the mapping system may be misused 221 for tracking IDfs of an entity or mount an attack. 223 To preserve its privacy, the entity or infrastructure may restrict 224 access for look-ups for certain IDfs or IDys or entity with specific 225 meta. (E.g. nature of an entity stored in meta as a camera). 227 Currently, even if look-ups on the mapping systems were modified not 228 to return a result if the requestor is barred, it would be easily 229 defeated if the requestor changes its IDf. However, if all IDfs of 230 an entity are associated with the IDy, then the requestor entity 231 cannot easily defeat the aforementioned filtering rule by just 232 changing its IDf. 234 3.1.2. Privacy against Eavesdroppers 236 Eavesdroppers may observe the traffic and deduce the flows between 237 two IDfs or entities. To protect its privacy, an entity may choose 238 additional temporary IDfs for communications. 240 However, this mechanism makes discovery difficult and the entity must 241 at least have a long-lived IDf for this purpose. 243 The use of obfuscation is another solution to protect the source and 244 destination IDf however this implies extra processing or DPI for 245 functionalities such as late binding. 247 The use of IDy as an indirection to the actual IDfs used on the wire 248 present the advantage of having the source and destination ephemeral 249 IDfs in clear but authorized use may still maps these to the IDy. 250 The IDy of an entity must not be revealed in packets. Therefore, 251 encrypting the control plane mechanisms (requests and replies) is 252 required to avoid eavesdroppers to deduce who are the peers of 253 communication flows. 255 3.1.3. Identifier Right to be Forgotten 257 The control of the IDy/IDf mappings can restrict access to selected 258 requesting IDys/IDfs and also limit that access over time to 259 implement an "identifier right to be forgotten". 261 The advantage of this method is that entities may use IDfs for 262 communication to better protect their IDy. Only authorized 263 communication partners can find out the corresponding IDys. The 264 concept of IDy proposed by IDEAS helps to provide privacy in 265 communication in a similar way as IPv6 privacy extension minimizes 266 the risk of being tracked by a stable MAC address. To that end, 267 access restriction is needed for mapping system requests that also 268 need to be encrypted to avoid eavesdropping. 270 3.2. Common Infrastructure and Primitives 272 Currently, each of the IDf-based protocols uses its own specific 273 mapping databases. While IDf-based data plane mechanisms may serve 274 fundamentally different objectives and may not need to interoperate, 275 there is a potential benefit in providing them with a common 276 interface for common services such as IDy/IDf registration, 277 discovery, update, resolution and access control policy. 278 Furthermore, the lack of a common infrastructure with standardized 279 invocation interfaces has the following downsides: 281 a. An impediment for the deployment of IDf-based. Indeed, it would 282 be inefficient to deploy several specialized mapping/ resolution 283 network databases within the same administrative domain. 284 Furthermore, there will be additional expense and overhead to 285 administer multiple proprietary mapping systems. 287 b. Difficulty to have an overall view of the network. If multiple 288 IDf-based solutions with distinct mapping systems are deployed, 289 troubleshooting may be difficult as the information may be 290 located in different places. 292 c. Complex Management due to disjoint information spread over 293 several mapping systems. Operations such as merging networks are 294 error prone and more challenging to detect and fix. 295 Additionally, there will be considerable management overhead 296 whenever devices migrate. 298 d. Barriers to the enforcement of common and consistent policies. 299 For example, in cross-platform IoT networking, brokering services 300 may be needed to enforce routing/security/QoS/TE policies on 301 behalf of partnering structures - service provider, energy 302 provider, content provider, etc. 304 The common infrastructure may be supported within limited or private 305 scopes. In addition support of private instances provides the 306 necessary separation for specific users or applications. 308 3.3. Allocation Schemes Guidance 310 Currently, there is no consistent guidance or allocation scheme for 311 non-IP address format public IDfs across all protocols. Each 312 protocol has historically assigned their IDfs independently, be it 313 structured or not. An agreed scheme or a collision detection 314 mechanism within a scope may facilitate cross-domain communication in 315 the future. This would simplify the implementation of some use cases 316 to facilitate cross-silo communications or to better address the 317 merging of networks. 319 The support of several allocation schemes by carving specific ranges 320 within a name space and recycling should be explored for the future 321 mapping systems. The operations and ease of deployment should also 322 be considered as they may influence policy enforcement schemes 323 related to the allocation of IDfs of the use of relevant META. 325 4. Scopes 327 4.1. In Scope 329 The scope of this work is on the network layer (layer 3). The 330 network identities that may be alphanumerical are assumed to map to 331 numerical IDfs as in LISP, HIP or ILA. The LOCs are assumed to be 332 IPv4 or IPv6 addresses. 334 The META is assumed to be tied to the IDy or IDf and slow changing. 336 While the issues described in the document may be generalized to a 337 broader scope, IDEAS is focused on delivering functionalities at the 338 network layer only. 340 4.2. Out of Scope 342 The following are out of scope for this effort: 344 o The resolution or mapping of domain names or any application level 345 naming or directories (like URIs ...). 347 o META information with rapid changes 349 4.3. Future Studies 351 Other network addressing schemes may be considered for future 352 studies. 354 5. Relationship between IDEAS and other IETF Working Groups 356 This document is meant to encourage the IETF community to investigate 357 the opportunity of a new specification effort to address some 358 specific problems from an IDy Enabled Networks standpoint in general. 359 The focus is to find a common solution and infrastructure that can be 360 shared by current protocols and facilitate the introduction of new 361 IDy-based services while avoiding rehashing the same problems again 362 each time a new service pops up. 364 We propose to address these problems with a GeneRic IDentity Services 365 (GRIDS) infrastructure which includes standardized access and 366 multiple services. The services include secured registration, 367 discovery, updates with data integrity, mapping and resolution 368 capabilities, define relationships between identities or group of 369 identities, access control policy and security. 371 Some other working groups are already working to address some 372 specific limitations or enhancement of identifier-based protocols but 373 do not take IDy requirements as highlighted in this document into 374 consideration. These working groups include LISP, HIP and NVO3. 376 Protocols and architectures defined by these WGs may assume a mapping 377 system or other resolution techniques, but they are not currently 378 covering the other services mentioned in this document. 380 5.1. LISP WG 382 The LISP WG has been working on multiple mapping systems (ALT, DDT) 383 for the LISP control plane and the primary function of this mapping 384 system is to map and resolve the IDf to IP addresses (EID/RLOC 385 mapping). LISP WG is also looking at Casssandra and blockchain. 386 Though some requirements are common,GRIDS has new specific 387 requirements described in [IDEAS-REQ]. 389 5.2. HIP WG 391 The HIP WG has based its IDy to IDf resolution service on DNS. 392 Operational IDf to Loc for fast mobility with low latency is handled 393 by HIP-RVS [RFC8005] and specific HIP Mobility Notification messaging 394 [RFC8046]. 396 5.3. NVO3 WG 398 The NV03 WG has been working on a mapping of VN names to VN IDs in 399 the network virtualization space and their requirements differ from 400 the wireless broadband requirements and cross-silo communications 401 that have been mentioned in this document. 403 6. Companion Documents 405 There are three companion documents: 407 o Use Cases for Identity Enabled Networks [IDEAS-USE] 409 o Requirements for Generic Identity Services in Identity Enabled 410 Networks [IDEAS-REQ] 412 o Identity Use Cases in IDEAS [IDEAS-IDY] 414 o Gap Analysis for Identity Enabled Networks [IDEAS-GAP] 416 7. Security Considerations 418 Due to the sensitivity of IDy tied to IDf and LOC, there is a need to 419 pay attention to security ramifications. In particular, the security 420 goals should include confidentiality, possible encryption for 421 integrity of sensitive data and privacy. 423 8. IANA Considerations 425 This document has no actions for IANA. 427 9. Contributors 429 The following individuals (by first name alphabetical order) have 430 contributed to this document: 432 o Albert Cabellos 434 o Alex Clemm 436 o Dino Farinacci 438 o Georgios Karagiannis 440 o Jim Guichard 442 o Michael Menth 444 o Robert Moskowitz 446 o Tom Herbert 448 o Uma Chunduri 450 This present document is based on an extract of the first version of 451 the draft. The authors and their affiliations on the original 452 document are: D. Farinacci (lispers.net), D. Meyer (Brocade), D. 453 Lake (Cisco Systems), T. Herbert (Facebook), M. Menth (University 454 of Tuebingen), Dipenkar Raychaudhuri (Rutgers University) and Julius 455 Mueller (ATT). 457 10. Acknowledgments 459 The authors would like to thank Stewart Bryant, David Lake, Bingyang 460 Liu, Dave Meyer, Dipenkar Raychaudhuri, Yingzhen Qu, and Onur Ozan 461 Koyluoglu for their review and input on this document. The authors 462 would like to thank Jean-Michel Esnault, Renwei Li, Lin Han, Kiran 463 Makhijani Erik Nordmark, Burjiz Pithawala, and Jeff Tansura who 464 participated in numerous discussions. 466 This document was produced using Marshall Rose's xml2rfc tool. 468 11. Informative References 470 [IDEAS-GAP] 471 Qu, Y., Cabellos, A., Moskowitz, R., Liu, B., and A. 472 Stockmayer, "Identity Use Cases in IDEAS", July 2017, 473 . 476 [IDEAS-IDY] 477 Chunduri, U., Clemm, A., and M. Menth, "Identity Use Cases 478 in IDEAS", June 2017, . 481 [IDEAS-REQ] 482 Pillay-Esnault, P., Clemm, A., Farinacci, D., and D. 483 Meyer, "Requirements for Generic Resilient Identity 484 Services in Identity Enabled Networks", March 2017, 485 . 488 [IDEAS-USE] 489 Pillay-Esnault, P., Farinacci, D., Herbert, T., Jacquenet, 490 C., Lake, D., Menth, M., Meyer, D., and D. Raychaudhuri, 491 "Use Cases for Identity Enabled Networks", March 2017, 492 . 495 [ILA] Herbert, T., "Identifier-locator addressing for network 496 virtualization", March 2016, 497 . 500 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 501 Locator/ID Separation Protocol (LISP)", RFC 6830, 502 DOI 10.17487/RFC6830, January 2013, 503 . 505 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 506 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 507 RFC 7401, DOI 10.17487/RFC7401, April 2015, 508 . 510 [RFC8005] Laganier, J., "Host Identity Protocol (HIP) Domain Name 511 System (DNS) Extension", RFC 8005, DOI 10.17487/RFC8005, 512 October 2016, . 514 [RFC8046] Henderson, T., Ed., Vogt, C., and J. Arkko, "Host Mobility 515 with the Host Identity Protocol", RFC 8046, 516 DOI 10.17487/RFC8046, February 2017, 517 . 519 Authors' Addresses 520 Padma Pillay-Esnault (editor) 521 Huawei 522 2330 Central Expressway 523 Santa Clara, CA 95050 524 USA 526 Email: padma.ietf@gmail.com 528 Mohamed Boucadair 529 Orange 530 Rennes 35000 531 France 533 Email: mohamed.boucadair@orange.com 535 Giuseppe Fioccola 536 Telecom Italia 538 Email: giuseppe.fioccola@telecomitalia.it 540 Christian Jacquenet 541 Orange 542 Rennes 35000 543 France 545 Email: christian.jacquenet@orange.com 547 Axel Nennker 548 Deutsche Telekom 550 Email: Axel.Nennker@telekom.de