LISP EID Anonymity
draft-ietf-lisp-eid-anonymity-14
| Document | Type | Active Internet-Draft (lisp WG) | |
|---|---|---|---|
| Authors | Dino Farinacci , Padma Pillay-Esnault , Wassim Haddad | ||
| Last updated | 2023-03-05 | ||
| Replaces | draft-farinacci-lisp-eid-anonymity | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-lisp-eid-anonymity-14
Network Working Group D. Farinacci
Internet-Draft lispers.net
Intended status: Experimental P. Pillay-Esnault
Expires: 6 September 2023 Independent
W. Haddad
Ericsson
5 March 2023
LISP EID Anonymity
draft-ietf-lisp-eid-anonymity-14
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
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 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 6 September 2023.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
Farinacci, et al. Expires 6 September 2023 [Page 1]
Internet-Draft LISP EID Anonymity March 2023
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 carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Design Details . . . . . . . . . . . . . . . . . . . . . . . 4
5. Other Types of Ephemeral-EIDs . . . . . . . . . . . . . . . . 5
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 . . . . . . . . . . . . . . . . 9
B.1. Changes to draft-ietf-lisp-eid-anonymity-14 . . . . . . . 9
B.2. Changes to draft-ietf-lisp-eid-anonymity-13 . . . . . . . 9
B.3. Changes to draft-ietf-lisp-eid-anonymity-12 . . . . . . . 9
B.4. Changes to draft-ietf-lisp-eid-anonymity-11 . . . . . . . 9
B.5. Changes to draft-ietf-lisp-eid-anonymity-10 . . . . . . . 9
B.6. Changes to draft-ietf-lisp-eid-anonymity-09 . . . . . . . 9
B.7. Changes to draft-ietf-lisp-eid-anonymity-08 . . . . . . . 9
B.8. Changes to draft-ietf-lisp-eid-anonymity-07 . . . . . . . 10
B.9. Changes to draft-ietf-lisp-eid-anonymity-06 . . . . . . . 10
B.10. Changes to draft-ietf-lisp-eid-anonymity-05 . . . . . . . 10
B.11. Changes to draft-ietf-lisp-eid-anonymity-04 . . . . . . . 10
B.12. Changes to draft-ietf-lisp-eid-anonymity-03 . . . . . . . 10
B.13. Changes to draft-ietf-lisp-eid-anonymity-02 . . . . . . . 10
B.14. Changes to draft-ietf-lisp-eid-anonymity-01 . . . . . . . 10
B.15. Changes to draft-ietf-lisp-eid-anonymity-00 . . . . . . . 10
B.16. Changes to draft-farinacci-lisp-eid-anonymity-02 . . . . 11
B.17. Changes to draft-farinacci-lisp-eid-anonymity-01 . . . . 11
B.18. Changes to draft-farinacci-lisp-eid-anonymity-00 . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
Farinacci, et al. Expires 6 September 2023 [Page 2]
Internet-Draft LISP EID Anonymity March 2023
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.
Farinacci, et al. Expires 6 September 2023 [Page 3]
Internet-Draft LISP EID Anonymity March 2023
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 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 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.
Farinacci, et al. Expires 6 September 2023 [Page 4]
Internet-Draft LISP EID Anonymity March 2023
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 240.0.0.0/4 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].
Farinacci, et al. Expires 6 September 2023 [Page 5]
Internet-Draft LISP EID Anonymity March 2023
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
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5,
RFC 1112, DOI 10.17487/RFC1112, August 1989,
<https://www.rfc-editor.org/info/rfc1112>.
Farinacci, et al. Expires 6 September 2023 [Page 6]
Internet-Draft LISP EID Anonymity March 2023
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2236] Fenner, W., "Internet Group Management Protocol, Version
2", RFC 2236, DOI 10.17487/RFC2236, November 1997,
<https://www.rfc-editor.org/info/rfc2236>.
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast
Listener Discovery (MLD) for IPv6", RFC 2710,
DOI 10.17487/RFC2710, October 1999,
<https://www.rfc-editor.org/info/rfc2710>.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, DOI 10.17487/RFC3376, October 2002,
<https://www.rfc-editor.org/info/rfc3376>.
[RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener
Discovery Version 2 (MLDv2) for IPv6", RFC 3810,
DOI 10.17487/RFC3810, June 2004,
<https://www.rfc-editor.org/info/rfc3810>.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, DOI 10.17487/RFC3972, March 2005,
<https://www.rfc-editor.org/info/rfc3972>.
[RFC4602] Pusateri, T., "Protocol Independent Multicast - Sparse
Mode (PIM-SM) IETF Proposed Standard Requirements
Analysis", RFC 4602, DOI 10.17487/RFC4602, August 2006,
<https://www.rfc-editor.org/info/rfc4602>.
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", RFC 4607, DOI 10.17487/RFC4607, August 2006,
<https://www.rfc-editor.org/info/rfc4607>.
[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
"Bidirectional Protocol Independent Multicast (BIDIR-
PIM)", RFC 5015, DOI 10.17487/RFC5015, October 2007,
<https://www.rfc-editor.org/info/rfc5015>.
[RFC6802] Baillargeon, S., Flinta, C., and A. Johnsson, "Ericsson
Two-Way Active Measurement Protocol (TWAMP) Value-Added
Octets", RFC 6802, DOI 10.17487/RFC6802, November 2012,
<https://www.rfc-editor.org/info/rfc6802>.
Farinacci, et al. Expires 6 September 2023 [Page 7]
Internet-Draft LISP EID Anonymity March 2023
[RFC6832] 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, January 2013,
<https://www.rfc-editor.org/info/rfc6832>.
[RFC7954] Iannone, L., Lewis, D., Meyer, D., and V. Fuller,
"Locator/ID Separation Protocol (LISP) Endpoint Identifier
(EID) Block", RFC 7954, DOI 10.17487/RFC7954, September
2016, <https://www.rfc-editor.org/info/rfc7954>.
[RFC8061] Farinacci, D. and B. Weis, "Locator/ID Separation Protocol
(LISP) Data-Plane Confidentiality", RFC 8061,
DOI 10.17487/RFC8061, February 2017,
<https://www.rfc-editor.org/info/rfc8061>.
[RFC8378] Moreno, V. and D. Farinacci, "Signal-Free Locator/ID
Separation Protocol (LISP) Multicast", RFC 8378,
DOI 10.17487/RFC8378, May 2018,
<https://www.rfc-editor.org/info/rfc8378>.
[RFC9300] Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A.
Cabellos, Ed., "The Locator/ID Separation Protocol
(LISP)", RFC 9300, DOI 10.17487/RFC9300, October 2022,
<https://www.rfc-editor.org/info/rfc9300>.
11.2. Informative References
[I-D.farinacci-lisp-ecdsa-auth]
Farinacci, D. and E. Nordmark, "LISP Control-Plane ECDSA
Authentication and Authorization", Work in Progress,
Internet-Draft, draft-farinacci-lisp-ecdsa-auth-03, 4
September 2018, <https://datatracker.ietf.org/doc/html/
draft-farinacci-lisp-ecdsa-auth-03>.
[I-D.ietf-lisp-eid-mobility]
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-11, 10 January 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-lisp-
eid-mobility-11>.
Appendix A. Acknowledgments
The author would like to thank the LISP WG for their review and
acceptance of this draft.
Farinacci, et al. Expires 6 September 2023 [Page 8]
Internet-Draft LISP EID Anonymity March 2023
Appendix B. Document Change Log
[RFC Editor: Please delete this section on publication as RFC.]
B.1. Changes to draft-ietf-lisp-eid-anonymity-14
* Posted March 2023.
* Update references (to propsed standard documents) and document
timer.
B.2. Changes to draft-ietf-lisp-eid-anonymity-13
* Posted September 2022.
* Update document timer and references.
B.3. Changes to draft-ietf-lisp-eid-anonymity-12
* Posted March 2022.
* Update document timer and references.
B.4. Changes to draft-ietf-lisp-eid-anonymity-11
* Posted end of September 2021.
* Update document timer and references.
B.5. Changes to draft-ietf-lisp-eid-anonymity-10
* Posted end of March 2021.
* Update document timer and references.
B.6. Changes to draft-ietf-lisp-eid-anonymity-09
* Posted end of October 2020.
* Update document timer and references.
B.7. Changes to draft-ietf-lisp-eid-anonymity-08
* Posted end of April 2020.
* Update document timer and references.
Farinacci, et al. Expires 6 September 2023 [Page 9]
Internet-Draft LISP EID Anonymity March 2023
B.8. Changes to draft-ietf-lisp-eid-anonymity-07
* Posted end of October 2019.
* Update document timer and references.
B.9. Changes to draft-ietf-lisp-eid-anonymity-06
* Posted end of March 2019.
* Padma had more basic edits and some clarification text.
B.10. Changes to draft-ietf-lisp-eid-anonymity-05
* Posted March IETF week 2019.
* Do not state that ephemeral EIDs make the privacy problem worse.
B.11. Changes to draft-ietf-lisp-eid-anonymity-04
* Posted October 2018 before Bangkok IETF deadline.
* 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.12. Changes to draft-ietf-lisp-eid-anonymity-03
* Posted October 2018.
* Update document timer and references.
B.13. Changes to draft-ietf-lisp-eid-anonymity-02
* Posted April 2018.
* Update document timer and references.
B.14. Changes to draft-ietf-lisp-eid-anonymity-01
* Posted October 2017.
* Add to section 5 that PKI can be used to authenticate EIDs.
* Update references.
B.15. Changes to draft-ietf-lisp-eid-anonymity-00
Farinacci, et al. Expires 6 September 2023 [Page 10]
Internet-Draft LISP EID Anonymity March 2023
* Posted August 2017.
* Made draft-farinacci-lisp-eid-anonymity-02 a LISP working group
document.
B.16. Changes to draft-farinacci-lisp-eid-anonymity-02
* Posted April 2017.
* Added section describing how ephemeral-EIDs can use a public key
hash as an alternative to a random number.
* 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.17. Changes to draft-farinacci-lisp-eid-anonymity-01
* Posted October 2016.
* Update document timer.
B.18. Changes to draft-farinacci-lisp-eid-anonymity-00
* Posted April 2016.
* Initial posting.
Authors' Addresses
Dino Farinacci
lispers.net
San Jose, CA
United States of America
Email: farinacci@gmail.com
Padma Pillay-Esnault
Independent
Santa Clara, CA
United States of America
Email: padma.ietf@gmail.com
Wassim Haddad
Ericsson
Santa Clara, CA
United States of America
Farinacci, et al. Expires 6 September 2023 [Page 11]
Internet-Draft LISP EID Anonymity March 2023
Email: wassim.haddad@ericsson.com
Farinacci, et al. Expires 6 September 2023 [Page 12]