--- 1/draft-ietf-lisp-eid-anonymity-05.txt 2019-04-11 09:13:42.367486011 -0700 +++ 2/draft-ietf-lisp-eid-anonymity-06.txt 2019-04-11 09:13:42.391486636 -0700 @@ -1,21 +1,21 @@ Network Working Group D. Farinacci Internet-Draft lispers.net Intended status: Experimental P. Pillay-Esnault -Expires: September 29, 2019 Huawei Technologies +Expires: October 13, 2019 Huawei Technologies W. Haddad Ericsson - March 28, 2019 + April 11, 2019 LISP EID Anonymity - draft-ietf-lisp-eid-anonymity-05 + draft-ietf-lisp-eid-anonymity-06 Abstract This specification will describe how ephemeral LISP EIDs can be used to create source anonymity. The idea makes use of frequently changing EIDs much like how a credit-card system uses a different credit-card numbers for each transaction. Requirements Language @@ -31,21 +31,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on September 29, 2019. + This Internet-Draft will expire on October 13, 2019. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -65,42 +65,42 @@ 6. Interworking Considerations . . . . . . . . . . . . . . . . . 5 7. Multicast Considerations . . . . . . . . . . . . . . . . . . 5 8. Performance Improvements . . . . . . . . . . . . . . . . . . 6 9. Security Considerations . . . . . . . . . . . . . . . . . . . 6 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 11.1. Normative References . . . . . . . . . . . . . . . . . . 6 11.2. Informative References . . . . . . . . . . . . . . . . . 8 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 8 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 8 - B.1. Changes to draft-ietf-lisp-eid-anonymity-05 . . . . . . . 8 - B.2. Changes to draft-ietf-lisp-eid-anonymity-04 . . . . . . . 8 - B.3. Changes to draft-ietf-lisp-eid-anonymity-03 . . . . . . . 9 - B.4. Changes to draft-ietf-lisp-eid-anonymity-02 . . . . . . . 9 - B.5. Changes to draft-ietf-lisp-eid-anonymity-01 . . . . . . . 9 - B.6. Changes to draft-ietf-lisp-eid-anonymity-00 . . . . . . . 9 - B.7. Changes to draft-farinacci-lisp-eid-anonymity-02 . . . . 9 - B.8. Changes to draft-farinacci-lisp-eid-anonymity-01 . . . . 9 - B.9. Changes to draft-farinacci-lisp-eid-anonymity-00 . . . . 10 + B.1. Changes to draft-ietf-lisp-eid-anonymity-06 . . . . . . . 8 + B.2. Changes to draft-ietf-lisp-eid-anonymity-05 . . . . . . . 8 + B.3. Changes to draft-ietf-lisp-eid-anonymity-04 . . . . . . . 9 + B.4. Changes to draft-ietf-lisp-eid-anonymity-03 . . . . . . . 9 + B.5. Changes to draft-ietf-lisp-eid-anonymity-02 . . . . . . . 9 + B.6. Changes to draft-ietf-lisp-eid-anonymity-01 . . . . . . . 9 + B.7. Changes to draft-ietf-lisp-eid-anonymity-00 . . . . . . . 9 + B.8. Changes to draft-farinacci-lisp-eid-anonymity-02 . . . . 9 + B.9. Changes to draft-farinacci-lisp-eid-anonymity-01 . . . . 10 + B.10. Changes to draft-farinacci-lisp-eid-anonymity-00 . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction The LISP architecture [RFC6830] specifies two namespaces, End-Point IDs (EIDs) and Routing Locators (RLOCs). An EID identifies a node in the network and the RLOC indicates the EID's topological location. - Typically EIDs are globally unique so a end-node system can connect + Typically EIDs are globally unique so an end-node system can connect to any other end-node system on the Internet. Privately used EIDs are allowed when scoped within a VPN but must always be unique within that scope. Therefore, address allocation is required by network administration to avoid address collisions or duplicate address use. - In a multiple namespace architecture like LISP, typically the EID will stay fixed while the RLOC can change. This occurs when the EID is mobile or when the LISP site the EID resides in changes its connection to the Internet. LISP creates the opportunity where EIDs are fixed and won't change. This draft will examine a technique to allow a end-node system to use a temporary address. The lifetime of a temporary address can be the same as a lifetime of an address in use today on the Internet or can have traditionally shorter lifetimes, possibly on the order of a day @@ -120,21 +120,24 @@ services as a server system would. It accesses servers and attempts to do it anonymously. 3. Overview A client end-node can assign its own ephemeral EID and use it to talk to any system on the Internet. The system is acting as a client where it initiates communication and desires to be an inaccessible resource from any other system. The ephemeral EID is used as a destination address solely to return packets to resources the - ephemeral EID connects to. + ephemeral EID connects to. A client-node may simultaneously use a + traditional EID along with ephemeral EIDs in parallel and are not + mutually exclusive. A client may choose to use the ephemeral EIDs + with some peers only where it needs to preserve anonymity. Here is the procedure a client end-node would use: 1. Client end-node desires to talk on the network. It creates and assigns an ephemeral-EID on any interface. The client end-node may also assign multiple ephemeral-EIDs on the same interface or across different interfaces. 2. If the client end-node is a LISP xTR, it will register ephemeral- EIDs mapped to underlay routable RLOCs. If the client end-node @@ -162,21 +165,21 @@ block 2001:5::/32 [RFC7954] when IPv6 is used. See IANA Considerations section for a specific sub-block allocation request. When IPv4 is used, the Class E block 240.0.0.0/4 is being proposed. The client end-node system will use the rest of the host bits to allocate a random number to be used as the ephemeral-EID. The EID can be created manually or via a programatic interface. When the EID address is going to change frequently, it is suggested to use a programatic interface. The probability of address collision is unlikely for IPv6 EIDs but could occur for IPv4 EIDs. A client end- - node can create a ephemeral-EID and then look it up in the mapping + node can create an ephemeral-EID and then look it up in the mapping system to see if it exists. If the EID exists in the mapping system, the client end-node can attempt creation of a new random number for the ephemeral-EID. See Section 8 where ephemeral-EIDs can be preallocated and registered to the mapping system before use. When the client end-node system is co-located with the RLOC and acts as an xTR, it should register the binding before sending packets. This eliminates a race condition for returning packets not knowing where to encapsulate packets to the ephemeral-EID's RLOCs. See Section 8 for alternatives for fixing this race condition problem. @@ -232,22 +235,22 @@ band mechanisms. These mechanisms need to support ephemeral-EIDs. Otherwise, PIM-ASM [RFC4602] or PIM-Bidir [RFC5015] will need to be used. 8. Performance Improvements An optimization to reduce the race condition between registering ephemeral-EIDs and returning packets as well as reducing the probability of ephemeral-EID address collision is to preload the mapping database with a list of ephemeral-EIDs before using them. It - comes at a expense of rebinding all of registered ephemeral-EIDs when - there is an RLOC change. There is work in progress to consider + comes at the expense of rebinding all of registered ephemeral-EIDs + when there is an RLOC change. There is work in progress to consider adding a level of indirection here so a single entry gets the RLOC update and the list of ephemeral-EIDs point to the single entry. 9. Security Considerations When LISP-crypto [RFC8061] is used the EID payload is more secure through encryption providing EID obfuscation of the ephemeral-EID as well as the global-EID it is communicating with. But the obfuscation only occurs between xTRs. So the randomness of a ephemeral-EID inside of LISP sites provide a new level of privacy. @@ -353,79 +356,85 @@ Appendix A. Acknowledgments The author would like to thank the LISP WG for their review and acceptance of this draft. Appendix B. Document Change Log [RFC Editor: Please delete this section on publication as RFC.] -B.1. Changes to draft-ietf-lisp-eid-anonymity-05 +B.1. Changes to draft-ietf-lisp-eid-anonymity-06 + + o Posted end of March 2019. + + o Padma had more basic edits and some clarification text. + +B.2. Changes to draft-ietf-lisp-eid-anonymity-05 o Posted March IETF week 2019. o Do not state that ephemeral EIDs make the privacy problem worse. -B.2. Changes to draft-ietf-lisp-eid-anonymity-04 +B.3. Changes to draft-ietf-lisp-eid-anonymity-04 o Posted October 2018 before Bangkok IETF deadline. o Made Padma requested changes to refer to ephemeral-EIDs allowed to have many on one interface and can be registered with more than 1 RLOC but one RLOC-set. -B.3. Changes to draft-ietf-lisp-eid-anonymity-03 +B.4. Changes to draft-ietf-lisp-eid-anonymity-03 o Posted October 2018. o Update document timer and references. -B.4. Changes to draft-ietf-lisp-eid-anonymity-02 +B.5. Changes to draft-ietf-lisp-eid-anonymity-02 o Posted April 2018. o Update document timer and references. -B.5. Changes to draft-ietf-lisp-eid-anonymity-01 +B.6. Changes to draft-ietf-lisp-eid-anonymity-01 o Posted October 2017. o Add to section 5 that PKI can be used to authenticate EIDs. o Update references. -B.6. Changes to draft-ietf-lisp-eid-anonymity-00 +B.7. Changes to draft-ietf-lisp-eid-anonymity-00 o Posted August 2017. o Made draft-farinacci-lisp-eid-anonymity-02 a LISP working group document. -B.7. Changes to draft-farinacci-lisp-eid-anonymity-02 +B.8. Changes to draft-farinacci-lisp-eid-anonymity-02 o Posted April 2017. o Added section describing how ephemeral-EIDs can use a public key hash as an alternative to a random number. o Indciate when an EID/RLOC co-located, that the xTR can register the EID when it is configured or changed versus waiting for a packet to be sent as in the EID/RLOC separated case. -B.8. Changes to draft-farinacci-lisp-eid-anonymity-01 +B.9. Changes to draft-farinacci-lisp-eid-anonymity-01 o Posted October 2016. o Update document timer. -B.9. Changes to draft-farinacci-lisp-eid-anonymity-00 +B.10. Changes to draft-farinacci-lisp-eid-anonymity-00 o Posted April 2016. o Initial posting. Authors' Addresses Dino Farinacci lispers.net San Jose, CA