LISP EID Anonymity
lispers.net
San Jose CA
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 . Ephemeral-EIDs are not
stored in the Domain Name System (DNS) and should not be
used in long-term address referrals.
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.
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:
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.
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.
The client end-node originates packets with a source
address equal to the ephemeral-EID and will receive packets
addressed to the ephemeral-EID.
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.
This specification proposes the use of the experimental
LISP EID-block 2001:5::/32 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 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 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 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.
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 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 .
If a client end-node is communicating with a system that
is not in a LISP site, the procedures from should be followed. The PITR will be
required to originate route advertisements for the
ephemeral-EID sub-block so it can
attract packets sourced by non-LISP sites destined to
ephemeral-EIDs. However, in the general case, the coarse
block from 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.
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
and MLD
.
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 and when PIM is used with LISP . In addition, when
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 is
used. Members that join (S,G) channels via out of band
mechanisms. These mechanisms need to support
ephemeral-EIDs. Otherwise, PIM-ASM
or PIM-Bidir will need to be
used.
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.
When LISP-crypto 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.
This specification is requesting the sub-block
2001:5:ffff::/48 for ephemeral-EID usage.
The author would like to thank the LISP WG for their
review and acceptance of this draft.
[RFC Editor: Please delete this section on publication as RFC.]
Posted August 2023.
Update references (to propsed standard documents) and document timer.
Posted March 2023.
Update references (to propsed standard documents) and document timer.
Posted September 2022.
Update document timer and references.
Posted March 2022.
Update document timer and references.
Posted end of September 2021.
Update document timer and references.
Posted end of March 2021.
Update document timer and references.
Posted end of October 2020.
Update document timer and references.
Posted end of April 2020.
Update document timer and references.
Posted end of October 2019.
Update document timer and references.
Posted end of March 2019.
Padma had more basic edits and some clarification text.
Posted March IETF week 2019.
Do not state that ephemeral EIDs make the privacy problem
worse.
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.
Posted October 2018.
Update document timer and references.
Posted April 2018.
Update document timer and references.
Posted October 2017.
Add to section 5 that PKI can be used to authenticate
EIDs.
Update references.
Posted August 2017.
Made draft-farinacci-lisp-eid-anonymity-02 a LISP working
group document.
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.
Posted October 2016.
Update document timer.
Posted April 2016.
Initial posting.