idnits 2.17.1 draft-xyz-ideas-gap-analysis-00.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 date (July 3, 2017) is 2490 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC4984' is mentioned on line 82, but not defined == Missing Reference: 'Ideas' is mentioned on line 503, but not defined == Unused Reference: 'RFC7402' is defined on line 410, but no explicit reference was found in the text ** Obsolete normative reference: RFC 6830 (Obsoleted by RFC 9300, RFC 9301) ** Obsolete normative reference: RFC 6833 (Obsoleted by RFC 9301) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Qu, Ed. 3 Internet-Draft Huawei 4 Intended status: Informational A. Cabellos 5 Expires: January 4, 2018 Technical University of Catalonia 6 R. Moskowitz 7 HTT Consulting 8 B. Liu 9 Huawei 10 A. Stockmayer 11 University of Tuebingen 12 July 3, 2017 14 Gap Analysis for Identity Enabled Networks 15 draft-xyz-ideas-gap-analysis-00 17 Abstract 19 Currently there are several identifier/locator separation protocols, 20 such as HIP, ILA, ILNA and LISP. This document analyzes the 21 technical gaps between existing solutions and today's privacy 22 requirements. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on January 4, 2018. 41 Copyright Notice 43 Copyright (c) 2017 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Specification of Requirements . . . . . . . . . . . . . . . . 3 60 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3 61 4. Overview of ID/LOC Protocols . . . . . . . . . . . . . . . . 4 62 4.1. LISP . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 4.2. HIP . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 4.3. ILA . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 5. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . 6 66 5.1. The Split of Identity and Identifier . . . . . . . . . . 6 67 5.2. A Common Identifier-to-Locator Mapping System . . . . . . 7 68 5.3. User-Defined Access Policies in the Mapping System . . . 7 69 6. Analysis of DNS . . . . . . . . . . . . . . . . . . . . . . . 7 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 71 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 72 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 73 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 74 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 75 11.1. Normative References . . . . . . . . . . . . . . . . . . 8 76 11.2. Informative References . . . . . . . . . . . . . . . . . 10 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 79 1. Introduction 81 The separation of location and identifier has been discussed for many 82 years, as documented in [RFC4984]. IP addresses have been overloaded 83 to serve as both locators and identifiers. Several identifier and 84 locator separation (ID/LOC) protocols have been proposed, such as HIP 85 [RFC7401], [ILA] and LISP [RFC6830]. They create two separate 86 namespaces: identifiers (IDfs) and Locators (LOCs). Identifiers 87 uniquely identify network entities no matter where they are located, 88 and locators are assigned based on topology information and are 89 typically routable. 91 In an ID/LOC protocol, a service is needed to maintain mappings 92 between identifiers and locators and to perform lookups from 93 identifiers to locators (and probably vice-verse). Currently each 94 ID-based protocol uses its own mapping database and mechanism to get 95 this mapping information [RFC6836][RFC8005]. 97 As pointed out by [IDEAS-PS][IDEAS-IDY-USE], the concept of identity 98 (IDy) tied to a network entity can help to solve some of the privacy 99 issues that are associated with today's networks. The goal of this 100 document is to analyze the technical gaps between the existing ID/LOC 101 protocols and today's requirements. The following gaps are 102 summarized: the split of identifier and identity; a common mapping 103 system supporting both IDf/LOC mapping and IDy/IDf mapping; and user- 104 defined access policies. 106 2. Specification of Requirements 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in [RFC2119]. 112 3. Definition of Terms 114 This document makes use of the terms that have been already defined 115 in the problem statement draft of IDEAS [IDEAS-PS]. They are 116 included here for reader's convenience. In case of any discrepancies 117 between the two drafts, the problem statement draft overrides. 119 Entity: An entity is a communication endpoint. It can be a device, a 120 node, or a virtual machine (VM), that needs to be identified. An 121 entity may have one or multiple identifiers (long-lived or ephemeral) 122 simultaneously. An entity is reached by the resolution of one or 123 more of its identifiers to one or more locators. 125 Identity (IDy): the essence of "being" of a specific entity. An 126 identity is not to be confused with an identifier: while an 127 identifier may be used to refer to an entity, an identifier's 128 lifecycle is not necessarily tied to the lifecycle of the Identity it 129 is referencing. On the other hand, the identity's lifecycle is 130 inherently tied to the lifecycle of the entity itself. 132 Identifier (IDf): denotes information to unambiguously identify an 133 entity within a given scope (e.g. HIP HIT, LISP EID). There is no 134 constraint on the format, obfuscation or routability of an IDy. The 135 IDy may or may not be present in the packet whose format is defined 136 by ID-based protocols (HIP/LISP). 138 Identifier-based (ID-based): When an entity is only reachable through 139 one or more communication access then a protocol or a solution is 140 said to be ID-based if it uses an ID-LOC decoupling and a mapping 141 system (MS) as base components of the architecture. Examples of ID- 142 based protocols are HIP, LISP and ILA. 144 IDentity Enabled Networks (IDEAS): IDEAS are networks that support 145 the identifier/locator decoupling. Reaching an entity is achieved by 146 the resolution of identifier(s) to locator(s). 148 Locator (LOC): denotes information that is topology-dependent and 149 which is used to forward packets to a given entity attached to a 150 network (IPv4/IPv6/L2/L2.5 Address). An entity can be reached using 151 one or multiple locators; these locators may have a limited validity 152 lifetime. 154 ID/LOC: Identifier and Locator Separation. 156 LISP: Locator/ID Separation Protocol. 158 HIP: Host Identity Protocol. 160 ILNP: Identifier-Locator Network Protocol. 162 ILA: Identifier-Locator Addressing. 164 DNS: Domain Name System. 166 4. Overview of ID/LOC Protocols 168 4.1. LISP 170 The Locator/ID Separation Protocol (LISP) [RFC6830] is structured 171 around four main components: the data plane, the control plane (both 172 specified in [RFC6830]), the LISP Mapping System Interface [RFC6833] 173 and the Mapping System (e.g., LISP-DDT [RFC8111] and LISP+ALT 174 [RFC6836]). 176 The LISP architecture decouples identifier and locator by means of 177 the mapping system interface. This well-defined interface separates 178 data/control from the mapping system architecture. As a result, LISP 179 does not assume any mapping system architecture. The LISP WG has, at 180 the time of this writing, specified two mapping systems: LISP-DDT 181 [RFC8111] and LISP-ALT [RFC6836]. 183 Both mapping system assume hierarchical identifiers, but the WG has 184 explored other architectures such as DHT for flat identifiers, or 185 monolithic mapping systems. 187 One of the main design principles behind LISP is to decouple the 188 identifier (EIDs) from the locators (RLOCs). By means of the LISP 189 Canonical Address Format (LCAF) [RFC8060] LISP provides a flexible 190 syntax to encode both EIDs and RLOCs. 192 In terms of security, LISP supports authorization for mapping updates 193 and the authentication of the clients updating such information. 194 This is achieved by means of the authentication data field in the 195 Map-Register message. In addition, LISP clients can verify the 196 security of data origin, authentication and delegation. This is 197 specified in [LISP-SEC] and the security mechanisms incorporated in 198 LISP-DDT [RFC8111]. 200 4.2. HIP 202 The Host Identity Protocol (HIP) [RFC7401] is a SIGMA-security 203 compliant exchange of current entity location for a pair of 204 cryptographically ownership provable Identifiers (HITs). HIP is, at 205 its inception, focused on the management of the Identifier/Location 206 mapping. HITs are valid, non-routable IPv6 addresses that carry the 207 cryptographic protocol suite and a hash of the HI (Host Identity 208 public key). 210 One method of discovery of a peer's HIT and initial location is 211 either via DNS RR 55 [RFC8005] with A|AAAA RR to the peer or A|AAAA 212 RR pointing to the peer's Rendezvous Service (RVS) server [RFC8004]. 213 The Initiating peer cannot detect from DNS the difference in 214 destination. The RVS server "slingshots" the I1 packet to the 215 recipient. The recipient decides, based on local policy, to respond 216 with the next exchange packet, R1. Thus using an RVS server not only 217 supports client mobility, it also hides a peer's location unless it 218 wants to be 'found'. 220 HIP provides Identity/Location separation through changes in the peer 221 IP stack behavior with only needing RVS added to the infrastructure. 222 HIP aware systems register to their RVS server(s) via a HIP exchange, 223 augmented with an RVS registration parameter [RFC8003]. All location 224 changes are made securely over HIP [RFC8046]. Location changes are 225 sent directly to peers and to the RVS server(s). HIP fully supports 226 double jumps (both peers move) and state lose recovery (full protocol 227 state machine). 229 HIP supports multihomed systems [RFC8047], fully decoupling 230 Identifier (HITs) from all interfaces. Multiple data-paths are 231 enabled with HIP. ESP via BEET mode [rfc7402] is most commonly used. 232 L2VPNs support is defined in [HIP-VPLS] and provided in commercial 233 products targeting SCADA environments. A non-cryptographic envelope 234 is proposed [HIP-IP]. 236 HIP works equally well over IPv4 or IPv6 networks. The HIP data-path 237 can be either IPv4 (via the HIP 32-bit Local Scope Identifier) or 238 IPv6 using the HIT. IPv4 applications can run transparently over 239 IPv6 and IPv6 over IPv4. 241 HIP well supports Identifiers to location, and weakly Identity to 242 Identifiers. Besides DNS support, identities may be supported in HIP 243 with X.509 certificates [rfc8002] to provide 3rd party assertions of 244 HITs and HIs. Identifiers to Identity reversal is poorly handled, 245 though potentially needed for support of FTP PASV and other protocols 246 with embedded addresses. DHT has been demonstrated [RFC6537], but 247 not fielded. The new work on Hierarchical HITs [HHIT] proposes new 248 methods to couple DNS and a registry for the reverse lookup. 250 4.3. ILA 252 In [ILA], an IPv6 address is divided into two parts: a locator and an 253 identifier. As other ID/LOC protocol, the locator indicates the 254 topological location of a network entity, and the identifier 255 identifies the entity in communications. ILA can be used to 256 implement overlay networks for network virtualization, and also 257 addresses use cases in mobility. 259 However, the mapping service in ILA is still TBD [ILA-MS-TBD]. 261 5. Gap Analysis 263 5.1. The Split of Identity and Identifier 265 In existing ID/LOC Protocols, the IDf/LOC mappings stored in the 266 mapping system are assumed to be public. A legitimate requestor can 267 lookup any record, and escape access control policy, if there is any, 268 by changing to a different identifier. Also a network entity may 269 want to hide its true identity for privacy protection by using 270 ephemeral identifiers [LISP-ANNOY]. 272 To address these issues, [IDEAS-PS] introduces the concept of 273 identity (IDy). An IDy uniquely identifies "who" is a communication 274 entity. Identifier and locator together identifies "where" is the 275 entity. With this 2-tier identification, multiple identifiers can be 276 bound to the same entity (IDy) and exchanged in clear on the wire, 277 without having to worry about the identity being compromised by 278 outside observers. 280 Since the lifecycle of an identity is the same as the entity, the 281 lifecycles of identity and its associated identifiers are decoupled. 282 It is possible for identifiers to be added or removed without 283 affecting the identity. This further abstraction can bring 284 additional benefits. [IDEAS-IDY-USE] describes the identity use 285 cases. 287 In summary: 289 o The notion of identity is not adequately supported. 291 o Two tiers of identification are needed, with identifiers anchored 292 at the identity. 294 5.2. A Common Identifier-to-Locator Mapping System 296 IDf/LOC mapping service is essential for ID/LOC protocols [RFC6833], 297 however now each protocol is using its own mapping database even 298 within the same administrative domain. This potentially adds 299 additional operational cost and management complexity. 301 A common mapping system supporting both IDf/LOC mapping and IDy/IDf 302 mapping can work with existing ID/LOC protocols, as well as add extra 303 identity based services. It can provide consistent access control, 304 common interface for services such as registration, discovery and 305 resolution. A unified database can help to ease network management 306 [IDEAS-PS]. 308 5.3. User-Defined Access Policies in the Mapping System 310 Different from DNS, which generally maintains public name-to-IP 311 mapping information, an IDf/LOC mapping system maintains more private 312 information. However existing mapping systems assume the information 313 stored is public, and this may cause privacy violation. A network 314 entity may want to set a customized access policy to control who can 315 get its identifier and location information. This policy should be 316 tied to identity, so it is not affected by identifier changes of the 317 requestor. 319 General system-wide access control (e.g., an operator can set a 320 system-wide access control list for a DNS server, only permitting the 321 customer network prefixes to access it) can provide some privacy, but 322 it is not sufficient. What is needed are: fine-grained level of 323 access control at the level of data records associated with each 324 individual entity; and reinforcement of the access policies. 326 6. Analysis of DNS 328 Since the 1980s, DNS has been pivotal to translate human readable 329 names that are easy to remember into hard-to-remember IP addresses. 330 It provides a global distributed directory service and is a very 331 powerful and useful technology to translate the domain name hierarchy 332 to IP address space. 334 Even though the DNS was designed to be resilient, it is prone to DDOS 335 attacks as discussed extensively in the Technical Plenary of IETF97. 336 Furthermore, some studies have also described challenges in the 337 response time and caching techniques and latency in the Internet 338 [DNS1] [DNS2] [DNS3] [GNRS]. 340 [DNS-DUP] proposed a mobility solution using DNS dynamic updating 341 protocol. However for a communication session when both hosts are 342 moving, the session fails and the hosts SHOULD query DNS and get the 343 new address and then restart the communications. 345 The use of a mapping system rather than using DNS system has been 346 discussed extensively in [IVIP], [RFC6115], on the lisp-wg mailing 347 list [LISP-DIS], and initial HIP design team (circa 1999-2003). 349 7. Security Considerations 351 IDEAS control plane may be used to maintain and transmit confidential 352 data, such as identity, access policy and metadata. Access to the 353 data needs to be authorized/authenticated. Control plane messages 354 containing such data need to be encrypted. The exact details of 355 encryption/authentication are topics for future research. 357 8. IANA Considerations 359 This document has no actions for IANA. 361 9. Contributors 363 TBD. 365 10. Acknowledgments 367 The authors would like to thank Dino Farinacci, Michael Menth, Padma 368 Pillay-Esnault, Alex Clemm, Uma Chunduri for their review and input 369 on this document. 371 This document was produced using Marshall Rose's xml2rfc tool. 373 11. References 375 11.1. Normative References 377 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 378 Requirement Levels", BCP 14, RFC 2119, 379 DOI 10.17487/RFC2119, March 1997, 380 . 382 [RFC6115] Li, T., Ed., "Recommendation for a Routing Architecture", 383 RFC 6115, DOI 10.17487/RFC6115, February 2011, 384 . 386 [RFC6537] Ahrenholz, J., "Host Identity Protocol Distributed Hash 387 Table Interface", RFC 6537, DOI 10.17487/RFC6537, February 388 2012, . 390 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 391 Locator/ID Separation Protocol (LISP)", RFC 6830, 392 DOI 10.17487/RFC6830, January 2013, 393 . 395 [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation 396 Protocol (LISP) Map-Server Interface", RFC 6833, 397 DOI 10.17487/RFC6833, January 2013, 398 . 400 [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, 401 "Locator/ID Separation Protocol Alternative Logical 402 Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836, 403 January 2013, . 405 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 406 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 407 RFC 7401, DOI 10.17487/RFC7401, April 2015, 408 . 410 [RFC7402] Jokela, P., Moskowitz, R., and J. Melen, "Using the 411 Encapsulating Security Payload (ESP) Transport Format with 412 the Host Identity Protocol (HIP)", RFC 7402, 413 DOI 10.17487/RFC7402, April 2015, 414 . 416 [RFC8003] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 417 Registration Extension", RFC 8003, DOI 10.17487/RFC8003, 418 October 2016, . 420 [RFC8004] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 421 Rendezvous Extension", RFC 8004, DOI 10.17487/RFC8004, 422 October 2016, . 424 [RFC8005] Laganier, J., "Host Identity Protocol (HIP) Domain Name 425 System (DNS) Extension", RFC 8005, DOI 10.17487/RFC8005, 426 October 2016, . 428 [RFC8046] Henderson, T., Ed., Vogt, C., and J. Arkko, "Host Mobility 429 with the Host Identity Protocol", RFC 8046, 430 DOI 10.17487/RFC8046, February 2017, 431 . 433 [RFC8047] Henderson, T., Ed., Vogt, C., and J. Arkko, "Host 434 Multihoming with the Host Identity Protocol", RFC 8047, 435 DOI 10.17487/RFC8047, February 2017, 436 . 438 [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 439 Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, 440 February 2017, . 442 [RFC8111] Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. 443 Smirnov, "Locator/ID Separation Protocol Delegated 444 Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111, 445 May 2017, . 447 11.2. Informative References 449 [DNS-DUP] Yahya, B. and J. Ben-Othman, "Achieving host mobility 450 using DNS dynamic updating protocol", October 2008, 451 . 453 [DNS1] Jung, J., Sit, E., Balakrishnan, H., and R. Morris, "DNS 454 Performance and the Effectiveness of Caching", 2002, 455 . 457 [DNS2] Liston, R., Srinivasan, S., and E. Zegura, "DNS 458 Performance and the Effectiveness of Caching", 2002, 459 . 462 [DNS3] Briscoe, B., Anna Brunstrom, A., Andreas Petlund, A., 463 David Hayes, D., David Ros, D., Ing-Jyh Tsang, I., Stein 464 Gjessing, S., Gorry Fairhurst, G., Carsten Griwodz, C., 465 and M. Michael Welzl, "Reducing Internet Latency: A Survey 466 of Techniques and their Merits", November 2014, 467 . 469 [GNRS] Karimi, P. and S. Mukherjee, "Global Name Resolution 470 Service", March 2017, . 473 [HHIT] Moskowitz, R., Xu, X., and B. Liu, "Hierarchical HITs for 474 HIPv2", June 2017, . 477 [HIP-IP] Moskowitz, R., Xu, X., and B. Liu, "Encapsulation of IP 478 within IP managed by HIP", June 2017, 479 . 482 [HIP-VPLS] 483 "HIP-based Virtual Private LAN Service (HIPLS)", February 484 2017, . 487 [IDEAS-IDY-USE] 488 "Identity Use Cases in IDEAS", June 2017, 489 . 492 [IDEAS-PS] 493 "Problem Statement for Identity Enabled Networks", March 494 2017, . 497 [ILA] Herbert, T., "Identifier-Locator Addressing for Network 498 Virtualization", March 2016, 499 . 502 [ILA-MS-TBD] 503 Herbert, T., "Re: [Ideas] A comment on the use case 504 draft", March 2017, . 507 [IVIP] Whittle, R., "Ivip (Internet Vastly Improved Plumbing) 508 Architecture", September 2010, 509 . 511 [LISP-ANNOY] 512 "LISP EID Anonymity", April 2017, 513 . 516 [LISP-DIS] 517 "LISP Discussion", . 520 [LISP-SEC] 521 Maino, F., Ermagan, V., Cabellos, A., Saucez, D., and O. 522 Bonaventure, "LISP-Security (LISP-SEC)", Work in Progress, 523 October 2012. 525 Authors' Addresses 526 Yingzhen Qu (editor) 527 Huawei 528 2330 Central Expressway 529 Santa Clara, CA 95050 530 USA 532 Email: yingzhen.qu@huawei.com 534 Albert Cabellos 535 Technical University of Catalonia 536 C/ Jordi Girona s/n 537 Barcelona 08034 538 Spain 540 Email: acabello@ac.upc.edu 542 Robert Moskowitz 543 HTT Consulting 544 Oak Park, MI 48237 545 USA 547 Email: rgm@labs.htt-consult.com 549 Bingyang Liu 550 Huawei 551 156 Beiqing Rd 552 Beijing 100095 553 China 555 Email: liubingyang@huawei.com 557 Andreas Stockmayer 558 University of Tuebingen 559 room B305, Institute of Computer Science 560 Tuebingen 72076 561 Germany 563 Email: andreas.stockmayer@uni-tuebingen.de