idnits 2.17.00 (12 Aug 2021) /tmp/idnits53702/draft-ietf-lisp-eid-anonymity-12.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 : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 2 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 20, 2022) is 55 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: draft-ietf-lisp-signal-free-multicast has been published as RFC 8378 Summary: 0 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 D. Farinacci 3 Internet-Draft lispers.net 4 Intended status: Experimental P. Pillay-Esnault 5 Expires: September 21, 2022 Independent 6 W. Haddad 7 Ericsson 8 March 20, 2022 10 LISP EID Anonymity 11 draft-ietf-lisp-eid-anonymity-12 13 Abstract 15 This specification will describe how ephemeral LISP EIDs can be used 16 to create source anonymity. The idea makes use of frequently 17 changing EIDs much like how a credit-card system uses a different 18 credit-card numbers for each transaction. 20 Requirements Language 22 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 23 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 24 document are to be interpreted as described in [RFC2119]. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on September 21, 2022. 43 Copyright Notice 45 Copyright (c) 2022 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3 62 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 4. Design Details . . . . . . . . . . . . . . . . . . . . . . . 4 64 5. Other Types of Ephemeral-EIDs . . . . . . . . . . . . . . . . 5 65 6. Interworking Considerations . . . . . . . . . . . . . . . . . 5 66 7. Multicast Considerations . . . . . . . . . . . . . . . . . . 5 67 8. Performance Improvements . . . . . . . . . . . . . . . . . . 6 68 9. Security Considerations . . . . . . . . . . . . . . . . . . . 6 69 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 70 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 11.1. Normative References . . . . . . . . . . . . . . . . . . 6 72 11.2. Informative References . . . . . . . . . . . . . . . . . 8 73 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 8 74 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 8 75 B.1. Changes to draft-ietf-lisp-eid-anonymity-12 . . . . . . . 8 76 B.2. Changes to draft-ietf-lisp-eid-anonymity-11 . . . . . . . 9 77 B.3. Changes to draft-ietf-lisp-eid-anonymity-10 . . . . . . . 9 78 B.4. Changes to draft-ietf-lisp-eid-anonymity-09 . . . . . . . 9 79 B.5. Changes to draft-ietf-lisp-eid-anonymity-08 . . . . . . . 9 80 B.6. Changes to draft-ietf-lisp-eid-anonymity-07 . . . . . . . 9 81 B.7. Changes to draft-ietf-lisp-eid-anonymity-06 . . . . . . . 9 82 B.8. Changes to draft-ietf-lisp-eid-anonymity-05 . . . . . . . 9 83 B.9. Changes to draft-ietf-lisp-eid-anonymity-04 . . . . . . . 9 84 B.10. Changes to draft-ietf-lisp-eid-anonymity-03 . . . . . . . 10 85 B.11. Changes to draft-ietf-lisp-eid-anonymity-02 . . . . . . . 10 86 B.12. Changes to draft-ietf-lisp-eid-anonymity-01 . . . . . . . 10 87 B.13. Changes to draft-ietf-lisp-eid-anonymity-00 . . . . . . . 10 88 B.14. Changes to draft-farinacci-lisp-eid-anonymity-02 . . . . 10 89 B.15. Changes to draft-farinacci-lisp-eid-anonymity-01 . . . . 10 90 B.16. Changes to draft-farinacci-lisp-eid-anonymity-00 . . . . 11 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 93 1. Introduction 95 The LISP architecture [RFC6830] specifies two namespaces, End-Point 96 IDs (EIDs) and Routing Locators (RLOCs). An EID identifies a node in 97 the network and the RLOC indicates the EID's topological location. 98 Typically EIDs are globally unique so an end-node system can connect 99 to any other end-node system on the Internet. Privately used EIDs 100 are allowed when scoped within a VPN but must always be unique within 101 that scope. Therefore, address allocation is required by network 102 administration to avoid address collisions or duplicate address use. 103 In a multiple namespace architecture like LISP, typically the EID 104 will stay fixed while the RLOC can change. This occurs when the EID 105 is mobile or when the LISP site the EID resides in changes its 106 connection to the Internet. 108 LISP creates the opportunity where EIDs are fixed and won't change. 109 This draft will examine a technique to allow a end-node system to use 110 a temporary address. The lifetime of a temporary address can be the 111 same as a lifetime of an address in use today on the Internet or can 112 have traditionally shorter lifetimes, possibly on the order of a day 113 or even change as frequent as new connection attempts. 115 2. Definition of Terms 117 Ephemeral-EID - is an IP address that is created randomly for use 118 for a temporary period of time. An Ephemeral-EID has all the 119 properties of an EID as defined in [RFC6830]. Ephemeral-EIDs are 120 not stored in the Domain Name System (DNS) and should not be used 121 in long-term address referrals. 123 Client End-Node - is a network node that originates and consumes 124 packets. It is a system that originates packets or initiates the 125 establishment of transport-layer connections. It does not offer 126 services as a server system would. It accesses servers and 127 attempts to do it anonymously. 129 3. Overview 131 A client end-node can assign its own ephemeral EID and use it to talk 132 to any system on the Internet. The system is acting as a client 133 where it initiates communication and desires to be an inaccessible 134 resource from any other system. The ephemeral EID is used as a 135 destination address solely to return packets to resources the 136 ephemeral EID connects to. A client-node may simultaneously use a 137 traditional EID along with ephemeral EIDs in parallel and are not 138 mutually exclusive. A client may choose to use the ephemeral EIDs 139 with some peers only where it needs to preserve anonymity. 141 Here is the procedure a client end-node would use: 143 1. Client end-node desires to talk on the network. It creates and 144 assigns an ephemeral-EID on any interface. The client end-node 145 may also assign multiple ephemeral-EIDs on the same interface or 146 across different interfaces. 148 2. If the client end-node is a LISP xTR, it will register ephemeral- 149 EIDs mapped to underlay routable RLOCs. If the client end-node 150 is not a LISP xTR, it can send packets on the network where a 151 LISP router xTR will register the ephemeral-EIDs with its RLOC- 152 set. 154 3. The client end-node originates packets with a source address 155 equal to the ephemeral-EID and will receive packets addressed to 156 the ephemeral-EID. 158 4. When the client end-node decides to stop using an ephemeral-EID, 159 it will deregister it from the mapping system and create and 160 assign a new ephemeral-EID, or decide to configure a static 161 global address, or participate in DHCP to get assigned a leased 162 address. 164 Note that the ephemeral-EID can be mobile just like any other EID so 165 if it is initially registered to the mapping system with one or more 166 RLOCs, later the RLOC-set can change as the ephemeral-EID roams. 168 4. Design Details 170 This specification proposes the use of the experimental LISP EID- 171 block 2001:5::/32 [RFC7954] when IPv6 is used. See IANA 172 Considerations section for a specific sub-block allocation request. 173 When IPv4 is used, the Class E block 240.0.0.0/4 is being proposed. 175 The client end-node system will use the rest of the host bits to 176 allocate a random number to be used as the ephemeral-EID. The EID 177 can be created manually or via a programatic interface. When the EID 178 address is going to change frequently, it is suggested to use a 179 programatic interface. The probability of address collision is 180 unlikely for IPv6 EIDs but could occur for IPv4 EIDs. A client end- 181 node can create an ephemeral-EID and then look it up in the mapping 182 system to see if it exists. If the EID exists in the mapping system, 183 the client end-node can attempt creation of a new random number for 184 the ephemeral-EID. See Section 8 where ephemeral-EIDs can be 185 preallocated and registered to the mapping system before use. 187 When the client end-node system is co-located with the RLOC and acts 188 as an xTR, it should register the binding before sending packets. 190 This eliminates a race condition for returning packets not knowing 191 where to encapsulate packets to the ephemeral-EID's RLOCs. See 192 Section 8 for alternatives for fixing this race condition problem. 193 When the client end-node system is not acting as an xTR, it should 194 send some packets so its ephemeral-EID can be discovered by an xTR 195 which supports EID-mobility [I-D.ietf-lisp-eid-mobility] so mapping 196 system registration can occur before the destination returns packets. 197 When the end-node system is acting as an xTR, the EID and RLOC-set is 198 co-located in the same node. So when the EID is created, the xTR can 199 register the mapping versus waiting for packet transmission. 201 5. Other Types of Ephemeral-EIDs 203 When IPv6 Ephemeral-EIDs are used, an alternative to a random number 204 can be used. For example, the low-order bits of the IPv6 address 205 could be a cryptographic hash of a public-key. Mechanisms from 206 [RFC3972] could be used for EIDs. Using this approach allows the 207 sender with a hashed EID to be authenticated. So packet signatures 208 can be verified by the corresponding public-key. When hashed EIDs 209 are used, the EID can change frequently as rekeying may be required 210 for enhanced security. LISP specific control message signature 211 mechanims can be found in [I-D.farinacci-lisp-ecdsa-auth]. 213 6. Interworking Considerations 215 If a client end-node is communicating with a system that is not in a 216 LISP site, the procedures from [RFC6832] should be followed. The 217 PITR will be required to originate route advertisements for the 218 ephemeral-EID sub-block [RFC7954] so it can attract packets sourced 219 by non-LISP sites destined to ephemeral-EIDs. However, in the 220 general case, the coarse block from [RFC7954] will be advertised 221 which would cover the sub-block. For IPv4, the 240.0.0.0/4 must be 222 advertised into the IPv4 routing system. 224 7. Multicast Considerations 226 A client end-node system can be a member of a multicast group fairly 227 easily since its address is not used for multicast communication as a 228 receiver. This is due to the design characteristics of IGMP 229 [RFC3376] [RFC2236] [RFC1112] and MLD [RFC2710] [RFC3810]. 231 When a client end-node system is a multicast source, there is 232 ephemeral (S,G) state that is created and maintained in the network 233 via multicast routing protocols such as PIM [RFC4602] and when PIM is 234 used with LISP [RFC6802]. In addition, when 235 [I-D.ietf-lisp-signal-free-multicast] is used, ephemeral-EID state is 236 created in the mapping database. This doesn't present any problems 237 other than the amount of state that may exist in the network if not 238 timed out and removed promptly. 240 However, there exists a multicast source discovery problem when PIM- 241 SSM [RFC4607] is used. Members that join (S,G) channels via out of 242 band mechanisms. These mechanisms need to support ephemeral-EIDs. 243 Otherwise, PIM-ASM [RFC4602] or PIM-Bidir [RFC5015] will need to be 244 used. 246 8. Performance Improvements 248 An optimization to reduce the race condition between registering 249 ephemeral-EIDs and returning packets as well as reducing the 250 probability of ephemeral-EID address collision is to preload the 251 mapping database with a list of ephemeral-EIDs before using them. It 252 comes at the expense of rebinding all of registered ephemeral-EIDs 253 when there is an RLOC change. There is work in progress to consider 254 adding a level of indirection here so a single entry gets the RLOC 255 update and the list of ephemeral-EIDs point to the single entry. 257 9. Security Considerations 259 When LISP-crypto [RFC8061] is used the EID payload is more secure 260 through encryption providing EID obfuscation of the ephemeral-EID as 261 well as the global-EID it is communicating with. But the obfuscation 262 only occurs between xTRs. So the randomness of a ephemeral-EID 263 inside of LISP sites provide a new level of privacy. 265 10. IANA Considerations 267 This specification is requesting the sub-block 2001:5:ffff::/48 for 268 ephemeral-EID usage. 270 11. References 272 11.1. Normative References 274 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 275 RFC 1112, DOI 10.17487/RFC1112, August 1989, 276 . 278 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 279 Requirement Levels", BCP 14, RFC 2119, 280 DOI 10.17487/RFC2119, March 1997, 281 . 283 [RFC2236] Fenner, W., "Internet Group Management Protocol, Version 284 2", RFC 2236, DOI 10.17487/RFC2236, November 1997, 285 . 287 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 288 Listener Discovery (MLD) for IPv6", RFC 2710, 289 DOI 10.17487/RFC2710, October 1999, 290 . 292 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 293 Thyagarajan, "Internet Group Management Protocol, Version 294 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, 295 . 297 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 298 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 299 DOI 10.17487/RFC3810, June 2004, 300 . 302 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 303 RFC 3972, DOI 10.17487/RFC3972, March 2005, 304 . 306 [RFC4602] Pusateri, T., "Protocol Independent Multicast - Sparse 307 Mode (PIM-SM) IETF Proposed Standard Requirements 308 Analysis", RFC 4602, DOI 10.17487/RFC4602, August 2006, 309 . 311 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 312 IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, 313 . 315 [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, 316 "Bidirectional Protocol Independent Multicast (BIDIR- 317 PIM)", RFC 5015, DOI 10.17487/RFC5015, October 2007, 318 . 320 [RFC6802] Baillargeon, S., Flinta, C., and A. Johnsson, "Ericsson 321 Two-Way Active Measurement Protocol (TWAMP) Value-Added 322 Octets", RFC 6802, DOI 10.17487/RFC6802, November 2012, 323 . 325 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 326 Locator/ID Separation Protocol (LISP)", RFC 6830, 327 DOI 10.17487/RFC6830, January 2013, 328 . 330 [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, 331 "Interworking between Locator/ID Separation Protocol 332 (LISP) and Non-LISP Sites", RFC 6832, 333 DOI 10.17487/RFC6832, January 2013, 334 . 336 [RFC7954] Iannone, L., Lewis, D., Meyer, D., and V. Fuller, 337 "Locator/ID Separation Protocol (LISP) Endpoint Identifier 338 (EID) Block", RFC 7954, DOI 10.17487/RFC7954, September 339 2016, . 341 [RFC8061] Farinacci, D. and B. Weis, "Locator/ID Separation Protocol 342 (LISP) Data-Plane Confidentiality", RFC 8061, 343 DOI 10.17487/RFC8061, February 2017, 344 . 346 11.2. Informative References 348 [I-D.farinacci-lisp-ecdsa-auth] 349 Farinacci, D. and E. Nordmark, "LISP Control-Plane ECDSA 350 Authentication and Authorization", draft-farinacci-lisp- 351 ecdsa-auth-03 (work in progress), September 2018. 353 [I-D.ietf-lisp-eid-mobility] 354 Comeras, M. P., Ashtaputre, V., Maino, F., Moreno, V., and 355 D. Farinacci, "LISP L2/L3 EID Mobility Using a Unified 356 Control Plane", draft-ietf-lisp-eid-mobility-09 (work in 357 progress), January 2022. 359 [I-D.ietf-lisp-signal-free-multicast] 360 Moreno, V. and D. Farinacci, "Signal-Free Locator/ID 361 Separation Protocol (LISP) Multicast", draft-ietf-lisp- 362 signal-free-multicast-09 (work in progress), March 2018. 364 Appendix A. Acknowledgments 366 The author would like to thank the LISP WG for their review and 367 acceptance of this draft. 369 Appendix B. Document Change Log 371 [RFC Editor: Please delete this section on publication as RFC.] 373 B.1. Changes to draft-ietf-lisp-eid-anonymity-12 375 o Posted March 2022. 377 o Update document timer and references. 379 B.2. Changes to draft-ietf-lisp-eid-anonymity-11 381 o Posted end of September 2021. 383 o Update document timer and references. 385 B.3. Changes to draft-ietf-lisp-eid-anonymity-10 387 o Posted end of March 2021. 389 o Update document timer and references. 391 B.4. Changes to draft-ietf-lisp-eid-anonymity-09 393 o Posted end of October 2020. 395 o Update document timer and references. 397 B.5. Changes to draft-ietf-lisp-eid-anonymity-08 399 o Posted end of April 2020. 401 o Update document timer and references. 403 B.6. Changes to draft-ietf-lisp-eid-anonymity-07 405 o Posted end of October 2019. 407 o Update document timer and references. 409 B.7. Changes to draft-ietf-lisp-eid-anonymity-06 411 o Posted end of March 2019. 413 o Padma had more basic edits and some clarification text. 415 B.8. Changes to draft-ietf-lisp-eid-anonymity-05 417 o Posted March IETF week 2019. 419 o Do not state that ephemeral EIDs make the privacy problem worse. 421 B.9. Changes to draft-ietf-lisp-eid-anonymity-04 423 o Posted October 2018 before Bangkok IETF deadline. 425 o Made Padma requested changes to refer to ephemeral-EIDs allowed to 426 have many on one interface and can be registered with more than 1 427 RLOC but one RLOC-set. 429 B.10. Changes to draft-ietf-lisp-eid-anonymity-03 431 o Posted October 2018. 433 o Update document timer and references. 435 B.11. Changes to draft-ietf-lisp-eid-anonymity-02 437 o Posted April 2018. 439 o Update document timer and references. 441 B.12. Changes to draft-ietf-lisp-eid-anonymity-01 443 o Posted October 2017. 445 o Add to section 5 that PKI can be used to authenticate EIDs. 447 o Update references. 449 B.13. Changes to draft-ietf-lisp-eid-anonymity-00 451 o Posted August 2017. 453 o Made draft-farinacci-lisp-eid-anonymity-02 a LISP working group 454 document. 456 B.14. Changes to draft-farinacci-lisp-eid-anonymity-02 458 o Posted April 2017. 460 o Added section describing how ephemeral-EIDs can use a public key 461 hash as an alternative to a random number. 463 o Indciate when an EID/RLOC co-located, that the xTR can register 464 the EID when it is configured or changed versus waiting for a 465 packet to be sent as in the EID/RLOC separated case. 467 B.15. Changes to draft-farinacci-lisp-eid-anonymity-01 469 o Posted October 2016. 471 o Update document timer. 473 B.16. Changes to draft-farinacci-lisp-eid-anonymity-00 475 o Posted April 2016. 477 o Initial posting. 479 Authors' Addresses 481 Dino Farinacci 482 lispers.net 483 San Jose, CA 484 USA 486 Email: farinacci@gmail.com 488 Padma Pillay-Esnault 489 Independent 490 Santa Clara, CA 491 USA 493 Email: padma.ietf@gmail.com 495 Wassim Haddad 496 Ericsson 497 Santa Clara, CA 498 USA 500 Email: wassim.haddad@ericsson.com