idnits 2.17.1 draft-ietf-lisp-eid-anonymity-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 : ---------------------------------------------------------------------------- == 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 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 (August 17, 2017) is 2444 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'I-D.meyer-lisp-mn' is defined on line 337, but no explicit reference was found in the text ** Obsolete normative reference: RFC 6830 (Obsoleted by RFC 9300, RFC 9301) == Outdated reference: A later version (-10) exists of draft-ietf-lisp-crypto-03 == Outdated reference: A later version (-09) exists of draft-ietf-lisp-signal-free-multicast-00 Summary: 1 error (**), 0 flaws (~~), 7 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: February 18, 2018 Huawei Technologies 6 W. Haddad 7 Ericsson 8 August 17, 2017 10 LISP EID Anonymity 11 draft-ietf-lisp-eid-anonymity-00 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 http://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 February 18, 2018. 43 Copyright Notice 45 Copyright (c) 2017 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 (http://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 . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3 62 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 4. Design Details . . . . . . . . . . . . . . . . . . . . . . . 4 64 5. Other Types of Ephemeral-EIDs . . . . . . . . . . . . . . . . 4 65 6. Interworking Considerations . . . . . . . . . . . . . . . . . 5 66 7. Multicast Considerations . . . . . . . . . . . . . . . . . . 5 67 8. Performance Improvements . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . 7 73 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 8 74 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 8 75 B.1. Changes to draft-ietf-lisp-eid-anonymity-00 . . . . . . . 8 76 B.2. Changes to draft-farinacci-lisp-eid-anonymity-02 . . . . 8 77 B.3. Changes to draft-farinacci-lisp-eid-anonymity-01 . . . . 8 78 B.4. Changes to draft-farinacci-lisp-eid-anonymity-00 . . . . 9 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 81 1. Introduction 83 The LISP architecture [RFC6830] specifies two namespaces, End-Point 84 IDs (EIDs) and Routing Locators (RLOCs). An EID identifies a node in 85 the network and the RLOC indicates the EID's topological location. 86 Typically EIDs are globally unique so a end-node system can connect 87 to any other end-node system on the Internet. Privately used EIDs 88 are allowed when scoped within a VPN but must always be unique within 89 that scope. Therefore, address allocation is required by network 90 administration to avoid address collisions or duplicate address use. 91 In a multiple namespace architecture like LISP, typically the EID 92 will stay fixed while the RLOC can change. This occurs when the EID 93 is mobile or when the LISP site the EID resides in changes its 94 connection to the Internet. 96 LISP creates the opportunity where EIDs are fixed and won't change. 97 This can create a privacy problem more so than what we have on the 98 Internet today. This draft will examine a technique to allow a end- 99 node system to use a temporary address. The lifetime of a temporary 100 address can be the same as a lifetime of an address in use today on 101 the Internet or can have traditionally shorter lifetimes, possibly on 102 the order of a day or even change as frequent as new connection 103 attempts. 105 2. Definition of Terms 107 Ephemeral-EID - is an IP address that is created randomly for use 108 for a temporary period of time. An Ephemeral-EID has all the 109 properties of an EID as defined in [RFC6830]. Ephemeral-EIDs are 110 not stored in the Domain Name System (DNS) and should not be used 111 in long-term address referrals. 113 Client End-Node - is a network node that originates and consumes 114 packets. It is a system that originates packets or initiates the 115 establishment of transport-layer connections. It does not offer 116 services as a server system would. It accesses servers and 117 attempts to do it anonymously. 119 3. Overview 121 A client end-node can assign its own ephemeral EID and use it to talk 122 to any system on the Internet. The system is acting as a client 123 where it initiates communication and desires to be an inaccessible 124 resource from any other system. The ephemeral EID is used as a 125 destination address solely to return packets to resources the 126 ephemeral EID connects to. 128 Here is the procedure a client end-node would use: 130 1. Client end-node desires to talk on the network. It creates and 131 assigns an ephemeral-EID on any interface. 133 2. If the client end-node is a LISP xTR, it will register the 134 ephemeral-EID with a globally routable RLOC. If the client end- 135 node is not a LISP xTR, it can send packets on the network where 136 a LISP router xTR will register the ephemeral-EID with its RLOC. 138 3. The client end-node originates packets with a source address 139 equal to the ephemeral-EID and will receive packets addressed to 140 the ephemeral-EID. 142 4. When the client end-node decides to stop using the ephemeral-EID, 143 it will deregister it from the mapping system and create and 144 assign a new ephemeral-EID, or decide to configure a static 145 global address, or participate in DHCP to get assigned a leased 146 address. 148 Note that the ephemeral-EID can be mobile just like any other EID so 149 if it is initially registered to the mapping system with one or more 150 RLOCs, later the RLOC-set can change as the ephemeral-EID roams. 152 4. Design Details 154 This specification proposes the use of the experimental LISP EID- 155 block 2001:5::/32 when IPv6 is used. See IANA Considerations section 156 for a specific sub-block allocation request. When IPv4 is used, the 157 Class E block 240.0.0.0/4 is being proposed. 159 The client end-node system will use the rest of the host bits to 160 allocate a random number to be used as the ephemeral-EID. The EID 161 can be created manually or via a programatic interface. When the EID 162 address is going to change frequently, it is suggested to use a 163 programatic interface. The probability of address collision is 164 unlikely for IPv6 EIDs but could occur for IPv4 EIDs. A client end- 165 node can create a ephemeral-EID and then look it up in the mapping 166 system to see if it exists. If the EID exists in the mapping system, 167 the client end-node can attempt creation of a new random number for 168 the ephemeral-EID. See Section 8 where ephemeral-EIDs can be 169 preallocated and registered to the mapping system before use. 171 When the client end-node system is co-located with the RLOC and acts 172 as an xTR, it should register the binding before sending packets. 173 This eliminates a race condition for returning packets not knowing 174 where to encapsulate packets to the ephemeral-EID's RLOCs. See 175 Section 8 for alternatives for fixing this race condition problem. 176 When the client end-node system is not acting as an xTR, it should 177 send some packets so its ephemeral-EID can be discovered by an xTR 178 which supports EID-mobility [I-D.portoles-lisp-eid-mobility] so 179 mapping system registration can occur before the destination returns 180 packets. When the end-node system is acting as an xTR, the EID and 181 RLOC-set is co-located in the same node. So when the EID is created, 182 the xTR can register the mapping versus waiting for packet 183 transmission. 185 5. Other Types of Ephemeral-EIDs 187 When IPv6 Ephemeral-EIDs are used, an alternative to a random number 188 can be used. For example, the low-order bits of the IPv6 address 189 could be a cryptographic hash of a public-key. Mechanisms from 190 [RFC3972] could be used for EIDs. Using this approach allows the 191 sender with a hashed EID to be authenticated. So packet signatures 192 can be verified by the corresponding public-key. When hashed EIDs 193 are used, the EID can change frequently as rekeying may be required 194 for enhanced security. 196 6. Interworking Considerations 198 If a client end-node is communicating with a system that is not in a 199 LISP site, the procedures from [RFC6832] should be followed. The 200 PITR will be required to originate route advertisements for the 201 ephemeral-EID sub-block [I-D.draft-ietf-lisp-eid-block] so it can 202 attract packets sourced by non-LISP sites destined to ephemeral-EIDs. 203 However, in the general case, the coarse block from 204 [I-D.draft-ietf-lisp-eid-block] will be advertised which would cover 205 the sub-block. For IPv4, the 240.0.0.0/4 must be advertised into the 206 IPv4 routing system. 208 7. Multicast Considerations 210 A client end-node system can be a member of a multicast group fairly 211 easily since its address is not used for multicast communication as a 212 receiver. This is due to the design characteristics of IGMP 213 [RFC3376] [RFC2236] [RFC1112] and MLD [RFC2710] [RFC3810]. 215 When a client end-node system is a multicast source, there is 216 ephemeral (S,G) state that is created and maintained in the network 217 via multicast routing protocols such as PIM [RFC4602] and when PIM is 218 used with LISP [RFC6802]. In addition, when 219 [I-D.draft-ietf-lisp-signal-free-multicast] is used, ephemeral-EID 220 state is created in the mapping database. This doesn't present any 221 problems other than the amount of state that may exist in the network 222 if not timed out and removed promptly. 224 However, there exists a multicast source discovery problem when PIM- 225 SSM [RFC4607] is used. Members that join (S,G) channels via out of 226 band mechanisms. These mechanisms need to support ephemeral-EIDs. 227 Otherwise, PIM-ASM [RFC4602] or PIM-Bidir [RFC5015] will need to be 228 used. 230 8. Performance Improvements 232 An optimization to reduce the race condition between registering 233 ephemeral-EIDs and returning packets as well as reducing the 234 probability of ephemeral-EID address collision is to preload the 235 mapping database with a list of ephemeral-EIDs before using them. It 236 comes at a expense of rebinding all of registered ephemeral-EIDs when 237 there is an RLOC change. There is work in progress to consider 238 adding a level of indirection here so a single entry gets the RLOC 239 update and the list of ephemeral-EIDs point to the single entry. 241 9. Security Considerations 243 When LISP-crypto [I-D.draft-ietf-lisp-crypto] is used the EID payload 244 is more secure through encryption providing EID obfuscation of the 245 ephemeral-EID as well as the global-EID it is communicating with. 246 But the obfuscation only occurs between xTRs. So the randomness of a 247 ephemeral-EID inside of LISP sites provide a new level of privacy. 249 10. IANA Considerations 251 This specification is requesting the sub-block 2001:5:ffff::/48 for 252 ephemeral-EID usage. 254 11. References 256 11.1. Normative References 258 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 259 RFC 1112, DOI 10.17487/RFC1112, August 1989, 260 . 262 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 263 Requirement Levels", BCP 14, RFC 2119, 264 DOI 10.17487/RFC2119, March 1997, . 267 [RFC2236] Fenner, W., "Internet Group Management Protocol, Version 268 2", RFC 2236, DOI 10.17487/RFC2236, November 1997, 269 . 271 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 272 Listener Discovery (MLD) for IPv6", RFC 2710, 273 DOI 10.17487/RFC2710, October 1999, . 276 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 277 Thyagarajan, "Internet Group Management Protocol, Version 278 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, 279 . 281 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 282 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 283 DOI 10.17487/RFC3810, June 2004, . 286 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 287 RFC 3972, DOI 10.17487/RFC3972, March 2005, 288 . 290 [RFC4602] Pusateri, T., "Protocol Independent Multicast - Sparse 291 Mode (PIM-SM) IETF Proposed Standard Requirements 292 Analysis", RFC 4602, DOI 10.17487/RFC4602, August 2006, 293 . 295 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 296 IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, 297 . 299 [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, 300 "Bidirectional Protocol Independent Multicast (BIDIR- 301 PIM)", RFC 5015, DOI 10.17487/RFC5015, October 2007, 302 . 304 [RFC6802] Baillargeon, S., Flinta, C., and A. Johnsson, "Ericsson 305 Two-Way Active Measurement Protocol (TWAMP) Value-Added 306 Octets", RFC 6802, DOI 10.17487/RFC6802, November 2012, 307 . 309 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 310 Locator/ID Separation Protocol (LISP)", RFC 6830, 311 DOI 10.17487/RFC6830, January 2013, . 314 [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, 315 "Interworking between Locator/ID Separation Protocol 316 (LISP) and Non-LISP Sites", RFC 6832, 317 DOI 10.17487/RFC6832, January 2013, . 320 11.2. Informative References 322 [I-D.draft-ietf-lisp-crypto] 323 Farinacci, D. and B. Weis, "LISP Data-Plane 324 Confidentiality", draft-ietf-lisp-crypto-03 (work in 325 progress). 327 [I-D.draft-ietf-lisp-eid-block] 328 Iannone, L., Lewis, D., Meyer, D., and V. Fuller, "LISP 329 EID Block", draft-ietf-lisp-eid-block-13.txt (work in 330 progress). 332 [I-D.draft-ietf-lisp-signal-free-multicast] 333 Farinacci, D. and V. Moreno, "Signal-Free LISP Multicast", 334 draft-ietf-lisp-signal-free-multicast-00.txt (work in 335 progress). 337 [I-D.meyer-lisp-mn] 338 Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP 339 Mobile Node", draft-meyer-lisp-mn-16 (work in progress), 340 December 2016. 342 [I-D.portoles-lisp-eid-mobility] 343 Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino, 344 F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a 345 Unified Control Plane", draft-portoles-lisp-eid- 346 mobility-02 (work in progress), April 2017. 348 Appendix A. Acknowledgments 350 The author would like to thank the LISP WG for their review and 351 acceptance of this draft. 353 Appendix B. Document Change Log 355 [RFC Editor: Please delete this section on publication as RFC.] 357 B.1. Changes to draft-ietf-lisp-eid-anonymity-00 359 o Posted August 2017. 361 o Made draft-farinacci-lisp-eid-anonymity-02 a LISP working group 362 document. 364 B.2. Changes to draft-farinacci-lisp-eid-anonymity-02 366 o Posted April 2017. 368 o Added section describing how ephemeral-EIDs can use a public key 369 hash as an alternative to a random number. 371 o Indciate when an EID/RLOC co-located, that the xTR can register 372 the EID when it is configured or changed versus waiting for a 373 packet to be sent as in the EID/RLOC separated case. 375 B.3. Changes to draft-farinacci-lisp-eid-anonymity-01 377 o Posted October 2016. 379 o Update document timer. 381 B.4. Changes to draft-farinacci-lisp-eid-anonymity-00 383 o Posted April 2016. 385 o Initial posting. 387 Authors' Addresses 389 Dino Farinacci 390 lispers.net 391 San Jose, CA 392 USA 394 Email: farinacci@gmail.com 396 Padma Pillay-Esnault 397 Huawei Technologies 398 San Clara, CA 399 USA 401 Email: padma@huawei.com 403 Wassim Haddad 404 Ericsson 405 San Clara, CA 406 USA 408 Email: wassim.haddad@ericsson.com