Network Working Group D. von Hugo Internet-Draft Deutsche Telekom Intended status: Standards Track B. Sarikaya Expires: November 26, 2018 Denpel Informatique T. Herbert Quantonium L. Iannone Telecom ParisTech S. Bhatti University of St. Andrews May 25, 2018 Gap and Solution Space Analysis for End to End Privacy Enabled Mapping System draft-xyzy-atick-gaps-00.txt Abstract This document presents a gap and solution analysis for end-to-end privacy enabled mapping systems. Each of the identifier locator separation system has its own approach to mapping identifiers to the locators. We analyse all these approaches and identify the gaps in each of them and do a solution space analysis in an attempt to identify a mapping system that can be end to end privacy enabled. 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 November 26, 2018. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. von Hugo, et al. Expires November 26, 2018 [Page 1] Internet-Draft Atick Gap Analysis May 2018 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. Gap and Solution Space Analysis . . . . . . . . . . . . . . . 3 3.1. ILNP . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.2. ILA . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.3. LISP . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. General Recommendations . . . . . . . . . . . . . . . . . . . 5 4.1. Security In the Data Path . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 8.2. Informative References . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction Identifier Locator Systems like ILA [I-D.herbert-intarea-ila], ILNP RFC 6740 [RFC6740], and LISP [I-D.ietf-lisp-rfc6830bis] [I-D.ietf-lisp-rfc6833bis] are proposed as alternative approaches to enabling direct routing in the upcoming converged communication networks such as 5G core network (5GC) rather than using tunneling with GTP-U, GRE, (P)MIPv6 or similar ones. In addition to 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. Added complexity in case of multicast traffic and increased signaling for tunnel management are further drawbacks. Tunnels may introduce vulnerabilities or add to the potential for receiver overload and thus DOS attacks [draft-ietf-intarea-tunnels-08]. Finally without other measures such as deep packet inspection optimization of paths according to network resources and application needs becomes complex. von Hugo, et al. Expires November 26, 2018 [Page 2] Internet-Draft Atick Gap Analysis May 2018 With the Id-Loc systems a mapping system needs to be established so that 5GC nodes or functions can access the identifier and locator values of the destination given the source identifier and locator values to enable them to route the packet towards the destination. For mapping systems there will be a trade-off between scalability and rapid processing versus privacy and security of data. A public distributed database such as the DNS is used by end hosts for host name (or FQDN) to identifier mapping usually to start the communication. DNS can be used to publicly access identifiers. However, using DNS for locator access brings the issue that any node in the internet can query and track the location of the roaming UEs in 5G network which is not desirable. A separate database called a mapping system needs to be used for identifier to locator mapping. Such a mapping system need not be public in order to avoid that any node can write new mapping pairs or ID-Loc bindings in such a database. 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]. See the definitions in [draft-xyz-atick-ps-oo.txt]. 3. Gap and Solution Space Analysis 3.1. ILNP ILNP uses DNS for identifier to locator mapping. RFC 6742 [RFC6742] defines DNS resource records for identifier called NID and locator called L64 for IPv6 and L32 for IPv4. This allows the end nodes to obtain the destination identifier for a given Fully Qualified Domain Name (FQDN). However the same node also gets the locator values raising serious privacy issues in the control plane. ILNP outlines locator and identifier privacy solutions in RFC 6748 [RFC6748] in the data plane. Source locator privacy can be preserved by the use of a Locator Rewriting Relay (LRR) on the path from the source to the destination, e.g. when a UE is in communication with a remote server. A LRR provides a mapping between a localised source locator value to a different locator value, e.g. a globally routable locator, re- writing the packet's source locator value with the new locator value. The LRR also handles the reverse path mapping to the source for return packets. For source identifier privacy, ILNP allows the use of any privacy mechanisms defined for IPv6 identifiers, e.g. ephemeral-use identifier values, ala RFC 4941 [RFC4941], or (better) RFC 8064 [RFC8064]. von Hugo, et al. Expires November 26, 2018 [Page 3] Internet-Draft Atick Gap Analysis May 2018 For incoming connections to an ILNP node, the identifier and locator values are stored in DNS as described above, i.e. ILNP does not define a mapping system. For a 5G network, this could be an internal ("private") DNS system, only accessible via the provider. However, it would be possible to define other mapping systems from names to identifier/locator values, or, for example, from E.164 numbers to ILNPv6 NID/L64 values. In general, if the source identifier for a UE is known to a remote entity, there is the potential for communication packets to be linked to a node. If the source locator of a UE is known to a remote entity, there is the potential for topological (and possibly geographical) location of that UE to become known. Also, there are concerns on the write operation efficiency for DNS data store, i.e. Dynamic DNS in the face of 5G level handovers. Furthermore, ILNP demands a change in the way local (e.g., within a LAN) communication is carried out, needing all of the devices to support ILNP. This in turn may raise heavy deployability issues. However, in 5G UE has a point-to-point connection to 5G core network, i.e. no shared LAN is used. 3.2. ILA ILA is currently using a distributed key value (KV) store for identifier locator mapping [I-D.herbert-ila-ilamp]. The key value NoSQL database also supports publish/subscribe where the senders or publishers send the messages while the receivers or subscribers receive them and the link by which the messages are transferred is called channel. Such an approach avoids developing a request response protocol in order to update the mapping database with new identifier locator values or to access locator values for a given identifier and also leverages all the recent developments for security, availability, reliability, replication, etc. ILA forwarding nodes (ILA-N) maintain caches of identifier locator values learned so far but these values are UE specific. The ILA Mapping Protocol (ILAMP) [I-D.herbert-ila-ilamp] is used between ILA forwarding nodes and ILA mapping routers (ILA-R). The purpose of the protocol is to populate and maintain the ILA mapping cache in forwarding nodes. ILA-N sends Map Request message to ILA-R with a list of identifiers and ILA-R replies with Map Information message with identifier to locator mappings. ILA-R contains a horizontal partition of the whole identifier locator database called a shard. LISP style request/response protocol based mapping system can also be used by ILA as defined in [I-D.rodrigueznatal-ila-lisp]. Privacy is addressed in the data plane by way of UE simultaneously using different addresses for different connections chosen from a block of addresses. It is observed that NAT can also provide address privacy but the use of NAT is discouraged in IETF. UE needs to von Hugo, et al. Expires November 26, 2018 [Page 4] Internet-Draft Atick Gap Analysis May 2018 reestablish connections every time it changes its address so address changing incurs delays which could be significant in case of real- time communication unless connections can be made simultaneously ('make before break'). 3.3. LISP In LISP, FQDN to identifier or EID mappings are stored in DNS. The LISP control-plane interface to the identifier-locator or EID-RLOC mapping system is defined in [I-D.ietf-lisp-rfc6833bis]. The LISP mapping transport system exists in three flavors: LISP-ALT RFC 6836 [RFC6836] LISP NERD RFC 6837 [RFC6837] and LISP-DDT RFC 8111 [RFC8111], respectively. LISP data plane nodes, Ingress/Egress Tunnel Routers (ITR/ETR or xTR) registers mappings to the mapping system by sending Map-Register messages to the Map-Server(s). The Map Servers then publish these identifier locator values in the mapping system. There is Map-Resolver which accepts Map-Request messages from an ITR for the EID and returns the corresponding EID- to-RLOC-set mappings by consulting mapping database system in a Map- Reply message. All messages defined in the control plane are UDP messages. All read and write operations to the mapping system are authenticated with shared-keys using sha256 as well as ECDSA similar to DNSSEC as well as origin authentication, integrity and anti-replay protection [I-D.ietf-lisp-sec]. Note that ITRs keep a small scale identifier locator map of all values learned so far called a cache. In LISP mapping system, the lack of privacy support in the control plane for a given identifier value exists. On the data plane, LISP allows to encrypt identifiers [RFC8061]. Since ITR uses request/response exchange in getting the locator values, until a resolution response is received, packets for a flow may be blocked (like any other cache based solution), depending on the implementation policy. This means a Denial of Service attack on the ITR or cache has the worst case effect of indefinitely blocking a legitimate flow. Also the cache in ITR may raise privacy issue if EID-RLOC values for one UE is used for another UE. However, there are proposals for LISP to use a Publish/Subscribe approach [I-D.rodrigueznatal-lisp-pubsub]. While not yet explored, in the current LISP specification nothing prevents from using privacy addressing by way of UE simultaneously using different addresses for different connections chosen from a block of addresses in the data plane. 4. General Recommendations The use of new type of databases known as NoSQL databases organized as Key-value stores or mapping systems is recommended. Such databases will provide very efficient read and writes unlike DNS. von Hugo, et al. Expires November 26, 2018 [Page 5] Internet-Draft Atick Gap Analysis May 2018 NoSQL mapping systems mostly support a message-oriented middleware system called publish-subscribe or PubSub. In PubSub, publishers are loosely coupled to subscribers and offer better scalability than traditional client-server systems because of parallel operation, message caching and network based message routing. Such systems support sharding based on a shard key across different database servers. Publish/subscribe mechanism takes cares of the request/ response mechanism commonly used in DNS or other mapping systems and have better DDOS protection. Although a proposal exists as in [I-D.herbert-ila-ilamp], how such a Key-value store will be architectured in 5GC is not defined. Some guidelines for sharding need to be developed. How the mapping database will be sharded based on its identifier values as the key differently for each Id-Loc system can be defined. What is stored in the mapping system is limited to the identifier and locator values and no considerations to provide privacy of the stored data. There are many privacy improving mechanisms defined like locator/ identifier privacy of ILNP discussed in RFC 6748 [RFC6748], frequent address changing of ILA, establishing and managing security associations between participating entities etc. Each of these techniques can be used by any Id-loc system. There is a need to standardize these privacy techniques in order to enable wide scale use by the end nodes. 4.1. Security In the Data Path We address privacy problem for mapping systems: First we state the Atick privacy model which can be summarized as privacy at every levels. At the mapping system, the map data will be designed with privacy considerations so that the access will be enabled only for the allowed entities and disabled for any others. 5GC nodes/ functions that are ingress/egress nodes may have caches and a protocol may be needed to communicate with other 5GC nodes that are part of the mapping servers and contains a shard. 5GC nodes/functions that are not ingress/egress nodes are considered part of the mapping servers and they provide secure access to the mapping data and may contain part of the mapping database. Privacy will be enabled in all 5GC nodes/functions that deal with the mapping database. Such considerations will be implemented by way of the privacy additions to the data stored in the mapping database. End hosts or UEs will be able to have control over their own mapping records stored in the mapping database. End nodes or UEs that are unauthorized will not be able to have access to the location data of another UE. The same applies to the unauthorized entities or servers/functions in what 5G architecture calls outside data network (DN). von Hugo, et al. Expires November 26, 2018 [Page 6] Internet-Draft Atick Gap Analysis May 2018 5. IANA Considerations TBD. 6. Security Considerations 7. Acknowledgements 8. References 8.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. [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. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, . [RFC6740] Atkinson, RJ. and SN. Bhatti, "Identifier-Locator Network Protocol (ILNP) Architectural Description", RFC 6740, DOI 10.17487/RFC6740, November 2012, . [RFC6742] Atkinson, RJ., Bhatti, SN., and S. Rose, "DNS Resource Records for the Identifier-Locator Network Protocol (ILNP)", RFC 6742, DOI 10.17487/RFC6742, November 2012, . von Hugo, et al. Expires November 26, 2018 [Page 7] Internet-Draft Atick Gap Analysis May 2018 [RFC6748] Atkinson, RJ. and SN. Bhatti, "Optional Advanced Deployment Scenarios for the Identifier-Locator Network Protocol (ILNP)", RFC 6748, DOI 10.17487/RFC6748, November 2012, . [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol Alternative Logical Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836, January 2013, . [RFC6837] Lear, E., "NERD: A Not-so-novel Endpoint ID (EID) to Routing Locator (RLOC) Database", RFC 6837, DOI 10.17487/RFC6837, January 2013, . [RFC8061] Farinacci, D. and B. Weis, "Locator/ID Separation Protocol (LISP) Data-Plane Confidentiality", RFC 8061, DOI 10.17487/RFC8061, February 2017, . [RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, "Recommendation on Stable IPv6 Interface Identifiers", RFC 8064, DOI 10.17487/RFC8064, February 2017, . [RFC8111] Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. Smirnov, "Locator/ID Separation Protocol Delegated Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111, May 2017, . 8.2. Informative References [I-D.herbert-ila-ilamp] Herbert, T., "Identifier Locator Addressing Mapping Protocol", draft-herbert-ila-ilamp-00 (work in progress), December 2017. [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. von Hugo, et al. Expires November 26, 2018 [Page 8] Internet-Draft Atick Gap Analysis May 2018 [I-D.rodrigueznatal-ila-lisp] Rodriguez-Natal, A., Ermagan, V., Maino, F., and A. Cabellos-Aparicio, "LISP control-plane for Identifier Locator Addressing (ILA)", draft-rodrigueznatal-ila- lisp-01 (work in progress), April 2018. [I-D.rodrigueznatal-lisp-pubsub] Rodriguez-Natal, A., Ermagan, V., Leong, J., Maino, F., Cabellos-Aparicio, A., Barkai, S., Farinacci, D., Boucadair, M., Jacquenet, C., and S. Secci, "Publish/ Subscribe Functionality for LISP", draft-rodrigueznatal- lisp-pubsub-02 (work in progress), March 2018. [I-D.xyz-ideas-gap-analysis] Qu, Y., Cabellos-Aparicio, A., Moskowitz, R., Liu, B., and A. Stockmayer, "Gap Analysis for Identity Enabled Networks", draft-xyz-ideas-gap-analysis-00 (work in progress), July 2017. 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 Tom Herbert Quantonium Email: tom@quantonium.net Luigi Iannone Telecom ParisTech Email: ggx@gigix.net von Hugo, et al. Expires November 26, 2018 [Page 9] Internet-Draft Atick Gap Analysis May 2018 Saleem Bhatti University of St. Andrews Email: saleem@st-andrews.ac.uk von Hugo, et al. Expires November 26, 2018 [Page 10]