idnits 2.17.1 draft-xyzy-atick-gaps-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 2143 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: 'RFC4941' is defined on line 280, but no explicit reference was found in the text == Unused Reference: 'RFC8064' is defined on line 300, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-intarea-tunnels' is defined on line 322, but no explicit reference was found in the text == Unused Reference: 'I-D.xyz-ideas-gap-analysis' is defined on line 346, 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 == Outdated reference: A later version (-29) exists of draft-ietf-lisp-sec-15 ** Obsolete normative reference: RFC 4941 (Obsoleted by RFC 8981) ** Downref: Normative reference to an Experimental RFC: RFC 6836 ** Downref: Normative reference to an Experimental RFC: RFC 6837 ** Downref: Normative reference to an Experimental RFC: RFC 8061 ** Downref: Normative reference to an Experimental RFC: RFC 8111 == Outdated reference: A later version (-13) exists of draft-ietf-intarea-tunnels-08 == Outdated reference: A later version (-01) exists of draft-xyz-atick-ps-00 Summary: 5 errors (**), 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 T. Herbert 7 Quantonium 8 L. Iannone 9 Telecom ParisTech 10 June 7, 2018 12 Gap and Solution Space Analysis for End to End Privacy Enabled Mapping 13 System 14 draft-xyzy-atick-gaps-01.txt 16 Abstract 18 This document presents a gap and solution analysis for end-to-end 19 privacy enabled mapping systems. Each of the identifier locator 20 separation system has its own approach to mapping identifiers to the 21 locators. We analyse all these approaches and identify the gaps in 22 each of them and do a solution space analysis in an attempt to 23 identify a mapping system that can be end to end privacy enabled. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on December 9, 2018. 42 Copyright Notice 44 Copyright (c) 2018 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 61 3. Gap and Solution Space Analysis . . . . . . . . . . . . . . . 3 62 3.1. ILA . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3.2. LISP . . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 4. General Recommendations . . . . . . . . . . . . . . . . . . . 5 65 4.1. Security In the Data Path . . . . . . . . . . . . . . . . 5 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 68 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 71 8.2. Informative References . . . . . . . . . . . . . . . . . 7 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 74 1. Introduction 76 Identifier Locator Systems like ILA [I-D.herbert-intarea-ila], LISP 77 [I-D.ietf-lisp-rfc6830bis] [I-D.ietf-lisp-rfc6833bis] and others are 78 proposed as alternative approaches to enabling direct routing in the 79 upcoming converged communication networks such as 5G core network 80 (5GC) rather than using tunneling with GTP-U, GRE, (P)MIPv6 or 81 similar ones. In addition to increasing packet overhead due to 82 encapsulation that may cause fragmentation and all related issues 83 typical disadvantages of (especially static end-to-end) tunneling 84 comprise inflexibility to properly react to dynamic changes of end 85 points and potential on-path anchors. Added complexity in case of 86 multicast traffic and increased signaling for tunnel management are 87 further drawbacks. Tunnels may introduce vulnerabilities or add to 88 the potential for receiver overload and thus DOS attacks [draft-ietf- 89 intarea-tunnels-08]. Finally without other measures such as deep 90 packet inspection optimization of paths according to network 91 resources and application needs becomes complex. 93 With the Id-Loc systems a mapping system needs to be established so 94 that 5GC nodes or functions can access the identifier and locator 95 values of the destination given the source identifier and locator 96 values to enable them to route the packet towards the destination. 98 For mapping systems there will be a trade-off between scalability and 99 rapid processing versus privacy and security of data. 101 A public distributed database such as the DNS is used by end hosts 102 for host name (or FQDN) to identifier mapping usually to start the 103 communication. DNS can be used to publicly access identifiers. 104 However, using DNS for locator access brings the issue that any node 105 in the internet can query and track the location of the roaming UEs 106 in 5G network which is not desirable. A separate database called a 107 mapping system needs to be used for identifier to locator mapping. 108 Such a mapping system need not be public in order to avoid that any 109 node can write new mapping pairs or ID-Loc bindings in such a 110 database. 112 2. Conventions and Terminology 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in RFC 2119 [RFC2119]. 118 See the definitions in [I-D.xyz-atick-ps]. 120 3. Gap and Solution Space Analysis 122 3.1. ILA 124 ILA is currently using a distributed key value (KV) store for 125 identifier locator mapping [I-D.herbert-ila-ilamp]. The key value 126 NoSQL database also supports publish/subscribe where the senders or 127 publishers send the messages while the receivers or subscribers 128 receive them and the link by which the messages are transferred is 129 called channel. Such an approach avoids developing a request 130 response protocol in order to update the mapping database with new 131 identifier locator values or to access locator values for a given 132 identifier and also leverages all the recent developments for 133 security, availability, reliability, replication, etc. ILA 134 forwarding nodes (ILA-N) maintain caches of identifier locator values 135 learned so far but these values are UE specific. The ILA Mapping 136 Protocol (ILAMP) [I-D.herbert-ila-ilamp] is used between ILA 137 forwarding nodes and ILA mapping routers (ILA-R). The purpose of the 138 protocol is to populate and maintain the ILA mapping cache in 139 forwarding nodes. ILA-N sends Map Request message to ILA-R with a 140 list of identifiers and ILA-R replies with Map Information message 141 with identifier to locator mappings. ILA-R contains a horizontal 142 partition of the whole identifier locator database called a shard. 143 LISP style request/response protocol based mapping system can also be 144 used by ILA as defined in [I-D.rodrigueznatal-ila-lisp]. 146 Privacy is addressed in the data plane by way of UE simultaneously 147 using different addresses for different connections chosen from a 148 block of addresses. It is observed that NAT can also provide address 149 privacy but the use of NAT is discouraged in IETF. UE needs to 150 reestablish connections every time it changes its address so address 151 changing incurs delays which could be significant in case of real- 152 time communication unless connections can be made simultaneously 153 ('make before break'). 155 3.2. LISP 157 In LISP, FQDN to identifier or EID mappings are stored in DNS. The 158 LISP control-plane interface to the identifier-locator or EID-RLOC 159 mapping system is defined in [I-D.ietf-lisp-rfc6833bis]. The LISP 160 mapping transport system exists in three flavors: LISP-ALT RFC 6836 161 [RFC6836] LISP NERD RFC 6837 [RFC6837] and LISP-DDT RFC 8111 162 [RFC8111], respectively. LISP data plane nodes, Ingress/Egress 163 Tunnel Routers (ITR/ETR or xTR) registers mappings to the mapping 164 system by sending Map-Register messages to the Map-Server(s). The 165 Map Servers then publish these identifier locator values in the 166 mapping system. There is Map-Resolver which accepts Map-Request 167 messages from an ITR for the EID and returns the corresponding EID- 168 to-RLOC-set mappings by consulting mapping database system in a Map- 169 Reply message. All messages defined in the control plane are UDP 170 messages. All read and write operations to the mapping system are 171 authenticated with shared-keys using sha256 as well as ECDSA similar 172 to DNSSEC as well as origin authentication, integrity and anti-replay 173 protection [I-D.ietf-lisp-sec]. 175 Note that ITRs keep a small scale identifier locator map of all 176 values learned so far called a cache. In LISP mapping system, the 177 lack of privacy support in the control plane for a given identifier 178 value exists. On the data plane, LISP allows to encrypt identifiers 179 [RFC8061]. Since ITR uses request/response exchange in getting the 180 locator values, until a resolution response is received, packets for 181 a flow may be blocked (like any other cache based solution), 182 depending on the implementation policy. This means a Denial of 183 Service attack on the ITR or cache has the worst case effect of 184 indefinitely blocking a legitimate flow. Also the cache in ITR may 185 raise privacy issue if EID-RLOC values for one UE is used for another 186 UE. However, there are proposals for LISP to use a Publish/Subscribe 187 approach [I-D.rodrigueznatal-lisp-pubsub]. While not yet explored, 188 in the current LISP specification nothing prevents from using privacy 189 addressing by way of UE simultaneously using different addresses for 190 different connections chosen from a block of addresses in the data 191 plane. 193 4. General Recommendations 195 The use of new type of databases known as NoSQL databases organized 196 as Key-value stores or mapping systems is recommended. Such 197 databases will provide very efficient read and writes unlike DNS. 198 NoSQL mapping systems mostly support a message-oriented middleware 199 system called publish-subscribe or PubSub. In PubSub, publishers are 200 loosely coupled to subscribers and offer better scalability than 201 traditional client-server systems because of parallel operation, 202 message caching and network based message routing. Such systems 203 support sharding based on a shard key across different database 204 servers. Publish/subscribe mechanism takes cares of the request/ 205 response mechanism commonly used in DNS or other mapping systems and 206 have better DDOS protection. Although a proposal exists as in 207 [I-D.herbert-ila-ilamp], how such a Key-value store will be 208 architectured in 5GC is not defined. Some guidelines for sharding 209 need to be developed. How the mapping database will be sharded based 210 on its identifier values as the key differently for each Id-Loc 211 system can be defined. 213 What is stored in the mapping system is limited to the identifier and 214 locator values and no considerations to provide privacy of the stored 215 data. 217 There are many privacy improving mechanisms defined like locator/ 218 identifier privacy of frequent address changing of ILA, establishing 219 and managing security associations between participating entities 220 etc. Each of these techniques can be used by any Id-loc system. 221 There is a need to standardize these privacy techniques in order to 222 enable wide scale use by the end nodes. 224 4.1. Security In the Data Path 226 We address privacy problem for mapping systems: First we state the 227 Atick privacy model which can be summarized as privacy at every 228 levels. At the mapping system, the map data will be designed with 229 privacy considerations so that the access will be enabled only for 230 the allowed entities and disabled for any others. 5GC nodes/ 231 functions that are ingress/egress nodes may have caches and a 232 protocol may be needed to communicate with other 5GC nodes that are 233 part of the mapping servers and contains a shard. 5GC nodes/functions 234 that are not ingress/egress nodes are considered part of the mapping 235 servers and they provide secure access to the mapping data and may 236 contain part of the mapping database. Privacy will be enabled in all 237 5GC nodes/functions that deal with the mapping database. Such 238 considerations will be implemented by way of the privacy additions to 239 the data stored in the mapping database. End hosts or UEs will be 240 able to have control over their own mapping records stored in the 241 mapping database. End nodes or UEs that are unauthorized will not be 242 able to have access to the location data of another UE. The same 243 applies to the unauthorized entities or servers/functions in what 5G 244 architecture calls outside data network (DN). 246 5. IANA Considerations 248 TBD. 250 6. Security Considerations 252 7. Acknowledgements 254 8. References 256 8.1. Normative References 258 [I-D.ietf-lisp-rfc6830bis] 259 Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. 260 Cabellos-Aparicio, "The Locator/ID Separation Protocol 261 (LISP)", draft-ietf-lisp-rfc6830bis-12 (work in progress), 262 March 2018. 264 [I-D.ietf-lisp-rfc6833bis] 265 Fuller, V., Farinacci, D., and A. Cabellos-Aparicio, 266 "Locator/ID Separation Protocol (LISP) Control-Plane", 267 draft-ietf-lisp-rfc6833bis-10 (work in progress), March 268 2018. 270 [I-D.ietf-lisp-sec] 271 Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. 272 Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-15 273 (work in progress), April 2018. 275 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 276 Requirement Levels", BCP 14, RFC 2119, 277 DOI 10.17487/RFC2119, March 1997, 278 . 280 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 281 Extensions for Stateless Address Autoconfiguration in 282 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 283 . 285 [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, 286 "Locator/ID Separation Protocol Alternative Logical 287 Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836, 288 January 2013, . 290 [RFC6837] Lear, E., "NERD: A Not-so-novel Endpoint ID (EID) to 291 Routing Locator (RLOC) Database", RFC 6837, 292 DOI 10.17487/RFC6837, January 2013, 293 . 295 [RFC8061] Farinacci, D. and B. Weis, "Locator/ID Separation Protocol 296 (LISP) Data-Plane Confidentiality", RFC 8061, 297 DOI 10.17487/RFC8061, February 2017, 298 . 300 [RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, 301 "Recommendation on Stable IPv6 Interface Identifiers", 302 RFC 8064, DOI 10.17487/RFC8064, February 2017, 303 . 305 [RFC8111] Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. 306 Smirnov, "Locator/ID Separation Protocol Delegated 307 Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111, 308 May 2017, . 310 8.2. Informative References 312 [I-D.herbert-ila-ilamp] 313 Herbert, T., "Identifier Locator Addressing Mapping 314 Protocol", draft-herbert-ila-ilamp-00 (work in progress), 315 December 2017. 317 [I-D.herbert-intarea-ila] 318 Herbert, T. and P. Lapukhov, "Identifier-locator 319 addressing for IPv6", draft-herbert-intarea-ila-01 (work 320 in progress), March 2018. 322 [I-D.ietf-intarea-tunnels] 323 Touch, J. and M. Townsley, "IP Tunnels in the Internet 324 Architecture", draft-ietf-intarea-tunnels-08 (work in 325 progress), January 2018. 327 [I-D.rodrigueznatal-ila-lisp] 328 Rodriguez-Natal, A., Ermagan, V., Maino, F., and A. 329 Cabellos-Aparicio, "LISP control-plane for Identifier 330 Locator Addressing (ILA)", draft-rodrigueznatal-ila- 331 lisp-01 (work in progress), April 2018. 333 [I-D.rodrigueznatal-lisp-pubsub] 334 Rodriguez-Natal, A., Ermagan, V., Leong, J., Maino, F., 335 Cabellos-Aparicio, A., Barkai, S., Farinacci, D., 336 Boucadair, M., Jacquenet, C., and S. Secci, "Publish/ 337 Subscribe Functionality for LISP", draft-rodrigueznatal- 338 lisp-pubsub-02 (work in progress), March 2018. 340 [I-D.xyz-atick-ps] 341 Hugo, D., Sarikaya, B., Iannone, L., and T. Herbert, 342 "Problem Statement for Secure End to End Privacy Enabled 343 Mapping System", draft-xyz-atick-ps-00 (work in progress), 344 May 2018. 346 [I-D.xyz-ideas-gap-analysis] 347 Qu, Y., Cabellos-Aparicio, A., Moskowitz, R., Liu, B., and 348 A. Stockmayer, "Gap Analysis for Identity Enabled 349 Networks", draft-xyz-ideas-gap-analysis-00 (work in 350 progress), July 2017. 352 Authors' Addresses 354 Dirk von Hugo 355 Deutsche Telekom 356 Deutsche-Telekom-Allee 7 357 D-64295 Darmstadt 358 Germany 360 Email: Dirk.von-Hugo@telekom.de 362 Behcet Sarikaya 363 Denpel Informatique 365 Email: sarikaya@ieee.org 367 Tom Herbert 368 Quantonium 370 Email: tom@quantonium.net 372 Luigi Iannone 373 Telecom ParisTech 375 Email: ggx@gigix.net