Network Working Group D. von Hugo Internet-Draft Deutsche Telekom Intended status: Standards Track B. Sarikaya Expires: December 9, 2018 Denpel Informatique L. Iannone Telecom ParisTech T. Herbert Quantonium June 7, 2018 Problem Statement for Secure End to End Privacy Enabled Mapping System draft-xyz-atick-ps-01.txt Abstract Problem Statement for Secure End to End Privacy Enabled Mapping System for Identifier Locator separation systems is presented. Since identifiers are often carried in packet headers in clear, and mapping systems are often designed to be accessible by any entity, to preserve identifier's privacy, lookups to the mapping system should be allowed only by authorized entities. In mapping systems, in addition to privacy, security also requires special attention because of the caches introduced into the data path. Any denial of service attacks on the cache should not allow the communication to come to an end. 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 https://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 December 9, 2018. von Hugo, et al. Expires December 9, 2018 [Page 1] Internet-Draft Atick Problem Statement June 2018 Copyright Notice Copyright (c) 2018 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 (https://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. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Security In the Data Path . . . . . . . . . . . . . . . . 5 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 7.2. Informative References . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction Current 4G and the upcoming converged communication network of 5G core network (5GC) make use of tunneling with anchor points to handle mobility, policy and quality of service. The use of IP addresses induces the topology and enables easy location tracking. Elimination or reduction of anchor points, as well as disassociating topology from IP addresses to facilitate efficient mobility and user privacy using Identifier Locator separation systems like Identifier Locator Addressing, The Locator/ID Separation Protocol and others is needed. Many drawbacks of tunneling are discussed in [I-D.ietf-intarea-tunnels] and we do not repeat them here. This document attempts to make the case for the use of the identifier locator separation (Id-Loc) protocols in the data plane and identifies the problems for such a large scale use. The problems identified mainly are privacy of the identifiers and associated locators and security issues. von Hugo, et al. Expires December 9, 2018 [Page 2] Internet-Draft Atick Problem Statement June 2018 2. Conventions and Terminology 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 RFC 2119 [RFC2119]. Identifier: An identifier is information to unambiguously identify an entity or an entity group within a given scope. An identifier is the equivalent of an End point identifier (EID) in The Locator/ID Separation Protocol (LISP). It may be visible in communications. Locator: A locator is a routable network address. It may be associated with an identifier and used for communication on the network layer according to identifier locator split principle. A locator is the equivalent of a Routing Locator (RLOC) in LISP or an IP address in other cases. 3. Problem Statement Identifier represents a communication end-point of an entity and may not be routable. Locator also represents a communication end point, i.e. its routable network address and thus can change if the entity moves. A database called a mapping system needs to be used for identifier to locator mapping. Identifiers are mapped to locators for forwarding purposes. Mapping system has to handle mobility by modifying identifier to locator mappings in the database. To start the communication, a device needs to know the identifier of the destination and then relies on a process to lookup on a network identifier and return the locator(s). Note that both identifier and locator can be carried in clear in packet headers. Usage of identifiers readily available for public access raises privacy issues. For public entities, it may be desirable to have their fully qualified domain names or host names available for public lookups by the clients however such is not the case in general for the identifiers, e.g. for individuals roaming in a mobile network. This document describes the problem statement for a new kind of mapping system to be used by identifier locator separation systems (Id-Loc) that are end to end privacy enabled. Heavy use of tunneling with fixed anchors: Current 4G and the upcoming converged communication network of 5G core network (5GC) make use of tunneling with anchor points to handle mobility, policy and quality of service. The use of IP addresses induces the topology and enables easy location tracking. Elimination von Hugo, et al. Expires December 9, 2018 [Page 3] Internet-Draft Atick Problem Statement June 2018 or reduction of anchor points, as well as disassociating topology from IP addresses to facilitate efficient mobility and user privacy using Identifier Locator separation systems is needed. Increasing packet overhead due to encapsulation that may cause fragmentation and all related issues typical disadvantages of (especially static end- to-end) tunneling comprise inflexibility to properly react to dynamic changes of end points and potential on-path anchors which is required to support mobility. Added complexity of increased signaling for tunnel management are further drawbacks [I-D.ietf-intarea-tunnels]. Proposed 5G operation: The use of GTP is proposed to tunnel UE packets from the base station, gNB to the User Plane Function (UPF) in N3 interface establishes a fixed anchor for UE traffic and UPF further GTP tunnels to another UPF in N9 interface which is connected to an external data network (DN). Access and Session Management control plane functions (AMF, SMF) push such configuration setup to the data plane functions. With such a rigid setup user mobility as well as UE receiving traffic on multiple interfaces can not be handled efficiently. UE to another UE traffic has to go to the fixed anchor since gNBs are not mobility anchors. Also due to the induced delays, delay sensitive applications such as Ultra Reliable Low Latency (URLL) applications can not be supported. IP Addressing Reveals geographic location: Addressing scheme in use currently reveal the topology of the internet and thus location privacy of the end nodes can not be established. Move away from this heavy use of locators is needed in favor of identifier locator separation systems. Gap Analysis: Gaps in mapping solutions developed so far in Id-Loc systems reveal the fact that secure end to end privacy enabled mapping system approach is needed across the board [I-D.xyzy-atick-gaps]. Access to a mapping system should not reveal the location about an entity to the unauthorized requestor of a look up on an identifier. Tracking of the identifiers of an entity and mounting attacks based on that should be avoided. On the other hand discovery by the entities that are allowed to should not be made difficult. This may be possible by using encryption effectively in the control plane mechanisms to avoid eavesdroppers to access such information [I-D.ietf-lisp-sec]. von Hugo, et al. Expires December 9, 2018 [Page 4] Internet-Draft Atick Problem Statement June 2018 If locators/ addresses (or device prefixes) are common between flows for a given entity then a third party can make inferences (i.e. whether they are sourced from the same host). This points to the problem of persistent identifiers which should be avoided. Compromise of a mapping system is very bad since it would allow attackers to take control of traffic and to misdirect it. If locators/ addresses contain fine grained topology then device location (and hence user location) can be inferred. This gets to the problem that locators may contain detailed geographic location information and hence are very sensitive data. This points to the need for using identifier locator separation. Scaling is an issue for mapping systems built using very high performance massively distributed noSQL databases. Slow moving or fixed hosts can probably induce light loads on mapping systems. In 5G case, very high number of devices moving at high speeds this changes drastically, i.e. very heavy load is induced on the mapping system. Mapping systems that scale to 100s of millions of entries with 100s of milliseconds response times are needed. State of the art shows that such systems can be built and operated with the use of thousands of servers worldwide. 3.1. Security In the Data Path If a cache is introduced into the data path (as might be the case in some mapping systems) then that in turn will introduce potential DoS attacks in order to slow down or even completely stop the communication. So proper protocol actions and security policies should be taken against DoS attacks. Compromise of a mapping system is very bad since it would allow attackers to take control of traffic and to misdirect it. 4. IANA Considerations TBD. 5. Security Considerations 6. Acknowledgements 7. References von Hugo, et al. Expires December 9, 2018 [Page 5] Internet-Draft Atick Problem Statement June 2018 7.1. Normative References [I-D.ietf-lisp-rfc6830bis] Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. Cabellos-Aparicio, "The Locator/ID Separation Protocol (LISP)", draft-ietf-lisp-rfc6830bis-12 (work in progress), March 2018. [I-D.ietf-lisp-rfc6833bis] Fuller, V., Farinacci, D., and A. Cabellos-Aparicio, "Locator/ID Separation Protocol (LISP) Control-Plane", draft-ietf-lisp-rfc6833bis-10 (work in progress), March 2018. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC6740] Atkinson, RJ. and SN. Bhatti, "Identifier-Locator Network Protocol (ILNP) Architectural Description", RFC 6740, DOI 10.17487/RFC6740, November 2012, . 7.2. Informative References [I-D.herbert-intarea-ila] Herbert, T. and P. Lapukhov, "Identifier-locator addressing for IPv6", draft-herbert-intarea-ila-01 (work in progress), March 2018. [I-D.ietf-intarea-tunnels] Touch, J. and M. Townsley, "IP Tunnels in the Internet Architecture", draft-ietf-intarea-tunnels-08 (work in progress), January 2018. [I-D.ietf-lisp-sec] Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-15 (work in progress), April 2018. [I-D.xyzy-atick-gaps] Hugo, D., Sarikaya, B., Herbert, T., Iannone, L., and S. Bhatti, "Gap and Solution Space Analysis for End to End Privacy Enabled Mapping System", draft-xyzy-atick-gaps-00 (work in progress), May 2018. von Hugo, et al. Expires December 9, 2018 [Page 6] Internet-Draft Atick Problem Statement June 2018 Authors' Addresses Dirk von Hugo Deutsche Telekom Deutsche-Telekom-Allee 7 D-64295 Darmstadt Germany Email: Dirk.von-Hugo@telekom.de Behcet Sarikaya Denpel Informatique Email: sarikaya@ieee.org Luigi Iannone Telecom ParisTech Email: ggx@gigix.net Tom Herbert Quantonium Email: tom@herbertland.com von Hugo, et al. Expires December 9, 2018 [Page 7]