Internet-Draft LISP EID Anonymity February 2024
Farinacci, et al. Expires 22 August 2024 [Page]
Network Working Group
Intended Status:
D. Farinacci
P. Pillay-Esnault
W. Haddad

LISP EID Anonymity


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

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

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

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 22 August 2024.

Table of Contents

1. Introduction

The LISP architecture [RFC9300] 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 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 or even change as frequent as new connection attempts.

2. Definition of Terms

Ephemeral-EID -
is an IP address that is created randomly for use for a temporary period of time. An Ephemeral-EID has all the properties of an EID as defined in [RFC9300]. Ephemeral-EIDs are not stored in the Domain Name System (DNS) and should not be used in long-term address referrals.
Client End-Node -
is a network node that originates and consumes packets. It is a system that originates packets or initiates the establishment of transport-layer connections. It does not offer 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. 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 is not a LISP xTR, it can send packets on the network where a LISP router xTR will register the ephemeral-EIDs with its RLOC-set.

  3. The client end-node originates packets with a source address equal to the ephemeral-EID and will receive packets addressed to the ephemeral-EID.

  4. When the client end-node decides to stop using an ephemeral-EID, it will deregister it from the mapping system and create and assign a new ephemeral-EID, or decide to configure a static global address, or participate in DHCP to get assigned a leased address.

Note that the ephemeral-EID can be mobile just like any other EID so if it is initially registered to the mapping system with one or more RLOCs, later the RLOC-set can change as the ephemeral-EID roams.

4. Design Details

This specification proposes the use of the experimental LISP EID-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 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 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. When the client end-node system is not acting as an xTR, it should send some packets so its ephemeral-EID can be discovered by an xTR which supports EID-mobility [I-D.ietf-lisp-eid-mobility] so mapping system registration can occur before the destination returns packets. When the end-node system is acting as an xTR, the EID and RLOC-set is co-located in the same node. So when the EID is created, the xTR can register the mapping versus waiting for packet transmission.

5. Other Types of Ephemeral-EIDs

When IPv6 Ephemeral-EIDs are used, an alternative to a random number can be used. For example, the low-order bits of the IPv6 address could be a cryptographic hash of a public-key. Mechanisms from [RFC3972] could be used for EIDs. Using this approach allows the sender with a hashed EID to be authenticated. So packet signatures can be verified by the corresponding public-key. When hashed EIDs are used, the EID can change frequently as rekeying may be required for enhanced security. LISP specific control message signature mechanims can be found in [I-D.farinacci-lisp-ecdsa-auth].

6. Interworking Considerations

If a client end-node is communicating with a system that is not in a LISP site, the procedures from [RFC6832] should be followed. The PITR will be required to originate route advertisements for the ephemeral-EID sub-block [RFC7954] so it can attract packets sourced by non-LISP sites destined to ephemeral-EIDs. However, in the general case, the coarse block from [RFC7954] will be advertised which would cover the sub-block. For IPv4, the must be advertised into the IPv4 routing system.

7. Multicast Considerations

A client end-node system can be a member of a multicast group fairly easily since its address is not used for multicast communication as a receiver. This is due to the design characteristics of IGMP [RFC3376] [RFC2236] [RFC1112] and MLD [RFC2710] [RFC3810].

When a client end-node system is a multicast source, there is ephemeral (S,G) state that is created and maintained in the network via multicast routing protocols such as PIM [RFC4602] and when PIM is used with LISP [RFC6802]. In addition, when [RFC8378] is used, ephemeral-EID state is created in the mapping database. This doesn't present any problems other than the amount of state that may exist in the network if not timed out and removed promptly.

However, there exists a multicast source discovery problem when PIM-SSM [RFC4607] is used. Members that join (S,G) channels via out of 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 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.

10. IANA Considerations

This specification is requesting the sub-block 2001:5:ffff::/48 for ephemeral-EID usage.

11. References

