Network Working Group P. Pillay-Esnault, Ed. Internet-Draft Huawei Intended status: Informational M. Boucadair Expires: January 4, 2018 Orange G. Fioccola Telecom Italia C. Jacquenet Orange A. Nennker Deutsche Telekom July 3, 2017 Problem Statement for Identity Enabled Networks draft-padma-ideas-problem-statement-03 Abstract This problem statement examines how existing protocols that separate identifiers from their location may benefit from the concept of identity. The proposal laid out herein advocates for a standardized identity/identifier network infrastructure that provides a framework to support identity services in addition to enhancing existing identifier/location mapping and resolution 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 January 4, 2018. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. Pillay-Esnault, et al. Expires January 4, 2018 [Page 1] Internet-Draft July 2017 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. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 3. Key Problems . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1.1. Tracking Prevention . . . . . . . . . . . . . . . . . 5 3.1.2. Privacy against Eavesdroppers . . . . . . . . . . . . 5 3.1.3. Identifier Right to be Forgotten . . . . . . . . . . 6 3.2. Common Infrastructure and Primitives . . . . . . . . . . 6 3.3. Allocation Schemes Guidance . . . . . . . . . . . . . . . 7 4. Scopes . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. In Scope . . . . . . . . . . . . . . . . . . . . . . . . 7 4.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . . 8 4.3. Future Studies . . . . . . . . . . . . . . . . . . . . . 8 5. Relationship between IDEAS and other IETF Working Groups . . 8 5.1. LISP WG . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.2. HIP WG . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.3. NVO3 WG . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Companion Documents . . . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 11. Informative References . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction While the separation of identifier from the location is not a new concept, existing solutions such as Host Identity Protocol (HIP) [RFC7401] , Location/Separation Protocol (LISP) [RFC6830] and Identifier-Locator Addressing (ILA) [ILA] for IPv6, may benefit from a higher layer abstraction that separates the identity of an entity from its associated identifier(s). In identifier and Location split protocols, identifiers (IDf) are used for decoupling the identifier and the location information at Pillay-Esnault, et al. Expires January 4, 2018 [Page 2] Internet-Draft July 2017 the network layer. Typically, a IDf represents an end-point communication tied to an entity. Usually, IDfs are long-lived and may or may not be routable. However, locators (LOC) may be transient and associated with the location of the entity. The LOCs are routable network addresses (e.g. IPv4, IPv6 addresses). The IDfs are mapped to LOCs for forwarding purposes. Modification of LOC information is handled by an a mapping system that updates the IDf/ LOC mappings. In order to communicate with a device, the initiator relies on a mapping system that is designed to process lookup requests on a network IDf and return the LOC(s). While the mapping system fulfills its functionality, this mode of operation has some drawbacks. The entities update the system with their (IDf,LOC) bindings. In some cases, it may register the LOC of a forwarding element such as a proxy or HIP Rendezvous Server. Regardless, it is assumed that once the entities have registered their (IDF,LOC(s)) tuple to the system, this information is available to all with access to the mapping system. Any request for this information would then be readily available without any discrimination. For example, a public entity needs to have its IDf public to be discovered by clients. However, it might not be always desirable that some devices (e.g. home cameras) are visible to all without any control. Privacy and security requirements of entities suggest the use of some mechanism to authenticate entities that can dynamically discover them and prevent unwanted communication. In existing architectures it is possible to authenticate IDf, however they are not permanently attached to the entity. This is crucial in a multi-provider and/or multi-domain scenario, related for example to a complex end-to-end service. Therefore the concept of an identity(IDy) tied to an entity and to its lifecycle should be considered. The IDy is intended to be used for identifying and authenticating an entity. Likewise, the IDy information should not be carried in clear in packet headers. The Section 3 of this document will describe how this IDy may be used. Furthermore, it would be beneficial to generalize this Identity concept across protocols that may benefit from it. Therefore there is a need for a system which shares some common control plane for services commonly used such as look-ups or updates. This document examines the possible changes and improvements needed to address these challenges in Identity Enabled networkS (IDEAS). It describes the problem statement and advocates for a standardized extensible common control plane for IDf/LOC protocols that supports: Pillay-Esnault, et al. Expires January 4, 2018 [Page 3] Internet-Draft July 2017 Identity services (including registration and authentication) Management of access credentials based on IDy Look-ups with restrictions Mapping, and resolution services on IDfs 2. 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 and locatable/reachable. Such entity will have one or more communication interfaces. An entity may have multiple IDfs simultaneously that are NOT associated with any particular interface(s). It is reached by the resolution of one or more of its IDfs to one or more LOCs. Identity (IDy): The essence of "being" of a specific entity. An IDy is not to be confused with an IDf: while an IDf may be used to refer to an entity, an IDf's lifecycle is not necessarily tied to the lifecycle of the IDy it is referencing. On the other hand, the IDy's lifecycle is inherently tied to the lifecycle of the entity itself. Identifier (IDf): An IDf denotes information to unambiguously identify an entity or an entity group within a given scope. An IDf is the equivalent of an End point identifier (EID) in LISP or Host Identity Tag (HIT) in HIP. It may be visible in communications. Locator (LOC): A locator is a routable network address. It may be associated with an IDf and used for communication on the network layer according to LOC/IDf split principle. A LOC is the equivalent of a Routing Locator (RLOC) in LISP or an IP address in HIP. Metadata (META): Data associated with an IDy and its IDfs in the framework. The metadata is to be used for storing long-lived slow changing information such as the nature of the entity (e.g. camera or phone). IDy/IDf mapping: One IDy may be associated to multiple IDfs. The IDfs are mapped to one IDy. Identifier-based: When an entity is only reachable through one or more communication access then a protocol or a solution is said to Pillay-Esnault, et al. Expires January 4, 2018 [Page 4] Internet-Draft July 2017 be identifier-based if it uses an ID-LOC decoupling and a mapping system (MS) as base components of the architecture. GeneRic Identity Services (GRIDS): GRIDS is a set of services to manage the lifecycle of ID[y|f]s, to map and resolve IDfs and LOCs, and to associate META with entities. It is a distributed system that stores the IDy, IDf, the associated LOC(s), and META in the form of tuples (ID, LOC, and META). Meta queries are supported and queries are restricted to authenticated and authorized IDys. IDentity Enabled Networks (IDEAS): IDEAS are networks that support the IDf/IDy decoupling as well as IDf /LOC decoupling using GRIDS. Reaching an entity is achieved by the resolution of IDf(s) to LOC(s). Scope: Domain of applicability or usability of an IDfs and IDys. The scope may be global or limited, e.g., considered local with geographic proximity or private within an administrative domain. 3. Key Problems 3.1. Privacy 3.1.1. Tracking Prevention Access to a mapping system may reveal the location and other sensitive information about an entity to the requestor of a look-up on an IDf. Repeated look-ups on the mapping system may be misused for tracking IDfs of an entity or mount an attack. To preserve its privacy, the entity or infrastructure may restrict access for look-ups for certain IDfs or IDys or entity with specific meta. (E.g. nature of an entity stored in meta as a camera). Currently, even if look-ups on the mapping systems were modified not to return a result if the requestor is barred, it would be easily defeated if the requestor changes its IDf. However, if all IDfs of an entity are associated with the IDy, then the requestor entity cannot easily defeat the aforementioned filtering rule by just changing its IDf. 3.1.2. Privacy against Eavesdroppers Eavesdroppers may observe the traffic and deduce the flows between two IDfs or entities. To protect its privacy, an entity may choose additional temporary IDfs for communications. Pillay-Esnault, et al. Expires January 4, 2018 [Page 5] Internet-Draft July 2017 However, this mechanism makes discovery difficult and the entity must at least have a long-lived IDf for this purpose. The use of obfuscation is another solution to protect the source and destination IDf however this implies extra processing or DPI for functionalities such as late binding. The use of IDy as an indirection to the actual IDfs used on the wire present the advantage of having the source and destination ephemeral IDfs in clear but authorized use may still maps these to the IDy. The IDy of an entity must not be revealed in packets. Therefore, encrypting the control plane mechanisms (requests and replies) is required to avoid eavesdroppers to deduce who are the peers of communication flows. 3.1.3. Identifier Right to be Forgotten The control of the IDy/IDf mappings can restrict access to selected requesting IDys/IDfs and also limit that access over time to implement an "identifier right to be forgotten". The advantage of this method is that entities may use IDfs for communication to better protect their IDy. Only authorized communication partners can find out the corresponding IDys. The concept of IDy proposed by IDEAS helps to provide privacy in communication in a similar way as IPv6 privacy extension minimizes the risk of being tracked by a stable MAC address. To that end, access restriction is needed for mapping system requests that also need to be encrypted to avoid eavesdropping. 3.2. Common Infrastructure and Primitives Currently, each of the IDf-based protocols uses its own specific mapping databases. While IDf-based data plane mechanisms may serve fundamentally different objectives and may not need to interoperate, there is a potential benefit in providing them with a common interface for common services such as IDy/IDf registration, discovery, update, resolution and access control policy. Furthermore, the lack of a common infrastructure with standardized invocation interfaces has the following downsides: a. An impediment for the deployment of IDf-based. 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. Pillay-Esnault, et al. Expires January 4, 2018 [Page 6] Internet-Draft July 2017 b. Difficulty to have an overall view of the network. If multiple IDf-based 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 enforcement 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. The common infrastructure may be supported within limited or private scopes. In addition support of private instances provides the necessary separation for specific users or applications. 3.3. Allocation Schemes Guidance Currently, there is no consistent guidance or allocation scheme for non-IP address format public IDfs across all protocols. Each protocol has historically assigned their IDfs independently, be it structured or not. An agreed scheme or a collision detection mechanism within a scope may facilitate cross-domain communication in the future. This would 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 IDfs of the use of relevant META. 4. Scopes 4.1. In Scope The scope of this work is on the network layer (layer 3). The network identities that may be alphanumerical are assumed to map to numerical IDfs as in LISP, HIP or ILA. The LOCs are assumed to be IPv4 or IPv6 addresses. The META is assumed to be tied to the IDy or IDf and slow changing. Pillay-Esnault, et al. Expires January 4, 2018 [Page 7] Internet-Draft July 2017 While the issues described in the document may be generalized to a broader scope, IDEAS is focused on delivering functionalities at the network layer only. 4.2. Out of Scope The following are out of scope for this effort: o The resolution or mapping of domain names or any application level naming or directories (like URIs ...). o META information with rapid changes 4.3. Future Studies Other network addressing schemes may be considered for future studies. 5. 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 IDy 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 IDy-based services while avoiding rehashing the same problems again each time a new service pops up. We propose to address these problems with a GeneRic IDentity Services (GRIDS) 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 identities or group of identities, access control policy and security. Some other working groups are already working to address some specific limitations or enhancement of identifier-based protocols but do not take IDy requirements as highlighted in this document into consideration. 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. Pillay-Esnault, et al. Expires January 4, 2018 [Page 8] Internet-Draft July 2017 5.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 IDf to IP addresses (EID/RLOC mapping). LISP WG is also looking at Casssandra and blockchain. Though some requirements are common,GRIDS has new specific requirements described in [IDEAS-REQ]. 5.2. HIP WG The HIP WG has based its IDy to IDf resolution service on DNS. Operational IDf to Loc for fast mobility with low latency is handled by HIP-RVS [RFC8005] and specific HIP Mobility Notification messaging [RFC8046]. 5.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. 6. Companion Documents There are three companion documents: o Use Cases for Identity Enabled Networks [IDEAS-USE] o Requirements for Generic Identity Services in Identity Enabled Networks [IDEAS-REQ] o Identity Use Cases in IDEAS [IDEAS-IDY] o Gap Analysis for Identity Enabled Networks [IDEAS-GAP] 7. Security Considerations Due to the sensitivity of IDy tied to IDf and LOC, 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. 8. IANA Considerations This document has no actions for IANA. Pillay-Esnault, et al. Expires January 4, 2018 [Page 9] Internet-Draft July 2017 9. Contributors The following individuals (by first name alphabetical order) have contributed to this document: o Albert Cabellos o Alex Clemm o Dino Farinacci o Georgios Karagiannis o Jim Guichard o Michael Menth o Robert Moskowitz o Tom Herbert o Uma Chunduri 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. Menth (University of Tuebingen), Dipenkar Raychaudhuri (Rutgers University) and Julius Mueller (ATT). 10. Acknowledgments The authors would like to thank Stewart Bryant, David Lake, Bingyang Liu, Dave Meyer, Dipenkar Raychaudhuri, Yingzhen Qu, and Onur Ozan Koyluoglu for their review and input on this document. The authors would like to thank Jean-Michel Esnault, Renwei Li, Lin Han, Kiran Makhijani Erik Nordmark, Burjiz Pithawala, and Jeff Tansura who participated in numerous discussions. This document was produced using Marshall Rose's xml2rfc tool. 11. Informative References [IDEAS-GAP] Qu, Y., Cabellos, A., Moskowitz, R., Liu, B., and A. Stockmayer, "Identity Use Cases in IDEAS", July 2017, . Pillay-Esnault, et al. Expires January 4, 2018 [Page 10] Internet-Draft July 2017 [IDEAS-IDY] Chunduri, U., Clemm, A., and M. Menth, "Identity Use Cases in IDEAS", June 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, . [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, . [RFC8046] Henderson, T., Ed., Vogt, C., and J. Arkko, "Host Mobility with the Host Identity Protocol", RFC 8046, DOI 10.17487/RFC8046, February 2017, . Authors' Addresses Pillay-Esnault, et al. Expires January 4, 2018 [Page 11] Internet-Draft July 2017 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 Giuseppe Fioccola Telecom Italia Email: giuseppe.fioccola@telecomitalia.it Christian Jacquenet Orange Rennes 35000 France Email: christian.jacquenet@orange.com Axel Nennker Deutsche Telekom Email: Axel.Nennker@telekom.de Pillay-Esnault, et al. Expires January 4, 2018 [Page 12]