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