idnits 2.17.1 draft-farinacci-lisp-eid-anonymity-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 : ---------------------------------------------------------------------------- == 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 (October 31, 2016) is 2727 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** 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 == Outdated reference: A later version (-02) exists of draft-portoles-lisp-eid-mobility-01 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: May 4, 2017 Huawei Technologies 6 October 31, 2016 8 LISP EID Anonymity 9 draft-farinacci-lisp-eid-anonymity-01 11 Abstract 13 This specification will describe how ephemeral LISP EIDs can be used 14 to create source anonymity. The idea makes use of frequently 15 changing EIDs much like how a credit-card system uses a different 16 credit-card numbers for each transaction. 18 Requirements Language 20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 21 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 22 document are to be interpreted as described in [RFC2119]. 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 May 4, 2017. 41 Copyright Notice 43 Copyright (c) 2016 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. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3 60 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 4. Design Details . . . . . . . . . . . . . . . . . . . . . . . 4 62 5. Interworking Considerations . . . . . . . . . . . . . . . . . 4 63 6. Multicast Considerations . . . . . . . . . . . . . . . . . . 5 64 7. Performance Improvements . . . . . . . . . . . . . . . . . . 5 65 8. Security Considerations . . . . . . . . . . . . . . . . . . . 5 66 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 67 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 10.1. Normative References . . . . . . . . . . . . . . . . . . 6 69 10.2. Informative References . . . . . . . . . . . . . . . . . 7 70 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 7 71 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 8 72 B.1. Changes to draft-farinacci-lisp-eid-anonymity-01 . . . . 8 73 B.2. Changes to draft-farinacci-lisp-eid-anonymity-00 . . . . 8 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 76 1. Introduction 78 The LISP architecture [RFC6830] specifies two namespaces, End-Point 79 IDs (EIDs) and Routing Locators (RLOCs). An EID identifies a node in 80 the network and the RLOC indicates the EID's topological location. 81 Typically EIDs are globally unique so a end-node system can connect 82 to any other end-node system on the Internet. Privately used EIDs 83 are allowed when scoped within a VPN but must always be unique within 84 that scope. Therefore, address allocation is required by network 85 administration to avoid address collisions or duplicate address use. 86 In a multiple namespace architecture like LISP, typically the EID 87 will stay fixed while the RLOC can change. This occurs when the EID 88 is mobile or when the LISP site the EID resides in changes its 89 connection to the Internet. 91 LISP creates the opportunity where EIDs are fixed and won't change. 92 This can create a privacy problem more so than what we have on the 93 Internet today. This draft will examine a technique to allow a end- 94 node system to use a temporary address. The lifetime of a temporary 95 address can be the same as a lifetime of an address in use today on 96 the Internet or can have traditionally shorter lifetimes, possibly on 97 the order of a day or even change as frequent as new connection 98 attempts. 100 2. Definition of Terms 102 Ephemeral-EID - is an IP address that is created randomly for use 103 for a temporary period of time. An Ephemeral-EID has all the 104 properties of an EID as defined in [RFC6830]. Ephemeral-EIDs are 105 not stored in the Domain Name System (DNS) and should not be used 106 in long-term address referrals. 108 Client End-Node - is a network node that originates and consumes 109 packets. It is a system that originates packets or initiates the 110 establishment of transport-layer connections. It does not offer 111 services as a server system would. It accesses servers and 112 attempts to do it anonymously. 114 3. Overview 116 A client end-node can assign its own ephemeral EID and use it to talk 117 to any system on the Internet. The system is acting as a client 118 where it initiates communication and desires to be an inaccessible 119 resource from any other system. The ephemeral EID is used as a 120 destination address solely to return packets to resources the 121 ephemeral EID connects to. 123 Here is the procedure a client end-node would use: 125 1. Client end-node desires to talk on the network. It creates and 126 assigns an ephemeral-EID on any interface. 128 2. If the client end-node is a LISP xTR, it will register the 129 ephemeral-EID with a globally routable RLOC. If the client end- 130 node is not a LISP xTR, it can send packets on the network where 131 a LISP router xTR will register the ephemeral-EID with its RLOC. 133 3. The client end-node originates packets with a source address 134 equal to the ephemeral-EID and will receive packets addressed to 135 the ephemeral-EID. 137 4. When the client end-node decides to stop using the ephemeral-EID, 138 it will deregister it from the mapping system and create and 139 assign a new ephemeral-EID, or decide to configure a static 140 global address, or participate in DHCP to get assigned a leased 141 address. 143 Note that the ephemeral-EID can be mobile just like any other EID so 144 if it is initially registered to the mapping system with one or more 145 RLOCs, later the RLOC-set can change as the ephemeral-EID roams. 147 4. Design Details 149 This specification proposes the use of the experimental LISP EID- 150 block 2001:5::/32 when IPv6 is used. See IANA Considerations section 151 for a specific sub-block allocation request. When IPv4 is used, the 152 Class E block 240.0.0.0/4 is being proposed. 154 The client end-node system will use the rest of the host bits to 155 allocate a random number to be used as the ephemeral-EID. The EID 156 can be created manually or via a programatic interface. When the EID 157 address is going to change frequently, it is suggested to use a 158 programatic interface. The probability of address collision is 159 unlikely for IPv6 EIDs but could occur for IPv4 EIDs. A client end- 160 node can create a ephemeral-EID and then look it up in the mapping 161 system to see if it exists. If the EID exists in the mapping system, 162 the client end-node can attempt creation of a new random number for 163 the ephemeral-EID. See Section 7 where ephemeral-EIDs can be 164 preallocated and registered to the mapping system before use. 166 When the client end-node system is co-located with the RLOC and acts 167 as an xTR, it should register the binding before sending packets. 168 This eliminates a race condition for returning packets not knowing 169 where to encapsulate packets to the ephemeral-EID's RLOCs. When the 170 client end-node system is not acting as an xTR, it should send some 171 packets so its ephemeral-EID can be discovered by an xTR which 172 supports EID-mobility [I-D.portoles-lisp-eid-mobility] so mapping 173 system registration can occur before the destination returns packets. 174 See Section 7 for alternatives for fixing this race condition 175 problem. 177 5. Interworking Considerations 179 If a client end-node is communicating with a system that is not in a 180 LISP site, the procedures from [RFC6832] should be followed. The 181 PITR will be required to originate route advertisements for the 182 ephemeral-EID sub-block [I-D.draft-ietf-lisp-eid-block] so it can 183 attract packets sourced by non-LISP sites destined to ephemeral-EIDs. 184 However, in the general case, the coarse block from 185 [I-D.draft-ietf-lisp-eid-block] will be advertised which would cover 186 the sub-block. For IPv4, the 240.0.0.0/4 must be advertised into the 187 IPv4 routing system. 189 6. Multicast Considerations 191 A client end-node system can be a member of a multicast group fairly 192 easily since its address is not used for multicast communication as a 193 receiver. This is due to the design characteristics of IGMP 194 [RFC3376] [RFC2236] [RFC1112] and MLD [RFC2710] [RFC3810]. 196 When a client end-node system is a multicast source, there is 197 ephemeral (S,G) state that is created and maintained in the network 198 via multicast routing protocols such as PIM [RFC4602] and when PIM is 199 used with LISP [RFC6802]. In addition, when 200 [I-D.draft-ietf-lisp-signal-free-multicast] is used, ephemeral-EID 201 state is created in the mapping database. This doesn't present any 202 problems other than the amount of state that may exist in the network 203 if not timed out and removed promptly. 205 However, there exists a multicast source discovery problem when PIM- 206 SSM [RFC4607] is used. Members that join (S,G) channels via out of 207 band mechanisms. These mechanisms need to support ephemeral-EIDs. 208 Otherwise, PIM-ASM [RFC4602] or PIM-Bidir [RFC5015] will need to be 209 used. 211 7. Performance Improvements 213 An optimization to reduce the race condition between registering 214 ephemeral-EIDs and returning packets as well as reducing the 215 probability of ephemeral-EID address collision is to preload the 216 mapping database with a list of ephemeral-EIDs before using them. It 217 comes at a expense of rebinding all of registered ephemeral-EIDs when 218 there is an RLOC change. There is work in progress to consider 219 adding a level of indirection here so a single entry gets the RLOC 220 update and the list of ephemeral-EIDs point to the single entry. 222 8. Security Considerations 224 When LISP-crypto [I-D.draft-ietf-lisp-crypto] is used the EID payload 225 is more secure through encryption providing EID obfuscation of the 226 ephemeral-EID as well as the global-EID it is communicating with. 227 But the obfuscation only occurs between xTRs. So the randomness of a 228 ephemeral-EID inside of LISP sites provide a new level of privacy. 230 9. IANA Considerations 232 This specification is requesting the sub-block 2001:5:ffff::/48 for 233 ephemeral-EID usage. 235 10. References 237 10.1. Normative References 239 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 240 RFC 1112, DOI 10.17487/RFC1112, August 1989, 241 . 243 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 244 Requirement Levels", BCP 14, RFC 2119, 245 DOI 10.17487/RFC2119, March 1997, 246 . 248 [RFC2236] Fenner, W., "Internet Group Management Protocol, Version 249 2", RFC 2236, DOI 10.17487/RFC2236, November 1997, 250 . 252 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 253 Listener Discovery (MLD) for IPv6", RFC 2710, 254 DOI 10.17487/RFC2710, October 1999, 255 . 257 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 258 Thyagarajan, "Internet Group Management Protocol, Version 259 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, 260 . 262 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 263 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 264 DOI 10.17487/RFC3810, June 2004, 265 . 267 [RFC4602] Pusateri, T., "Protocol Independent Multicast - Sparse 268 Mode (PIM-SM) IETF Proposed Standard Requirements 269 Analysis", RFC 4602, DOI 10.17487/RFC4602, August 2006, 270 . 272 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 273 IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, 274 . 276 [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, 277 "Bidirectional Protocol Independent Multicast (BIDIR- 278 PIM)", RFC 5015, DOI 10.17487/RFC5015, October 2007, 279 . 281 [RFC6802] Baillargeon, S., Flinta, C., and A. Johnsson, "Ericsson 282 Two-Way Active Measurement Protocol (TWAMP) Value-Added 283 Octets", RFC 6802, DOI 10.17487/RFC6802, November 2012, 284 . 286 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 287 Locator/ID Separation Protocol (LISP)", RFC 6830, 288 DOI 10.17487/RFC6830, January 2013, 289 . 291 [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, 292 "Interworking between Locator/ID Separation Protocol 293 (LISP) and Non-LISP Sites", RFC 6832, 294 DOI 10.17487/RFC6832, January 2013, 295 . 297 10.2. Informative References 299 [I-D.draft-ietf-lisp-crypto] 300 Farinacci, D. and B. Weis, "LISP Data-Plane 301 Confidentiality", draft-ietf-lisp-crypto-03 (work in 302 progress). 304 [I-D.draft-ietf-lisp-eid-block] 305 Iannone, L., Lewis, D., Meyer, D., and V. Fuller, "LISP 306 EID Block", draft-ietf-lisp-eid-block-13.txt (work in 307 progress). 309 [I-D.draft-ietf-lisp-signal-free-multicast] 310 Farinacci, D. and V. Moreno, "Signal-Free LISP Multicast", 311 draft-ietf-lisp-signal-free-multicast-00.txt (work in 312 progress). 314 [I-D.portoles-lisp-eid-mobility] 315 Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino, 316 F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a 317 Unified Control Plane", draft-portoles-lisp-eid- 318 mobility-01 (work in progress), October 2016. 320 Appendix A. Acknowledgments 322 The author would like to thank the LISP WG for their review and 323 acceptance of this draft. 325 Appendix B. Document Change Log 327 [RFC Editor: Please delete this section on publication as RFC.] 329 B.1. Changes to draft-farinacci-lisp-eid-anonymity-01 331 o Posted October 2016. 333 o Update document timer. 335 B.2. Changes to draft-farinacci-lisp-eid-anonymity-00 337 o Posted April 2016. 339 o Initial posting. 341 Authors' Addresses 343 Dino Farinacci 344 lispers.net 345 San Jose, CA 346 USA 348 Email: farinacci@gmail.com 350 Padma Pillay-Esnault 351 Huawei Technologies 352 San Clara, CA 353 USA 355 Email: padma@huawei.com