idnits 2.17.1 draft-padma-ideas-problem-statement-01.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 12, 2017) is 2596 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 4423 (ref. 'HIP-ARCH') (Obsoleted by RFC 9063) -- Obsolete informational reference (is this intentional?): RFC 6830 (Obsoleted by RFC 9300, RFC 9301) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 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: September 13, 2017 C. Jacquenet 6 Orange 7 M. Fioccola 8 Telecom Italia 9 A. Nennker 10 Deutsche Telekom 11 March 12, 2017 13 Problem Statement for Identity Enabled Networks 14 draft-padma-ideas-problem-statement-01 16 Abstract 18 The forthcoming deployment of 5G coupled with emerging applications 19 such as augmented reality, virtual reality and 8k videos are likely 20 to raise more stringent requirements in terms of ultra-low latency 21 while ensuring session continuity. The emergence of IoT services 22 also raises new challenges (with respect to their interoperability, 23 discovery, naming and addressing) which may lead to identity-based 24 designs. This problem statement examines how the existing solutions 25 for networks whose forwarding scheme assumes the decoupling between 26 the identifier and the locator information (called Identity Enabled 27 Networks) will struggle to meet such requirements. It advocates for 28 a standardized, secured common control plane with data integrity for 29 Identity Services such as identifier registration, mapping and 30 resolution. This memo also identifies several key areas to be 31 further investigated for the architecture design of these services. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on September 13, 2017. 50 Copyright Notice 52 Copyright (c) 2017 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Specification of Requirements . . . . . . . . . . . . . . . . 4 69 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 70 4. Brief Overview of ID Enabled Networks . . . . . . . . . . . . 5 71 4.1. Identifiers Role in a Communication Session . . . . . . . 6 72 4.2. Mapping/Resolution Services in GRIDS differ from Domain 73 Name Service (DNS) . . . . . . . . . . . . . . . . . . . 7 74 5. Key Problems . . . . . . . . . . . . . . . . . . . . . . . . 8 75 5.1. Common Control Plane Infrastructure . . . . . . . . . . . 8 76 5.2. Identifier Lifecycle . . . . . . . . . . . . . . . . . . 9 77 5.3. Security of Mapping Systems . . . . . . . . . . . . . . . 9 78 5.4. Distributed Denial of Service Attack Prone . . . . . . . 9 79 6. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 10 80 7. Relationship between IDEAS and other IETF Working Groups . . 10 81 7.1. LISP WG . . . . . . . . . . . . . . . . . . . . . . . . . 10 82 7.2. HIP WG . . . . . . . . . . . . . . . . . . . . . . . . . 10 83 7.3. NVO3 WG . . . . . . . . . . . . . . . . . . . . . . . . . 11 84 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 85 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 86 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11 87 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 88 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 89 12.1. Normative References . . . . . . . . . . . . . . . . . . 12 90 12.2. Informative References . . . . . . . . . . . . . . . . . 12 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 93 1. Introduction 95 The current Internet architecture was designed for an environment 96 very different from today's networks. The October 2006 IAB Routing 97 and Addressing Workshop [RFC4984] identified several future trends 98 and challenges. [RFC4984] suggests that a generic identifier- 99 locator separation would be a possible solution to support billions 100 of mobile devices without "bringing undue impact on global routing 101 scalability and stability". Indeed, the concept of identifier- 102 locator separation is key to meeting future trends and challenges. 103 At the same time, proposed solutions in this space do not currently 104 address all requirements. 106 The Routing Research Group (RRG) identified several identifier-based 107 solutions in [RFC6115]. The technique relies upon the decoupling of 108 the identifier from the locator and therefore the change of location 109 is transparent to higher layers. The changes of LOC are handled by 110 an infrastructure that maps the ID to the LOC. 112 As Machine to Machine (M2M) communications become more pervasive, IoT 113 devices are slated to be highly interconnected and unsupervised. As 114 these communications will most likely be unmonitored, there are 115 concerns regarding their discovery (privacy) , accessibility 116 (possible breach) and data integrity (confidentiality). Furthermore, 117 the multitude of diverse IoT devices using different communication 118 protocols may create siloed communications. The sheer number of IoT 119 devices expected to be deployed by 2020 will introduce new challenges 120 that may be overcome by using the infrastructure of Identifier-based 121 solutions. 123 The deployment of 5G network infrastructures coupled with 124 applications (such as augmented reality, virtual reality, 8k videos) 125 are also putting more constraints, such as ultra-low latency with 126 session continuity, on the underlying connectivity infrastructures 127 [GSMA1] [GSMA2]. Identifier-based protocols can support mobility 128 provided they have an efficient mapping service. 130 Furthermore the vision of Network Slicing, that is a fundamental 131 feature of the 5G systems, has evolved from a simple network overlay 132 concept to enabling dynamic multi-service and multi-tenancy support, 133 that transforms the networking perspective by abstracting, isolating 134 and separating logical network behaviors from the underlying physical 135 network resources. The generic architecture proposed by IDEAS 136 facilitates these applications, in particular the decoupling of the 137 entity identifier from the locator can also help to select the 138 optimal control plane and user plane as well as compose and allocate 139 virtualized network functions inside the core or radio access network 140 depending on the service requirements. In the same way, the 141 dynamically and on-demand virtual slices creation need an efficient 142 mapping service between entity identifier and locator. 144 This document examines the possible changes and improvements needed 145 to address these challenges in Identity Enabled Networks (IDEAS). 147 To provide some background, this memo gives a brief overview of what 148 are Identity Enabled Networks. Next, it describes the problem 149 statement and advocates for a standardized common control plane for 150 identity services, including identifier registration, mapping, and 151 resolution services. 153 Several key areas that should be investigated for the architecture 154 design of these services and how they interface with current and 155 future Identifier-aware protocols are listed. 157 The goal of the work proposed by this IDEAS initiative is to provide 158 a generic architecture that is scalable, extensible, robust, secure, 159 and flexible for future networks. 161 2. Specification of Requirements 163 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 164 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 165 document are to be interpreted as described in [RFC2119]. 167 3. Definition of Terms 169 Entity : An entity is a communication endpoint. It can be a 170 device, a node, or a (software) process, that needs to be 171 identified. An entity may have one or multiple identifiers 172 simultaneously. An entity is reached by the resolution of one or 173 more of its identifiers to one or more locators. 175 Entity Collection: A set of entities with its own identifier, 176 e.g., a multicast group, or an ad-hoc vehicular network that needs 177 to be uniquely identified (e.g., a train entity may represent a 178 Closed User Group (CUG) and may contain all the passengers' 179 devices that share the same fate for connectivity). 181 Identifier (ID): denotes information to unambiguously identify an 182 entity within a given scope. There is no constraint on the 183 format, obfuscation or routability of an ID. The ID may or may 184 not be present in the packet whose format is defined by ID-based 185 protocols. 187 Locator (LOC): denotes information that is topology-dependent and 188 which is used to forward packets to a given entity attached to a 189 network. An entity can be reached using one or multiple locators; 190 these locators may have a limited validity lifetime. 192 Identity: the essence of "being" of a specific entity. An 193 identity is not to be confused with an identifier: while an 194 identifier may be used to refer to an entity, an identifier's 195 lifecycle is not necessarily tied to the lifecycle of the identity 196 it is referencing. On the other hand, the identity's lifecycle is 197 inherently tied to the lifecycle of the entity itself. 199 IDentity Enabled Networks (IDEAS): IDEAS are networks that support 200 the identifier/locator decoupling. Reaching an entity is achieved 201 by the resolution of identifier(s) to locator(s). 203 Identifier-based (ID-based): When an entity is only reachable 204 through one or more communication access then a protocol or a 205 solution is said to be ID-based if it uses an ID-LOC decoupling 206 and a mapping system (MS) as base components of the architecture. 208 Identity-capable (ID-capable): An application is said to be ID- 209 capable if it makes use of an Identifier of an entity to establish 210 communication. For example, an application that initiates its 211 sessions using an ID. An application may use an IP-address as a 212 proxy for an ID if the network resolves this ambiguity. We regard 213 such an application as being ID-capable. 215 Generic Resilient Identity Services (GRIDS): GRIDS is a set of 216 services to manage the lifecycle of IDs, to map and resolve 217 identifiers and locators, and to associate metadata (META) with 218 entities and entity collections. It is a distributed system that 219 stores the ID, the associated LOC(s), and metadata (META) in the 220 form of tuples (ID, LOC, and META). 222 Metadata (META): is data associated with an Identity. The 223 metadata may contain information such as the nature of the entity 224 for example. 226 5G: Fifth generation wireless broadband technology [NEWS-3GPP]. 228 Scope: denotes the domain of applicability or usability of an ID. 229 A scope may be limited (e.g., considered local with geographic 230 proximity, or private within an administrative domain) or be 231 global. 233 4. Brief Overview of ID Enabled Networks 235 The proposals of separating the ID from the LOC are not new. 236 Location/Identifier Separation Protocol (LISP) [RFC6830] and 237 Identifier Locator Addressing [ILA] solutions have been deployed in 238 data centers (DC). Host Identity Protocol (HIP) [RFC7401] has been 239 deployed as a host-based solution. 241 The use of mobile devices with critical applications and fast 242 mobility introduce additional constraints to address the combination 243 of the following requirements: 245 a. Ultra-low latency [GSMA1][GSMA2] 247 b. Session continuity 249 c. Mobility across heterogeneous multi-access networks 251 d. Network Slicing 253 IoT device technologies introduce other constraints such as battery 254 life (up to ten year battery life for low power devices [GSMA2]) may 255 not allow connected devices to constantly signal their position or 256 limit the way they communicate. For example, in order to save energy 257 a pet tracker may have intermittent one-way communication just to 258 signal periodically its location. 260 As the number of personal devices increases, they may be grouped in a 261 cluster belonging to a closed user group or perhaps a class of 262 devices. There will be a need to identify such groups and register 263 them for multicasting or broadcasting. As the number of personal 264 devices increases, they may be grouped in various clusters or closed 265 user groups (depending on the nature of the IoT service and the need 266 to manage small communities on the fly) or perhaps a service-inferred 267 class of Devices (e.g., healthcare bracelets, heat sensors, infrared 268 CCTV, etc.). There will be a need to identify such groups and 269 clusters, and register them for multicasting or broadcasting purposes 270 (e.g., to optimize resource management when sending a set of 271 commands). Another example Energy management in smart cities may 272 send commands to all lampposts that belong to different groupings 273 (street or neighborhood). 275 Therefore, any ID/LOC separation solution will require an 276 infrastructure that secures registration, efficient discovery, and 277 can manage complex lookups(e.g. all cameras of a brand in a factory 278 floor) as well mapping/resolution services. 280 4.1. Identifiers Role in a Communication Session 282 The IDentity Enabled networkS (IDEAS) intend to define the use of 283 Identifiers (ID) as follows: 285 o An ID is a way to identify communication endpoints of an entity. 286 The ID of an entity abstracts its communication endpoints from its 287 location. There is a distinction as well that the ID to a locator 288 address mapping is a way to reach the entity but not tied to a 289 specific interface address on the device itself. 291 o Even though IDs may be sent inside a packet, they may be encrypted 292 (or not) and may not be globally routable. 294 o A single entity may have multiple IDs, and IDs of the same entity 295 may have different life spans that are different from the lifespan 296 of the entity. Furthermore, it is understood that IDs may have 297 different lifecycles, which may be permanent or ephemeral by 298 choice or design. 300 o Ephemeral (temporary) IDs may be used as a short-lived pseudonym 301 for a permanent ID to protect the privacy of the related entity. 303 o Involved entities may have multiple IDs that are used to initiate 304 a communication . Specifically, they are not just passive objects 305 that need to be referenced and located in the Internet, but are 306 live endpoints that may initiate a session while in motion or not. 308 o Finally, entities with these IDs may be moving over large 309 geographical distances and across multiple administrative domains. 310 Therefore, there is no guarantee that they will retain their IP 311 address. 313 4.2. Mapping/Resolution Services in GRIDS differ from Domain Name 314 Service (DNS) 316 The resolution of the ID into a locator is often mistaken as a NAT- 317 like translation or even a DNS type of indirection. Since the 1980s, 318 DNS has been pivotal to translate human readable names that are easy 319 to remember into hard-to-remember IP addresses. It provides a global 320 distributed directory service and is a very powerful and useful 321 technology to translate the domain name hierarchy to IP address 322 space. ]. The use of DNS, as is, is therefore unlikely to meet the 323 challenges posed to GRIDS. 325 Even though the DNS was designed to be resilient, it is prone to DDOS 326 attacks as discussed extensively in the Technical Plenary of IETF97. 327 Furthermore, some studies have also described challenges in the 328 response time and caching techniques and latency in the Internet 329 [DNS1] [DNS2] [DNS3]. The use of a mapping system rather than using 330 DNS system has been discussed extensively in [IVIP], [RFC6115] and on 331 the lisp-wg mailing list [LISP-DIS]. 333 5. Key Problems 335 5.1. Common Control Plane Infrastructure 337 Today, most locator/identifier separation solutions rely on a control 338 plane that resolves an ID to one or multiple locators. Eventually, 339 the control plane may be used to define other policies that are 340 enforced by the devices that participate to the delivery and the 341 operation of a connectivity service. These solutions implement their 342 own resolution methods. The resolution service may leverage push- 343 based protocols (traditional routing protocols and [LISP-SUBS]), 344 pull-based control planes (DNS and LISP), third party software, or 345 any combination thereof. 347 Currently, each of the ID-based protocols uses its own specific 348 mapping databases. While ID-enabled data plane mechanisms may serve 349 fundamentally different objectives and may not need to interoperate 350 in the past, there is a potential benefit in providing them with a 351 common interface for services such as registration, discovery, update 352 and resolution and new services such as security or access control 353 policy. Furthermore, the lack of a mapping system with standardized 354 invocation interfaces has the following downsides: 356 a. An impediment for the deployment of ID-enabled solutions. 357 Indeed, it would be inefficient to deploy several specialized 358 mapping/resolution network databases within the same 359 administrative domain. Furthermore, there will be additional 360 expense and overhead to administer multiple proprietary mapping 361 systems. 363 b. Difficulty to have an overall view of the network. If multiple 364 ID-enabled solutions with distinct mapping systems are deployed, 365 troubleshooting may be difficult as the information may be 366 located in different places. 368 c. Complex Management due to disjoint information spread over 369 several mapping systems. Operations such as merging networks are 370 error prone and more challenging to detect and fix. 371 Additionally, there will be considerable management overhead 372 whenever devices migrate. 374 d. Barriers to the application of common and consistent policies. 375 For example, in cross-platform IoT networking, brokering services 376 may be needed to enforce routing/security/QoS/TE policies on 377 behalf of partnering structures - service provider, energy 378 provider, content provider, etc. 380 e. Risk for fragmented connectivity. A high diversity of mapping 381 system variants will create silos of communications. 383 f. Complex cross-MS communications. A common resolution system 384 infrastructure may facilitate cross-MS communications. Today it 385 is difficult to communicate with multiple customized ID mapping 386 systems with distinct interfaces. 388 The common control plane may support limited or private scopes. In 389 addition support of private instances provides the necessary 390 separation for specific users or applications. 392 The emergence of dynamic (small-sized) communities or closed, on-the- 393 fly, user groups puts additional pressure on the mapping system, from 394 several standpoints that include robustness, availability, 395 scalability and reliability. 397 5.2. Identifier Lifecycle 399 Currently, there is no guidance or allocation scheme for public IDs. 400 Each protocol has historically assigned their ID independently, be it 401 structured or not. An agreed upon ID format and scope may facilitate 402 cross-domain communication and simplify the implementation of some 403 use cases to facilitate cross-silo communications or to better 404 address the merging of networks 406 The support of several allocation schemes by carving specific ranges 407 within a name space and recycling should be explored for the future 408 mapping systems. The operations and ease of deployment should also 409 be considered as they may influence policy enforcement schemes 410 related to the allocation of IDs of the use of relevant metadata. 412 5.3. Security of Mapping Systems 414 As access to a mapping system may reveal the location and other 415 sensitive information about an ID, any breach is therefore considered 416 a security risk. 418 Secured access and data integrity to current mapping systems may not 419 be guaranteed. It is possible to register erroneous information in 420 some cases if the system is under attack [LISP-SEC]. Similarly, in 421 the absence of DNSSEC, HIP RR is vulnerable [RFC8005]. 423 5.4. Distributed Denial of Service Attack Prone 425 The DNS system is vulnerable to DDOS attacks. The HIP protocol 426 relies on DNS for the publication of public Host Identifier 427 [HIP-ARCH]. 429 The other current mapping systems are not specifically designed to be 430 protected against a DDOS attack. This is a potential issue as they 431 have well-known IP addresses and registration depends on their 432 reachability. 434 6. Use Cases 436 The use cases are discussed in detail in [IDEAS-USE]. 438 7. Relationship between IDEAS and other IETF Working Groups 440 This document is meant to encourage the IETF community to investigate 441 the opportunity of a new specification effort to address some 442 specific problems from an ID Enabled Networks standpoint in general. 443 The focus is to find a common solution and infrastructure that can be 444 shared by current protocols and facilitate the introduction of new 445 ID-based services while avoiding rehashing the same problems again 446 each time a new service pops up. 448 It proposes to address these problems with a Generic Resilient ID 449 Services infrastructure which includes standardized access and 450 multiple services. The services include secured registration, 451 discovery, updates with data integrity, mapping and resolution 452 capabilities, define relationships between IDs or group of IDs, 453 access control policy and security. 455 Some other working groups are already working to address some 456 specific limitations or enhancement of ID-capable protocols. These 457 working groups include LISP, HIP and NVO3. 459 Protocols and architectures defined by these WGs may assume a mapping 460 system or other resolution techniques, but they are not currently 461 covering the other services mentioned in this document. 463 7.1. LISP WG 465 The LISP WG has been working on multiple mapping systems (ALT, DDT) 466 for the LISP control plane and the primary function of this mapping 467 system is to map and resolve the ID to IP addresses (EID/RLOC 468 mapping). Though some requirements are common, GRIDS has new 469 specific requirements that are described in [IDEAS-REQ]. 471 7.2. HIP WG 473 The HIP WG has based its resolution service on DNS and sections 4.2, 474 5.3 and 5.4 of this document describe some of the vulnerabilities of 475 this solution to address the requirement for fast mobility with low 476 latency. 478 7.3. NVO3 WG 480 The NV03 WG has been working on a mapping of VN names to VN IDs in 481 the network virtualization space and their requirements differ from 482 the wireless broadband requirements and cross-silo communications 483 that have been mentioned in this document. 485 8. Security Considerations 487 Due to the sensitivity of Identity tied to identifier and locator, 488 there is a need to pay attention to security ramifications. In 489 particular, the security goals should include confidentiality, 490 possible encryption for integrity of sensitive data and privacy. 491 Various aspects of security and the security requirements for IDEAS 492 are discussed in TBD document. 494 9. IANA Considerations 496 This document has no actions for IANA. 498 10. Contributors 500 This present document is based on an extract of the first version of 501 the draft. The authors and their affiliations on the original 502 document are: D. Farinacci (lispers.net), D. Meyer (Brocade), D. 503 Lake (Cisco Systems), T. Herbert (Facebook), M. Menthe (University 504 of Tuebingen), Dipenkar Raychaudhuri (Rutgers University), Julius 505 Mueller (ATT) and Padma Pillay-Esnault (Huawei). 507 There are two companion documents also extracted from the -00 version 508 of this document: Problem Statement in IDEAS [IDEAS-USE] and GRIDS 509 Requirements [IDEAS-REQ]. 511 The following individuals substantially contributed to this document: 513 o Georgios Karagiannis 515 o Alex Clemm 517 o Uma Chunduri 519 11. Acknowledgments 521 The authors would like to thank Alex Clemm, Uma Chunduri, Georgios 522 Karagiannis, Stewart Bryant, Michael Menth, Liu Bingyang, Yingzhen Qu 523 and Onur Ozan Koyluoglu for their review and input on this document. 524 The authors would like to thank Renwei Li, Jeff Tansura, Burjiz 525 Pithawala, Lin Han and Kiran Makhijani and Jean-Michel Esnault who 526 participated in numerous discussions. 528 This document was produced using Marshall Rose's xml2rfc tool. 530 12. References 532 12.1. Normative References 534 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 535 Requirement Levels", BCP 14, RFC 2119, 536 DOI 10.17487/RFC2119, March 1997, 537 . 539 12.2. Informative References 541 [DNS1] Jung, J., Sit, E., Balakrishnan, H., and R. Morris, "DNS 542 Performance and the Effectiveness of Caching", 2002, 543 . 545 [DNS2] Liston, R., Srinivasan, S., and E. Zegura, "DNS 546 Performance and the Effectiveness of Caching", 2002, 547 . 550 [DNS3] Briscoe, B., Anna Brunstrom, A., Andreas Petlund, A., 551 David Hayes, D., David Ros, D., Ing-Jyh Tsang, I., Stein 552 Gjessing, S., Gorry Fairhurst, G., Carsten Griwodz, C., 553 and M. Michael Welzl, "Reducing Internet Latency: A Survey 554 of Techniques and their Merits", November 2014, 555 . 557 [GSMA1] GSMA, "Unlocking Commercial Opportunities From 4G 558 Evolution to 5G", February 2016, 559 . 562 [GSMA2] GSMA, "Understanding 5G: Perspectives on future 563 technological advancements in mobile", December 2014, 564 . 567 [HIP-ARCH] 568 Moskowitz, R. and M. Komu, "An Architectural Introduction 569 to the Locator/ID Separation Protocol", November 2016, 570 . 573 [IDEAS-REQ] 574 Pillay-Esnault, P., Clemm, A., Farinacci, D., and D. 575 Meyer, "Requirements for Generic Resilient Identity 576 Services in Identity Enabled Networks", March 2017, 577 . 580 [IDEAS-USE] 581 Pillay-Esnault, P., Farinacci, D., Herbert, T., Jacquenet, 582 C., Lake, D., Menth, M., Meyer, D., and D. Raychaudhuri, 583 "Use Cases for Identity Enabled Networks", March 2017, 584 . 587 [ILA] Herbert, T., "Identifier-locator addressing for network 588 virtualization", March 2016, 589 . 592 [IVIP] Whittle, R., "Ivip (Internet Vastly Improved Plumbing) 593 Architecture", September 2010, 594 . 596 [LISP-DIS] 597 "LISP Discussion", . 600 [LISP-SEC] 601 Maino, F., Ermagan, V., Cabellos, A., and D. Saucez, 602 "LISP-Security", November 2016, 603 . 605 [LISP-SUBS] 606 Boucadair, M. and C. Jacquenet, "LISP Subscription", 607 February 2017, . 610 [NEWS-3GPP] 611 3GPP, "3GPP News", 612 . 614 [RFC4984] Meyer, D., Ed., Zhang, L., Ed., and K. Fall, Ed., "Report 615 from the IAB Workshop on Routing and Addressing", 616 RFC 4984, DOI 10.17487/RFC4984, September 2007, 617 . 619 [RFC6115] Li, T., Ed., "Recommendation for a Routing Architecture", 620 RFC 6115, DOI 10.17487/RFC6115, February 2011, 621 . 623 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 624 Locator/ID Separation Protocol (LISP)", RFC 6830, 625 DOI 10.17487/RFC6830, January 2013, 626 . 628 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 629 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 630 RFC 7401, DOI 10.17487/RFC7401, April 2015, 631 . 633 [RFC8005] Laganier, J., "Host Identity Protocol (HIP) Domain Name 634 System (DNS) Extension", RFC 8005, DOI 10.17487/RFC8005, 635 October 2016, . 637 Authors' Addresses 639 Padma Pillay-Esnault (editor) 640 Huawei 641 2330 Central Expressway 642 Santa Clara, CA 95050 643 USA 645 Email: padma.ietf@gmail.com 647 Mohamed Boucadair 648 Orange 649 Rennes 35000 650 France 652 Email: mohamed.boucadair@orange.com 654 Christian Jacquenet 655 Orange 656 Rennes 35000 657 France 659 Email: christian.jacquenet@orange.com 660 Giuseppe Fioccola 661 Telecom Italia 663 Email: giuseppe.fioccola@telecomitalia.it 665 Axel Nennker 666 Deutsche Telekom 668 Email: Axel.Nennker@telekom.de