idnits 2.17.1 draft-xyz-atick-ps-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 (June 7, 2018) is 2149 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.ietf-lisp-rfc6830bis' is defined on line 234, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-lisp-rfc6833bis' is defined on line 240, but no explicit reference was found in the text == Unused Reference: 'RFC6740' is defined on line 251, but no explicit reference was found in the text == Unused Reference: 'I-D.herbert-intarea-ila' is defined on line 258, but no explicit reference was found in the text == Outdated reference: A later version (-38) exists of draft-ietf-lisp-rfc6830bis-12 == Outdated reference: A later version (-31) exists of draft-ietf-lisp-rfc6833bis-10 ** Downref: Normative reference to an Experimental RFC: RFC 6740 == Outdated reference: A later version (-13) exists of draft-ietf-intarea-tunnels-08 == Outdated reference: A later version (-29) exists of draft-ietf-lisp-sec-15 == Outdated reference: A later version (-01) exists of draft-xyzy-atick-gaps-00 Summary: 1 error (**), 0 flaws (~~), 11 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. von Hugo 3 Internet-Draft Deutsche Telekom 4 Intended status: Standards Track B. Sarikaya 5 Expires: December 9, 2018 Denpel Informatique 6 L. Iannone 7 Telecom ParisTech 8 T. Herbert 9 Quantonium 10 June 7, 2018 12 Problem Statement for Secure End to End Privacy Enabled Mapping System 13 draft-xyz-atick-ps-01.txt 15 Abstract 17 Problem Statement for Secure End to End Privacy Enabled Mapping 18 System for Identifier Locator separation systems is presented. Since 19 identifiers are often carried in packet headers in clear, and mapping 20 systems are often designed to be accessible by any entity, to 21 preserve identifier's privacy, lookups to the mapping system should 22 be allowed only by authorized entities. In mapping systems, in 23 addition to privacy, security also requires special attention because 24 of the caches introduced into the data path. Any denial of service 25 attacks on the cache should not allow the communication to come to an 26 end. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on December 9, 2018. 45 Copyright Notice 47 Copyright (c) 2018 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 64 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 65 3.1. Security In the Data Path . . . . . . . . . . . . . . . . 5 66 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 68 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 69 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 71 7.2. Informative References . . . . . . . . . . . . . . . . . 6 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 74 1. Introduction 76 Current 4G and the upcoming converged communication network of 5G 77 core network (5GC) make use of tunneling with anchor points to handle 78 mobility, policy and quality of service. The use of IP addresses 79 induces the topology and enables easy location tracking. Elimination 80 or reduction of anchor points, as well as disassociating topology 81 from IP addresses to facilitate efficient mobility and user privacy 82 using Identifier Locator separation systems like Identifier Locator 83 Addressing, The Locator/ID Separation Protocol and others is needed. 84 Many drawbacks of tunneling are discussed in 85 [I-D.ietf-intarea-tunnels] and we do not repeat them here. 87 This document attempts to make the case for the use of the identifier 88 locator separation (Id-Loc) protocols in the data plane and 89 identifies the problems for such a large scale use. The problems 90 identified mainly are privacy of the identifiers and associated 91 locators and security issues. 93 2. Conventions and Terminology 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in RFC 2119 [RFC2119]. 99 Identifier: An identifier is information to unambiguously identify an 100 entity or an entity group within a given scope. An identifier is the 101 equivalent of an End point identifier (EID) in The Locator/ID 102 Separation Protocol (LISP). It may be visible in communications. 104 Locator: A locator is a routable network address. It may be 105 associated with an identifier and used for communication on the 106 network layer according to identifier locator split principle. A 107 locator is the equivalent of a Routing Locator (RLOC) in LISP or an 108 IP address in other cases. 110 3. Problem Statement 112 Identifier represents a communication end-point of an entity and may 113 not be routable. Locator also represents a communication end point, 114 i.e. its routable network address and thus can change if the entity 115 moves. A database called a mapping system needs to be used for 116 identifier to locator mapping. Identifiers are mapped to locators 117 for forwarding purposes. Mapping system has to handle mobility by 118 modifying identifier to locator mappings in the database. 120 To start the communication, a device needs to know the identifier of 121 the destination and then relies on a process to lookup on a network 122 identifier and return the locator(s). Note that both identifier and 123 locator can be carried in clear in packet headers. 125 Usage of identifiers readily available for public access raises 126 privacy issues. For public entities, it may be desirable to have 127 their fully qualified domain names or host names available for public 128 lookups by the clients however such is not the case in general for 129 the identifiers, e.g. for individuals roaming in a mobile network. 131 This document describes the problem statement for a new kind of 132 mapping system to be used by identifier locator separation systems 133 (Id-Loc) that are end to end privacy enabled. 135 Heavy use of tunneling with fixed anchors: 137 Current 4G and the upcoming converged communication network of 5G 138 core network (5GC) make use of tunneling with anchor points to handle 139 mobility, policy and quality of service. The use of IP addresses 140 induces the topology and enables easy location tracking. Elimination 141 or reduction of anchor points, as well as disassociating topology 142 from IP addresses to facilitate efficient mobility and user privacy 143 using Identifier Locator separation systems is needed. Increasing 144 packet overhead due to encapsulation that may cause fragmentation and 145 all related issues typical disadvantages of (especially static end- 146 to-end) tunneling comprise inflexibility to properly react to dynamic 147 changes of end points and potential on-path anchors which is required 148 to support mobility. Added complexity of increased signaling for 149 tunnel management are further drawbacks [I-D.ietf-intarea-tunnels]. 151 Proposed 5G operation: 153 The use of GTP is proposed to tunnel UE packets from the base 154 station, gNB to the User Plane Function (UPF) in N3 interface 155 establishes a fixed anchor for UE traffic and UPF further GTP tunnels 156 to another UPF in N9 interface which is connected to an external data 157 network (DN). Access and Session Management control plane functions 158 (AMF, SMF) push such configuration setup to the data plane functions. 159 With such a rigid setup user mobility as well as UE receiving traffic 160 on multiple interfaces can not be handled efficiently. UE to another 161 UE traffic has to go to the fixed anchor since gNBs are not mobility 162 anchors. Also due to the induced delays, delay sensitive 163 applications such as Ultra Reliable Low Latency (URLL) applications 164 can not be supported. 166 IP Addressing Reveals geographic location: 168 Addressing scheme in use currently reveal the topology of the 169 internet and thus location privacy of the end nodes can not be 170 established. Move away from this heavy use of locators is needed in 171 favor of identifier locator separation systems. 173 Gap Analysis: 175 Gaps in mapping solutions developed so far in Id-Loc systems reveal 176 the fact that secure end to end privacy enabled mapping system 177 approach is needed across the board [I-D.xyzy-atick-gaps]. 179 Access to a mapping system should not reveal the location about an 180 entity to the unauthorized requestor of a look up on an identifier. 181 Tracking of the identifiers of an entity and mounting attacks based 182 on that should be avoided. On the other hand discovery by the 183 entities that are allowed to should not be made difficult. This may 184 be possible by using encryption effectively in the control plane 185 mechanisms to avoid eavesdroppers to access such information 186 [I-D.ietf-lisp-sec]. 188 If locators/ addresses (or device prefixes) are common between flows 189 for a given entity then a third party can make inferences (i.e. 190 whether they are sourced from the same host). This points to the 191 problem of persistent identifiers which should be avoided. 193 Compromise of a mapping system is very bad since it would allow 194 attackers to take control of traffic and to misdirect it. 196 If locators/ addresses contain fine grained topology then device 197 location (and hence user location) can be inferred. This gets to the 198 problem that locators may contain detailed geographic location 199 information and hence are very sensitive data. This points to the 200 need for using identifier locator separation. 202 Scaling is an issue for mapping systems built using very high 203 performance massively distributed noSQL databases. Slow moving or 204 fixed hosts can probably induce light loads on mapping systems. In 205 5G case, very high number of devices moving at high speeds this 206 changes drastically, i.e. very heavy load is induced on the mapping 207 system. Mapping systems that scale to 100s of millions of entries 208 with 100s of milliseconds response times are needed. State of the 209 art shows that such systems can be built and operated with the use of 210 thousands of servers worldwide. 212 3.1. Security In the Data Path 214 If a cache is introduced into the data path (as might be the case in 215 some mapping systems) then that in turn will introduce potential DoS 216 attacks in order to slow down or even completely stop the 217 communication. So proper protocol actions and security policies 218 should be taken against DoS attacks. 220 Compromise of a mapping system is very bad since it would allow 221 attackers to take control of traffic and to misdirect it. 223 4. IANA Considerations 225 TBD. 227 5. Security Considerations 229 6. Acknowledgements 231 7. References 232 7.1. Normative References 234 [I-D.ietf-lisp-rfc6830bis] 235 Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. 236 Cabellos-Aparicio, "The Locator/ID Separation Protocol 237 (LISP)", draft-ietf-lisp-rfc6830bis-12 (work in progress), 238 March 2018. 240 [I-D.ietf-lisp-rfc6833bis] 241 Fuller, V., Farinacci, D., and A. Cabellos-Aparicio, 242 "Locator/ID Separation Protocol (LISP) Control-Plane", 243 draft-ietf-lisp-rfc6833bis-10 (work in progress), March 244 2018. 246 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 247 Requirement Levels", BCP 14, RFC 2119, 248 DOI 10.17487/RFC2119, March 1997, 249 . 251 [RFC6740] Atkinson, RJ. and SN. Bhatti, "Identifier-Locator Network 252 Protocol (ILNP) Architectural Description", RFC 6740, 253 DOI 10.17487/RFC6740, November 2012, 254 . 256 7.2. Informative References 258 [I-D.herbert-intarea-ila] 259 Herbert, T. and P. Lapukhov, "Identifier-locator 260 addressing for IPv6", draft-herbert-intarea-ila-01 (work 261 in progress), March 2018. 263 [I-D.ietf-intarea-tunnels] 264 Touch, J. and M. Townsley, "IP Tunnels in the Internet 265 Architecture", draft-ietf-intarea-tunnels-08 (work in 266 progress), January 2018. 268 [I-D.ietf-lisp-sec] 269 Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. 270 Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-15 271 (work in progress), April 2018. 273 [I-D.xyzy-atick-gaps] 274 Hugo, D., Sarikaya, B., Herbert, T., Iannone, L., and S. 275 Bhatti, "Gap and Solution Space Analysis for End to End 276 Privacy Enabled Mapping System", draft-xyzy-atick-gaps-00 277 (work in progress), May 2018. 279 Authors' Addresses 281 Dirk von Hugo 282 Deutsche Telekom 283 Deutsche-Telekom-Allee 7 284 D-64295 Darmstadt 285 Germany 287 Email: Dirk.von-Hugo@telekom.de 289 Behcet Sarikaya 290 Denpel Informatique 292 Email: sarikaya@ieee.org 294 Luigi Iannone 295 Telecom ParisTech 297 Email: ggx@gigix.net 299 Tom Herbert 300 Quantonium 302 Email: tom@herbertland.com