Network Working Group P. Pillay-Esnault, Ed. Internet-Draft Huawei Intended status: Informational M. Boucadair Expires: September 13, 2017 C. Jacquenet Orange M. Fioccola Telecom Italia A. Nennker Deutsche Telekom March 12, 2017 Problem Statement for Identity Enabled Networks draft-padma-ideas-problem-statement-01 Abstract The forthcoming deployment of 5G coupled with emerging applications such as augmented reality, virtual reality and 8k videos are likely to raise more stringent requirements in terms of ultra-low latency while ensuring session continuity. The emergence of IoT services also raises new challenges (with respect to their interoperability, discovery, naming and addressing) which may lead to identity-based designs. This problem statement examines how the existing solutions for networks whose forwarding scheme assumes the decoupling between the identifier and the locator information (called Identity Enabled Networks) will struggle to meet such requirements. It advocates for a standardized, secured common control plane with data integrity for Identity Services such as identifier registration, mapping and resolution. This memo also identifies several key areas to be further investigated for the architecture design of these services. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 13, 2017. Pillay-Esnault, et al. Expires September 13, 2017 [Page 1] Internet-Draft March 2017 Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Specification of Requirements . . . . . . . . . . . . . . . . 4 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 4. Brief Overview of ID Enabled Networks . . . . . . . . . . . . 5 4.1. Identifiers Role in a Communication Session . . . . . . . 6 4.2. Mapping/Resolution Services in GRIDS differ from Domain Name Service (DNS) . . . . . . . . . . . . . . . . . . . 7 5. Key Problems . . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Common Control Plane Infrastructure . . . . . . . . . . . 8 5.2. Identifier Lifecycle . . . . . . . . . . . . . . . . . . 9 5.3. Security of Mapping Systems . . . . . . . . . . . . . . . 9 5.4. Distributed Denial of Service Attack Prone . . . . . . . 9 6. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7. Relationship between IDEAS and other IETF Working Groups . . 10 7.1. LISP WG . . . . . . . . . . . . . . . . . . . . . . . . . 10 7.2. HIP WG . . . . . . . . . . . . . . . . . . . . . . . . . 10 7.3. NVO3 WG . . . . . . . . . . . . . . . . . . . . . . . . . 11 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 12.1. Normative References . . . . . . . . . . . . . . . . . . 12 12.2. Informative References . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 1. Introduction The current Internet architecture was designed for an environment very different from today's networks. The October 2006 IAB Routing and Addressing Workshop [RFC4984] identified several future trends Pillay-Esnault, et al. Expires September 13, 2017 [Page 2] Internet-Draft March 2017 and challenges. [RFC4984] suggests that a generic identifier- locator separation would be a possible solution to support billions of mobile devices without "bringing undue impact on global routing scalability and stability". Indeed, the concept of identifier- locator separation is key to meeting future trends and challenges. At the same time, proposed solutions in this space do not currently address all requirements. The Routing Research Group (RRG) identified several identifier-based solutions in [RFC6115]. The technique relies upon the decoupling of the identifier from the locator and therefore the change of location is transparent to higher layers. The changes of LOC are handled by an infrastructure that maps the ID to the LOC. As Machine to Machine (M2M) communications become more pervasive, IoT devices are slated to be highly interconnected and unsupervised. As these communications will most likely be unmonitored, there are concerns regarding their discovery (privacy) , accessibility (possible breach) and data integrity (confidentiality). Furthermore, the multitude of diverse IoT devices using different communication protocols may create siloed communications. The sheer number of IoT devices expected to be deployed by 2020 will introduce new challenges that may be overcome by using the infrastructure of Identifier-based solutions. The deployment of 5G network infrastructures coupled with applications (such as augmented reality, virtual reality, 8k videos) are also putting more constraints, such as ultra-low latency with session continuity, on the underlying connectivity infrastructures [GSMA1] [GSMA2]. Identifier-based protocols can support mobility provided they have an efficient mapping service. Furthermore the vision of Network Slicing, that is a fundamental feature of the 5G systems, has evolved from a simple network overlay concept to enabling dynamic multi-service and multi-tenancy support, that transforms the networking perspective by abstracting, isolating and separating logical network behaviors from the underlying physical network resources. The generic architecture proposed by IDEAS facilitates these applications, in particular the decoupling of the entity identifier from the locator can also help to select the optimal control plane and user plane as well as compose and allocate virtualized network functions inside the core or radio access network depending on the service requirements. In the same way, the dynamically and on-demand virtual slices creation need an efficient mapping service between entity identifier and locator. This document examines the possible changes and improvements needed to address these challenges in Identity Enabled Networks (IDEAS). Pillay-Esnault, et al. Expires September 13, 2017 [Page 3] Internet-Draft March 2017 To provide some background, this memo gives a brief overview of what are Identity Enabled Networks. Next, it describes the problem statement and advocates for a standardized common control plane for identity services, including identifier registration, mapping, and resolution services. Several key areas that should be investigated for the architecture design of these services and how they interface with current and future Identifier-aware protocols are listed. The goal of the work proposed by this IDEAS initiative is to provide a generic architecture that is scalable, extensible, robust, secure, and flexible for future networks. 2. Specification of Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Definition of Terms Entity : An entity is a communication endpoint. It can be a device, a node, or a (software) process, that needs to be identified. An entity may have one or multiple identifiers simultaneously. An entity is reached by the resolution of one or more of its identifiers to one or more locators. Entity Collection: A set of entities with its own identifier, e.g., a multicast group, or an ad-hoc vehicular network that needs to be uniquely identified (e.g., a train entity may represent a Closed User Group (CUG) and may contain all the passengers' devices that share the same fate for connectivity). Identifier (ID): denotes information to unambiguously identify an entity within a given scope. There is no constraint on the format, obfuscation or routability of an ID. The ID may or may not be present in the packet whose format is defined by ID-based protocols. Locator (LOC): denotes information that is topology-dependent and which is used to forward packets to a given entity attached to a network. An entity can be reached using one or multiple locators; these locators may have a limited validity lifetime. Identity: the essence of "being" of a specific entity. An identity is not to be confused with an identifier: while an identifier may be used to refer to an entity, an identifier's Pillay-Esnault, et al. Expires September 13, 2017 [Page 4] Internet-Draft March 2017 lifecycle is not necessarily tied to the lifecycle of the identity it is referencing. On the other hand, the identity's lifecycle is inherently tied to the lifecycle of the entity itself. IDentity Enabled Networks (IDEAS): IDEAS are networks that support the identifier/locator decoupling. Reaching an entity is achieved by the resolution of identifier(s) to locator(s). Identifier-based (ID-based): When an entity is only reachable through one or more communication access then a protocol or a solution is said to be ID-based if it uses an ID-LOC decoupling and a mapping system (MS) as base components of the architecture. Identity-capable (ID-capable): An application is said to be ID- capable if it makes use of an Identifier of an entity to establish communication. For example, an application that initiates its sessions using an ID. An application may use an IP-address as a proxy for an ID if the network resolves this ambiguity. We regard such an application as being ID-capable. Generic Resilient Identity Services (GRIDS): GRIDS is a set of services to manage the lifecycle of IDs, to map and resolve identifiers and locators, and to associate metadata (META) with entities and entity collections. It is a distributed system that stores the ID, the associated LOC(s), and metadata (META) in the form of tuples (ID, LOC, and META). Metadata (META): is data associated with an Identity. The metadata may contain information such as the nature of the entity for example. 5G: Fifth generation wireless broadband technology [NEWS-3GPP]. Scope: denotes the domain of applicability or usability of an ID. A scope may be limited (e.g., considered local with geographic proximity, or private within an administrative domain) or be global. 4. Brief Overview of ID Enabled Networks The proposals of separating the ID from the LOC are not new. Location/Identifier Separation Protocol (LISP) [RFC6830] and Identifier Locator Addressing [ILA] solutions have been deployed in data centers (DC). Host Identity Protocol (HIP) [RFC7401] has been deployed as a host-based solution. Pillay-Esnault, et al. Expires September 13, 2017 [Page 5] Internet-Draft March 2017 The use of mobile devices with critical applications and fast mobility introduce additional constraints to address the combination of the following requirements: a. Ultra-low latency [GSMA1][GSMA2] b. Session continuity c. Mobility across heterogeneous multi-access networks d. Network Slicing IoT device technologies introduce other constraints such as battery life (up to ten year battery life for low power devices [GSMA2]) may not allow connected devices to constantly signal their position or limit the way they communicate. For example, in order to save energy a pet tracker may have intermittent one-way communication just to signal periodically its location. As the number of personal devices increases, they may be grouped in a cluster belonging to a closed user group or perhaps a class of devices. There will be a need to identify such groups and register them for multicasting or broadcasting. As the number of personal devices increases, they may be grouped in various clusters or closed user groups (depending on the nature of the IoT service and the need to manage small communities on the fly) or perhaps a service-inferred class of Devices (e.g., healthcare bracelets, heat sensors, infrared CCTV, etc.). There will be a need to identify such groups and clusters, and register them for multicasting or broadcasting purposes (e.g., to optimize resource management when sending a set of commands). Another example Energy management in smart cities may send commands to all lampposts that belong to different groupings (street or neighborhood). Therefore, any ID/LOC separation solution will require an infrastructure that secures registration, efficient discovery, and can manage complex lookups(e.g. all cameras of a brand in a factory floor) as well mapping/resolution services. 4.1. Identifiers Role in a Communication Session The IDentity Enabled networkS (IDEAS) intend to define the use of Identifiers (ID) as follows: o An ID is a way to identify communication endpoints of an entity. The ID of an entity abstracts its communication endpoints from its location. There is a distinction as well that the ID to a locator Pillay-Esnault, et al. Expires September 13, 2017 [Page 6] Internet-Draft March 2017 address mapping is a way to reach the entity but not tied to a specific interface address on the device itself. o Even though IDs may be sent inside a packet, they may be encrypted (or not) and may not be globally routable. o A single entity may have multiple IDs, and IDs of the same entity may have different life spans that are different from the lifespan of the entity. Furthermore, it is understood that IDs may have different lifecycles, which may be permanent or ephemeral by choice or design. o Ephemeral (temporary) IDs may be used as a short-lived pseudonym for a permanent ID to protect the privacy of the related entity. o Involved entities may have multiple IDs that are used to initiate a communication . Specifically, they are not just passive objects that need to be referenced and located in the Internet, but are live endpoints that may initiate a session while in motion or not. o Finally, entities with these IDs may be moving over large geographical distances and across multiple administrative domains. Therefore, there is no guarantee that they will retain their IP address. 4.2. Mapping/Resolution Services in GRIDS differ from Domain Name Service (DNS) The resolution of the ID into a locator is often mistaken as a NAT- like translation or even a DNS type of indirection. Since the 1980s, DNS has been pivotal to translate human readable names that are easy to remember into hard-to-remember IP addresses. It provides a global distributed directory service and is a very powerful and useful technology to translate the domain name hierarchy to IP address space. ]. The use of DNS, as is, is therefore unlikely to meet the challenges posed to GRIDS. Even though the DNS was designed to be resilient, it is prone to DDOS attacks as discussed extensively in the Technical Plenary of IETF97. Furthermore, some studies have also described challenges in the response time and caching techniques and latency in the Internet [DNS1] [DNS2] [DNS3]. The use of a mapping system rather than using DNS system has been discussed extensively in [IVIP], [RFC6115] and on the lisp-wg mailing list [LISP-DIS]. Pillay-Esnault, et al. Expires September 13, 2017 [Page 7] Internet-Draft March 2017 5. Key Problems 5.1. Common Control Plane Infrastructure Today, most locator/identifier separation solutions rely on a control plane that resolves an ID to one or multiple locators. Eventually, the control plane may be used to define other policies that are enforced by the devices that participate to the delivery and the operation of a connectivity service. These solutions implement their own resolution methods. The resolution service may leverage push- based protocols (traditional routing protocols and [LISP-SUBS]), pull-based control planes (DNS and LISP), third party software, or any combination thereof. Currently, each of the ID-based protocols uses its own specific mapping databases. While ID-enabled data plane mechanisms may serve fundamentally different objectives and may not need to interoperate in the past, there is a potential benefit in providing them with a common interface for services such as registration, discovery, update and resolution and new services such as security or access control policy. Furthermore, the lack of a mapping system with standardized invocation interfaces has the following downsides: a. An impediment for the deployment of ID-enabled solutions. Indeed, it would be inefficient to deploy several specialized mapping/resolution network databases within the same administrative domain. Furthermore, there will be additional expense and overhead to administer multiple proprietary mapping systems. b. Difficulty to have an overall view of the network. If multiple ID-enabled solutions with distinct mapping systems are deployed, troubleshooting may be difficult as the information may be located in different places. c. Complex Management due to disjoint information spread over several mapping systems. Operations such as merging networks are error prone and more challenging to detect and fix. Additionally, there will be considerable management overhead whenever devices migrate. d. Barriers to the application of common and consistent policies. For example, in cross-platform IoT networking, brokering services may be needed to enforce routing/security/QoS/TE policies on behalf of partnering structures - service provider, energy provider, content provider, etc. Pillay-Esnault, et al. Expires September 13, 2017 [Page 8] Internet-Draft March 2017 e. Risk for fragmented connectivity. A high diversity of mapping system variants will create silos of communications. f. Complex cross-MS communications. A common resolution system infrastructure may facilitate cross-MS communications. Today it is difficult to communicate with multiple customized ID mapping systems with distinct interfaces. The common control plane may support limited or private scopes. In addition support of private instances provides the necessary separation for specific users or applications. The emergence of dynamic (small-sized) communities or closed, on-the- fly, user groups puts additional pressure on the mapping system, from several standpoints that include robustness, availability, scalability and reliability. 5.2. Identifier Lifecycle Currently, there is no guidance or allocation scheme for public IDs. Each protocol has historically assigned their ID independently, be it structured or not. An agreed upon ID format and scope may facilitate cross-domain communication and simplify the implementation of some use cases to facilitate cross-silo communications or to better address the merging of networks The support of several allocation schemes by carving specific ranges within a name space and recycling should be explored for the future mapping systems. The operations and ease of deployment should also be considered as they may influence policy enforcement schemes related to the allocation of IDs of the use of relevant metadata. 5.3. Security of Mapping Systems As access to a mapping system may reveal the location and other sensitive information about an ID, any breach is therefore considered a security risk. Secured access and data integrity to current mapping systems may not be guaranteed. It is possible to register erroneous information in some cases if the system is under attack [LISP-SEC]. Similarly, in the absence of DNSSEC, HIP RR is vulnerable [RFC8005]. 5.4. Distributed Denial of Service Attack Prone The DNS system is vulnerable to DDOS attacks. The HIP protocol relies on DNS for the publication of public Host Identifier [HIP-ARCH]. Pillay-Esnault, et al. Expires September 13, 2017 [Page 9] Internet-Draft March 2017 The other current mapping systems are not specifically designed to be protected against a DDOS attack. This is a potential issue as they have well-known IP addresses and registration depends on their reachability. 6. Use Cases The use cases are discussed in detail in [IDEAS-USE]. 7. Relationship between IDEAS and other IETF Working Groups This document is meant to encourage the IETF community to investigate the opportunity of a new specification effort to address some specific problems from an ID Enabled Networks standpoint in general. The focus is to find a common solution and infrastructure that can be shared by current protocols and facilitate the introduction of new ID-based services while avoiding rehashing the same problems again each time a new service pops up. It proposes to address these problems with a Generic Resilient ID Services infrastructure which includes standardized access and multiple services. The services include secured registration, discovery, updates with data integrity, mapping and resolution capabilities, define relationships between IDs or group of IDs, access control policy and security. Some other working groups are already working to address some specific limitations or enhancement of ID-capable protocols. These working groups include LISP, HIP and NVO3. Protocols and architectures defined by these WGs may assume a mapping system or other resolution techniques, but they are not currently covering the other services mentioned in this document. 7.1. LISP WG The LISP WG has been working on multiple mapping systems (ALT, DDT) for the LISP control plane and the primary function of this mapping system is to map and resolve the ID to IP addresses (EID/RLOC mapping). Though some requirements are common, GRIDS has new specific requirements that are described in [IDEAS-REQ]. 7.2. HIP WG The HIP WG has based its resolution service on DNS and sections 4.2, 5.3 and 5.4 of this document describe some of the vulnerabilities of this solution to address the requirement for fast mobility with low latency. Pillay-Esnault, et al. Expires September 13, 2017 [Page 10] Internet-Draft March 2017 7.3. NVO3 WG The NV03 WG has been working on a mapping of VN names to VN IDs in the network virtualization space and their requirements differ from the wireless broadband requirements and cross-silo communications that have been mentioned in this document. 8. Security Considerations Due to the sensitivity of Identity tied to identifier and locator, there is a need to pay attention to security ramifications. In particular, the security goals should include confidentiality, possible encryption for integrity of sensitive data and privacy. Various aspects of security and the security requirements for IDEAS are discussed in TBD document. 9. IANA Considerations This document has no actions for IANA. 10. Contributors This present document is based on an extract of the first version of the draft. The authors and their affiliations on the original document are: D. Farinacci (lispers.net), D. Meyer (Brocade), D. Lake (Cisco Systems), T. Herbert (Facebook), M. Menthe (University of Tuebingen), Dipenkar Raychaudhuri (Rutgers University), Julius Mueller (ATT) and Padma Pillay-Esnault (Huawei). There are two companion documents also extracted from the -00 version of this document: Problem Statement in IDEAS [IDEAS-USE] and GRIDS Requirements [IDEAS-REQ]. The following individuals substantially contributed to this document: o Georgios Karagiannis o Alex Clemm o Uma Chunduri 11. Acknowledgments The authors would like to thank Alex Clemm, Uma Chunduri, Georgios Karagiannis, Stewart Bryant, Michael Menth, Liu Bingyang, Yingzhen Qu and Onur Ozan Koyluoglu for their review and input on this document. The authors would like to thank Renwei Li, Jeff Tansura, Burjiz Pillay-Esnault, et al. Expires September 13, 2017 [Page 11] Internet-Draft March 2017 Pithawala, Lin Han and Kiran Makhijani and Jean-Michel Esnault who participated in numerous discussions. This document was produced using Marshall Rose's xml2rfc tool. 12. References 12.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . 12.2. Informative References [DNS1] Jung, J., Sit, E., Balakrishnan, H., and R. Morris, "DNS Performance and the Effectiveness of Caching", 2002, . [DNS2] Liston, R., Srinivasan, S., and E. Zegura, "DNS Performance and the Effectiveness of Caching", 2002, . [DNS3] Briscoe, B., Anna Brunstrom, A., Andreas Petlund, A., David Hayes, D., David Ros, D., Ing-Jyh Tsang, I., Stein Gjessing, S., Gorry Fairhurst, G., Carsten Griwodz, C., and M. Michael Welzl, "Reducing Internet Latency: A Survey of Techniques and their Merits", November 2014, . [GSMA1] GSMA, "Unlocking Commercial Opportunities From 4G Evolution to 5G", February 2016, . [GSMA2] GSMA, "Understanding 5G: Perspectives on future technological advancements in mobile", December 2014, . [HIP-ARCH] Moskowitz, R. and M. Komu, "An Architectural Introduction to the Locator/ID Separation Protocol", November 2016, . Pillay-Esnault, et al. Expires September 13, 2017 [Page 12] Internet-Draft March 2017 [IDEAS-REQ] Pillay-Esnault, P., Clemm, A., Farinacci, D., and D. Meyer, "Requirements for Generic Resilient Identity Services in Identity Enabled Networks", March 2017, . [IDEAS-USE] Pillay-Esnault, P., Farinacci, D., Herbert, T., Jacquenet, C., Lake, D., Menth, M., Meyer, D., and D. Raychaudhuri, "Use Cases for Identity Enabled Networks", March 2017, . [ILA] Herbert, T., "Identifier-locator addressing for network virtualization", March 2016, . [IVIP] Whittle, R., "Ivip (Internet Vastly Improved Plumbing) Architecture", September 2010, . [LISP-DIS] "LISP Discussion", . [LISP-SEC] Maino, F., Ermagan, V., Cabellos, A., and D. Saucez, "LISP-Security", November 2016, . [LISP-SUBS] Boucadair, M. and C. Jacquenet, "LISP Subscription", February 2017, . [NEWS-3GPP] 3GPP, "3GPP News", . [RFC4984] Meyer, D., Ed., Zhang, L., Ed., and K. Fall, Ed., "Report from the IAB Workshop on Routing and Addressing", RFC 4984, DOI 10.17487/RFC4984, September 2007, . Pillay-Esnault, et al. Expires September 13, 2017 [Page 13] Internet-Draft March 2017 [RFC6115] Li, T., Ed., "Recommendation for a Routing Architecture", RFC 6115, DOI 10.17487/RFC6115, February 2011, . [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The Locator/ID Separation Protocol (LISP)", RFC 6830, DOI 10.17487/RFC6830, January 2013, . [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. Henderson, "Host Identity Protocol Version 2 (HIPv2)", RFC 7401, DOI 10.17487/RFC7401, April 2015, . [RFC8005] Laganier, J., "Host Identity Protocol (HIP) Domain Name System (DNS) Extension", RFC 8005, DOI 10.17487/RFC8005, October 2016, . Authors' Addresses Padma Pillay-Esnault (editor) Huawei 2330 Central Expressway Santa Clara, CA 95050 USA Email: padma.ietf@gmail.com Mohamed Boucadair Orange Rennes 35000 France Email: mohamed.boucadair@orange.com Christian Jacquenet Orange Rennes 35000 France Email: christian.jacquenet@orange.com Pillay-Esnault, et al. Expires September 13, 2017 [Page 14] Internet-Draft March 2017 Giuseppe Fioccola Telecom Italia Email: giuseppe.fioccola@telecomitalia.it Axel Nennker Deutsche Telekom Email: Axel.Nennker@telekom.de Pillay-Esnault, et al. Expires September 13, 2017 [Page 15]