11.1. Normative References

Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, DOI 10.17487/RFC1112, , <>.
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <>.
Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, DOI 10.17487/RFC2236, , <>.
Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, DOI 10.17487/RFC2710, , <>.
Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, DOI 10.17487/RFC3376, , <>.
Vida, R., Ed. and L. Costa, Ed., "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, DOI 10.17487/RFC3810, , <>.
Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, DOI 10.17487/RFC3972, , <>.
Pusateri, T., "Protocol Independent Multicast - Sparse Mode (PIM-SM) IETF Proposed Standard Requirements Analysis", RFC 4602, DOI 10.17487/RFC4602, , <>.
Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, DOI 10.17487/RFC4607, , <>.
Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bidirectional Protocol Independent Multicast (BIDIR-PIM)", RFC 5015, DOI 10.17487/RFC5015, , <>.
Baillargeon, S., Flinta, C., and A. Johnsson, "Ericsson Two-Way Active Measurement Protocol (TWAMP) Value-Added Octets", RFC 6802, DOI 10.17487/RFC6802, , <>.
Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, "Interworking between Locator/ID Separation Protocol (LISP) and Non-LISP Sites", RFC 6832, DOI 10.17487/RFC6832, , <>.
Iannone, L., Lewis, D., Meyer, D., and V. Fuller, "Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block", RFC 7954, DOI 10.17487/RFC7954, , <>.
Farinacci, D. and B. Weis, "Locator/ID Separation Protocol (LISP) Data-Plane Confidentiality", RFC 8061, DOI 10.17487/RFC8061, , <>.
Moreno, V. and D. Farinacci, "Signal-Free Locator/ID Separation Protocol (LISP) Multicast", RFC 8378, DOI 10.17487/RFC8378, , <>.
Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. Cabellos, Ed., "The Locator/ID Separation Protocol (LISP)", RFC 9300, DOI 10.17487/RFC9300, , <>.

11.2. Informative References

Farinacci, D. and E. Nordmark, "LISP Control-Plane ECDSA Authentication and Authorization", Work in Progress, Internet-Draft, draft-farinacci-lisp-ecdsa-auth-03, , <>.
Portoles-Comeras, M., Ashtaputre, V., Maino, F., Moreno, V., and D. Farinacci, "LISP L2/L3 EID Mobility Using a Unified Control Plane", Work in Progress, Internet-Draft, draft-ietf-lisp-eid-mobility-13, , <>.

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-16

B.2. Changes to draft-ietf-lisp-eid-anonymity-15

B.3. Changes to draft-ietf-lisp-eid-anonymity-14

B.4. Changes to draft-ietf-lisp-eid-anonymity-13

B.5. Changes to draft-ietf-lisp-eid-anonymity-12

B.6. Changes to draft-ietf-lisp-eid-anonymity-11

B.7. Changes to draft-ietf-lisp-eid-anonymity-10

B.8. Changes to draft-ietf-lisp-eid-anonymity-09

B.9. Changes to draft-ietf-lisp-eid-anonymity-08

B.10. Changes to draft-ietf-lisp-eid-anonymity-07

B.11. Changes to draft-ietf-lisp-eid-anonymity-06

B.12. Changes to draft-ietf-lisp-eid-anonymity-05

B.13. Changes to draft-ietf-lisp-eid-anonymity-04

B.14. Changes to draft-ietf-lisp-eid-anonymity-03

B.15. Changes to draft-ietf-lisp-eid-anonymity-02

B.16. Changes to draft-ietf-lisp-eid-anonymity-01

B.17. Changes to draft-ietf-lisp-eid-anonymity-00

B.18. Changes to draft-farinacci-lisp-eid-anonymity-02

B.19. Changes to draft-farinacci-lisp-eid-anonymity-01

B.20. Changes to draft-farinacci-lisp-eid-anonymity-00

Authors' Addresses

Dino Farinacci
San Jose, CA
United States of America
Padma Pillay-Esnault
Santa Clara, CA
United States of America
Wassim Haddad
Santa Clara, CA
United States of America