draft-ietf-lisp-threats-08.txt		draft-ietf-lisp-threats-09.txt
	Network Working Group D. Saucez		Network Working Group D. Saucez
	Internet-Draft INRIA		Internet-Draft INRIA
	Intended status: Informational L. Iannone		Intended status: Informational L. Iannone
	Expires: April 24, 2014 Telecom ParisTech		Expires: October 10, 2014 Telecom ParisTech
	O. Bonaventure		O. Bonaventure
	Universite catholique de Louvain		Universite catholique de Louvain
	October 21, 2013		April 8, 2014
	LISP Threats Analysis		LISP Threats Analysis
	draft-ietf-lisp-threats-08.txt		draft-ietf-lisp-threats-09.txt
	Abstract		Abstract
	This document proposes a threat analysis of the Locator/Identifier		This document proposes a threat analysis of the Locator/Identifier
	Separation Protocol (LISP) if deployed in the Internet.		Separation Protocol (LISP) if deployed in the Internet.
	Status of This Memo		Status of this Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 http://datatracker.ietf.org/drafts/current/.		Drafts is at http://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 April 24, 2014.		This Internet-Draft will expire on October 10, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2014 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
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. On-path Attackers . . . . . . . . . . . . . . . . . . . . . . 3		2. On-path Attackers . . . . . . . . . . . . . . . . . . . . . . 3
	3. Off-Path Attackers: Reference Environment . . . . . . . . . . 4		3. Off-Path Attackers: Reference Environment . . . . . . . . . . 3
	4. Attack vectors . . . . . . . . . . . . . . . . . . . . . . . 5		4. Attack vectors . . . . . . . . . . . . . . . . . . . . . . . . 5
	4.1. Configured EID-to-RLOC mappings . . . . . . . . . . . . . 5		4.1. Configured EID-to-RLOC mappings . . . . . . . . . . . . . 6
	4.2. EID-to-RLOC Cache . . . . . . . . . . . . . . . . . . . . 6		4.2. EID-to-RLOC Cache . . . . . . . . . . . . . . . . . . . . 6
	4.3. Attacks using the data-plane . . . . . . . . . . . . . . 6		4.3. Attacks using the data-plane . . . . . . . . . . . . . . . 7
	4.3.1. Attacks not leveraging on the LISP header . . . . . . 6		4.3.1. Attacks not leveraging on the LISP header . . . . . . 7
	4.3.2. Attacks leveraging on the LISP header . . . . . . . . 8		4.3.2. Attacks leveraging on the LISP header . . . . . . . . 8
	4.4. Attacks using the control-plane . . . . . . . . . . . . . 11		4.4. Attacks using the control-plane . . . . . . . . . . . . . 11
	4.4.1. Attacks with Map-Request messages . . . . . . . . . . 11		4.4.1. Attacks with Map-Request messages . . . . . . . . . . 11
	4.4.2. Attacks with Map-Reply messages . . . . . . . . . . . 12		4.4.2. Attacks with Map-Reply messages . . . . . . . . . . . 12
	4.4.3. Attacks with Map-Register messages . . . . . . . . . 13		4.4.3. Attacks with Map-Register messages . . . . . . . . . . 13
	4.4.4. Attacks with Map-Notify messages . . . . . . . . . . 14		4.4.4. Attacks with Map-Notify messages . . . . . . . . . . . 14
	5. Attack categories . . . . . . . . . . . . . . . . . . . . . . 14		5. Attack categories . . . . . . . . . . . . . . . . . . . . . . 14
	5.1. Intrusion . . . . . . . . . . . . . . . . . . . . . . . . 14		5.1. Intrusion . . . . . . . . . . . . . . . . . . . . . . . . 14
	5.1.1. Description . . . . . . . . . . . . . . . . . . . . . 14		5.1.1. Description . . . . . . . . . . . . . . . . . . . . . 14
	5.1.2. Vectors . . . . . . . . . . . . . . . . . . . . . . . 14		5.1.2. Vectors . . . . . . . . . . . . . . . . . . . . . . . 14
	5.2. Denial of Service (DoS) . . . . . . . . . . . . . . . . . 14		5.2. Denial of Service (DoS) . . . . . . . . . . . . . . . . . 14
	5.2.1. Description . . . . . . . . . . . . . . . . . . . . . 14		5.2.1. Description . . . . . . . . . . . . . . . . . . . . . 14
	5.2.2. Vectors . . . . . . . . . . . . . . . . . . . . . . . 15		5.2.2. Vectors . . . . . . . . . . . . . . . . . . . . . . . 14
	5.3. Subversion . . . . . . . . . . . . . . . . . . . . . . . 15		5.3. Subversion . . . . . . . . . . . . . . . . . . . . . . . . 15
	5.3.1. Description . . . . . . . . . . . . . . . . . . . . . 15		5.3.1. Description . . . . . . . . . . . . . . . . . . . . . 15
	5.3.2. Vectors . . . . . . . . . . . . . . . . . . . . . . . 15		5.3.2. Vectors . . . . . . . . . . . . . . . . . . . . . . . 15
	6. Note on privacy . . . . . . . . . . . . . . . . . . . . . . . 16		6. Note on Privacy . . . . . . . . . . . . . . . . . . . . . . . 16
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 16		8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
	10.1. Normative References . . . . . . . . . . . . . . . . . . 17		10.1. Normative References . . . . . . . . . . . . . . . . . . . 17
	10.2. Informative References . . . . . . . . . . . . . . . . . 18		10.2. Informative References . . . . . . . . . . . . . . . . . . 17
	Appendix A. Document Change Log . . . . . . . . . . . . . . . . 19		Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 18
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
	1. Introduction		1. Introduction
	The Locator/ID Separation Protocol (LISP) is defined in [RFC6830].		The Locator/ID Separation Protocol (LISP) is specified in [RFC6830].
	The present document assesses the security level and identifies		The present document assess the potential security threats identified
	security threats in the LISP specification if LISP is deployed in the		in the LISP specifications if LISP is deployed in the Internet (i.e.,
	Internet (i.e., a public non-trustable environment). As a result of		a public non-trustable environment).
	the performed analysis, the document discusses the severity of the
	threats and proposes recommendations to reach the same level of
	security in LISP than in Internet today (e.g., without LISP).
	The document is composed of three main parts: the first discussing
	the LISP data-plane; while the second discussing the LISP control-
	plane. The final part summarizes the recommendations to prevent the
	identified threats.
	The LISP data-plane consists of LISP packet encapsulation,
	decapsulation, and forwarding and includes the map cache data
	structures used to perform these operations.
	The LISP control-plane consists in the mapping distribution system,		The document is composed of two main parts: the first discussing the
	which can be one of the mapping distribution systems proposed so far		techniques that can be used by attackers to succeed attacks based on
	(e.g., [RFC6830], [I-D.ietf-lisp-ddt], [RFC6836], [RFC6833],		the LISP protocol and architecture; the second discussing the main
	[I-D.meyer-lisp-cons], and [RFC6837]), and the Map-Request, Map-		categories of attacks and how to construct them.
	Reply, Map-Register, and Map-Notification messages.
	This document does not consider all the possible uses of LISP as		This document does not consider all the possible uses of LISP as
	discussed in [RFC6830]. The document focuses on LISP unicast,		discussed in [RFC6830] and [I-D.ietf-lisp-deployment]. The document
	including as well LISP Interworking [RFC6832], LISP-MS [RFC6833], and		focuses on LISP unicast, including as well LISP Interworking
	LISP Map-Versioning [RFC6834]. The reading of these documents is a		[RFC6832], LISP-MS [RFC6833], and LISP Map-Versioning [RFC6834]. The
	prerequisite for understanding the present document.		reading of these documents is a prerequisite for understanding the
			present document.
	Unless otherwise stated, the document assumes a generic IP service		This document assumes a generic IP service and does not discuss the
	and does not discuss the difference, from a security viewpoint,		difference, from a security viewpoint, between using IPv4 or IPv6.
	between using IPv4 or IPv6.
	2. On-path Attackers		2. On-path Attackers
	On-path attackers are attackers that are able to capture and modify		On-path attackers are attackers that are able to capture and modify
	all the packets exchanged between an Ingress Tunnel Router (ITR) and		all the packets exchanged between an Ingress Tunnel Router (ITR) and
	an Egress Tunnel Router (ETR). To cope with such an attacker,		an Egress Tunnel Router (ETR). To cope with such an attacker,
	cryptographic techniques such as those used by IPSec ([RFC4301]) are		cryptographic techniques such as those used by IPSec ([RFC4301]) are
	required. As with IP, LISP relies on higher layer cryptography to		required. As with IP, LISP relies on higher layer cryptography to
	secure packet payloads from on path attacks, so this document does		secure packet payloads from on path attacks, so this document does
	not consider on-path attackers in this document.		not consider on-path attackers.
	Similarly, a time-shifted attack is an attack where the attacker is		Similarly, a time-shifted attack is an attack where the attacker is
	temporarily on the path between two communicating hosts. While it is		temporarily on the path between two communicating hosts. While it is
	on-path, the attacker sends specially crafted packets or modifies		on-path, the attacker sends specially crafted packets or modifies
	packets exchanged by the communicating hosts in order to disturb the		packets exchanged by the communicating hosts in order to disturb the
	packet flow (e.g., by performing a man in the middle attack). An		packet flow (e.g., by performing a man in the middle attack). An
	important issue for time-shifted attacks is the duration of the		important issue for time-shifted attacks is the duration of the
	attack once the attacker has left the path between the two		attack once the attacker has left the path between the two
	communicating hosts. We do not consider time-shifted attacks in this		communicating hosts. This documents does not consider time-shifted
	document.		attacks.
	3. Off-Path Attackers: Reference Environment		3. Off-Path Attackers: Reference Environment
	The reference environment shown in the figure below is considered		The reference environment shown in the figure below is considered
	throughout this document. There are two hosts attached to LISP		throughout this document. There are two hosts attached to LISP
	routers: HA and HB. HA is attached to the two LISP xTRs LR1 and LR2,		routers: HA and HB. HA is attached to the two LISP xTRs LR1 and LR2,
	which in turn are attached to two different ISPs. HB is attached to		which in turn are attached to two different ISPs. HB is attached to
	the two LISP xTRs LR3 and LR4. HA and HB are the EIDs of the two		the two LISP xTRs LR3 and LR4. HA and HB are the EIDs of the two
	hosts. LR1, LR2, LR3, and LR4 are the RLOCs of the xTRs. PxTR is a		hosts. LR1, LR2, LR3, and LR4 are the RLOCs of the xTRs. PxTR is a
	proxy xTR and MR/MS plays the roles of Map Server and/or Map		proxy xTR and MR/MS plays the roles of Map Server and/or Map
	Resolver.		Resolver.
	+-----+		+-----+
	| HA |		| HA |
	+-----+		+-----+
	| EID: HA		| EID: HA
	|		|
	-----------------		-----------------
	| |		| |
	+-----+ +-----+		+-----+ +-----+
	| LR1 | | LR2 |		| LR1 | | LR2 |
	+-----+ +-----+		+-----+ +-----+
	| |		| |
	| |		| |
	+-----+ +-----+		+-----+ +-----+
	|ISP1 | |ISP2 |		|ISP1 | |ISP2 |
	+-----+ +-----+		+-----+ +-----+
	| |		| |
	skipping to change at page 4, line 44		skipping to change at page 4, line 39
	+------+ | | +-----+		+------+ | | +-----+
	| Internet |		| Internet |
	+-------+ | | +-----+		+-------+ | | +-----+
	| MR/MS |----| |-----| NSA |		| MR/MS |----| |-----| NSA |
	+-------+ +----------------+ +-----+		+-------+ +----------------+ +-----+
	| |		| |
	+-----+ +-----+		+-----+ +-----+
	| LR3 | | LR4 |		| LR3 | | LR4 |
	+-----+ +-----+		+-----+ +-----+
	| |		| |
	-------------------		-------------------
	|		|
	| EID: HB		| EID: HB
	+-----+		+-----+
	| HB |		| HB |
	+-----+		+-----+
	Figure 1: Reference Network		Figure 1: Reference Network
	We consider two off-path attackers with different capabilities:		We consider two off-path attackers with different capabilities:
	SA is an off-path attacker that is able to send spoofed packets,		SA is an off-path attacker that is able to send spoofed packets,
	i.e., packets with a different source IP address than its		i.e., packets with a different source IP address than its
	assigned IP address. SA stands for Spoofing Attacker.		assigned IP address. SA stands for Spoofing Attacker. To
			perform some of the attacks described in this document SA needs
			to be in a non-LISP site.
	NSA is an off-path attacker that is only able to send packets whose		NSA is an off-path attacker that is only able to send packets whose
	source address is its assigned IP address. NSA stands for Non		source address is its assigned IP address. NSA stands for Non
	Spoofing Attacker.		Spoofing Attacker.
	It should be noted that with LISP, packet spoofing is slightly		It should be noted that with LISP, packet spoofing is slightly
	different than in the current Internet. Generally the term "spoofed		different than in the current Internet. Generally the term "spoofed
	packet" indicates a packet containing a source IP address that is not		packet" indicates a packet containing a source IP address that is not
	the one of the actual originator of the packet. Since LISP uses		the one of the actual originator of the packet. Since LISP uses
	encapsulation, the spoofed address could be in the outer header as		encapsulation, the spoofed address could be in the outer header as
	skipping to change at page 6, line 22		skipping to change at page 6, line 27
	4.2. EID-to-RLOC Cache		4.2. EID-to-RLOC Cache
	The EID-to-RLOC Cache (also called the Map-Cache) is the data		The EID-to-RLOC Cache (also called the Map-Cache) is the data
	structure that stores a copy of the mappings retrieved from a remote		structure that stores a copy of the mappings retrieved from a remote
	ETR's mapping via the LISP control-plane. Attacks against this data		ETR's mapping via the LISP control-plane. Attacks against this data
	structure could happen either when the mappings are first installed		structure could happen either when the mappings are first installed
	in the cache or by corrupting (poisoning) the mappings already		in the cache or by corrupting (poisoning) the mappings already
	present in the cache.		present in the cache.
	This document calls "cache poisoning attack", any attack that alters		Cache poisoning attacks are used to alter (any combination of) the
	the EID-to-RLOC Cache. Cache poisoning attacks are use to alter (any		following parts of the mappings installed in the EID-to-RLOC Cache:
	combination of) the following parts of mapping installed in the EID-
	to-RLOC Cache:
	o EID prefix		o EID prefix
	o RLOC list		o RLOC list
	o RLOC priority		o RLOC priority
	o RLOC weight		o RLOC weight
	o RLOC reachability		o RLOC reachability
	o Mapping TTL		o Mapping TTL
	o Mapping version		o Mapping version
	o Mapping Instance ID		o Mapping Instance ID
			Cache poisoning attacks can be performed by attackers from the
			outside of the attacked LISP network but also directly from the
			inside. As a matter of fact, end-hosts behind an ITR can use the
			data-plane to overflow the ITR's EID-to-RLOC Cache by sending packets
			to non-popular EID prefixes (similar to scan attack but with a
			different goal). In such a scenario the ITR may evict popular (in-
			use) entries from the map-cache disrupting the normal operation of
			the network by forcing cache miss [Florin13].
	4.3. Attacks using the data-plane		4.3. Attacks using the data-plane
	The data-plane is constituted of the operations of encapsulation,		The data-plane is constituted of the operations of encapsulation,
	decapsulation, and forwarding as well as the content of the EID-to-		decapsulation, and forwarding as well as the content of the EID-to-
	RLOC Cache and configured EID-to-RLOC mappings as specified in the		RLOC Cache and configured EID-to-RLOC mappings as specified in the
	original LISP document ([RFC6830]).		original LISP document ([RFC6830]).
	4.3.1. Attacks not leveraging on the LISP header		4.3.1. Attacks not leveraging on the LISP header
	An attacker can inject packets into flows without using the LISP		An attacker can inject packets into flows without using the LISP
	header, i.e., with the N, L, E, V, and I bits ([RFC6830]).		header, i.e., with the N, L, E, V, and I bits ([RFC6830]).
	Taking notation of the reference environment notation (Figure 1), to		Taking notation of the reference environment (Figure 1), to inject a
	inject a packet in the HA->HB flow, a spoofing off-path attacker (SA)		packet in the HA->HB flow, a spoofing off-path attacker (SA) could
	could send a LISP encapsulated packet whose source is set to LR1 or		send a LISP encapsulated packet whose source is set to LR1 or LR2 and
	LR2 and destination LR3 or LR4. The packet will reach HB as if the		destination LR3 or LR4. The packet will reach HB as if the packet
	packet was sent by host HA. This is not different from today's		was sent by host HA. This is not different from today's Internet
	Internet where a spoofing off-path attacker may inject data packets		where a spoofing off-path attacker may inject data packets in any
	in any flow. A non-spoofing off-path attacker (NSA) could only send		flow. A non-spoofing off-path attacker (NSA) could only send a
	a packet whose source address is set to its assigned IP address. The		packet whose source address is set to its assigned IP address. The
	destination address of the encapsulated packet could be LR3 or LR4.		destination address of the encapsulated packet could be LR3 or LR4.
	4.3.1.1. Gleaning Attacks		4.3.1.1. Gleaning Attacks
	In order to reduce the time required to obtain a mapping, [RFC6830]		In order to reduce the time required to obtain a mapping, [RFC6830]
	proposes the gleaning mechanism that allows an ITR to learn a mapping		proposes the gleaning mechanism that allows an ITR to learn a mapping
	from the LISP data encapsulated packets and the Map-Request packets		from the LISP data encapsulated packets and the Map-Request packets
	that it receives. LISP data encapsulated packet contains a source		that it receives. LISP data encapsulated packet contains a source
	RLOC, destination RLOC, source EID and destination EID. When an ITR		RLOC, destination RLOC, source EID and destination EID. When an ITR
	receives a data encapsulated packet coming from a source EID for		receives a data encapsulated packet coming from a source EID for
	skipping to change at page 8, line 6		skipping to change at page 8, line 6
	An attacker can send LISP encapsulated packets to host HB with host		An attacker can send LISP encapsulated packets to host HB with host
	HA's EID and if the xTRs that serve host HB do not store a mapping		HA's EID and if the xTRs that serve host HB do not store a mapping
	for host HA at that time. The xTR will store the gleaned entry and		for host HA at that time. The xTR will store the gleaned entry and
	use it to return the packets sent by host HB. In parallel, the ETR		use it to return the packets sent by host HB. In parallel, the ETR
	will send a Map-Request to retrieve the mapping for HA but until the		will send a Map-Request to retrieve the mapping for HA but until the
	reception of the Map-Reply, host HB will exchange packets with the		reception of the Map-Reply, host HB will exchange packets with the
	attacker instead of HA.		attacker instead of HA.
	Similarly, if an off-path attacker knows that hosts HA and HB that		Similarly, if an off-path attacker knows that hosts HA and HB that
	resides in different sites will exchange information at time t the		resides in different sites will exchange information at a given time
	attacker could send to LR1 (resp. LR3) a LISP data encapsulated		the attacker could send to LR1 (resp. LR3) a LISP data encapsulated
	packet whose source RLOC is its IP address and contains an IP packet		packet whose source RLOC is its IP address and contains an IP packet
	whose source is set to HB (resp. HA). The attacker chooses a packet		whose source is set to HB (resp. HA). The attacker chooses a packet
	that will not trigger an answer, for example the last part of a		that will not trigger an answer, for example the last part of a
	fragmented packet. Upon reception of these packets, LR1 and LR3		fragmented packet. Upon reception of these packets, LR1 and LR3
	install gleaned entries that point to the attacker. If host HA is		install gleaned entries that point to the attacker. If host HA is
	willing to establishes a flow with host HB at that time, the packets		willing to establish a flow with host HB at that time, the packets
	that they exchange will pass through the attacker as long as the		that they exchange will pass through the attacker as long as the
	gleaned entry is active on the xTRs.		gleaned entry is active on the xTRs.
	By itself, an attack made solely using gleaning cannot last long,		By itself, an attack made solely using gleaning cannot last long,
	however it should be noted that with current network capacities, a		however it should be noted that with current network capacities, a
	large amount of packets might be exchanged during even a small		large amount of packets might be exchanged during even a small
	fraction of time.		fraction of time.
	4.3.1.2. Threats concerning Interworking		4.3.1.2. Threats concerning Interworking
	[RFC6832] defines Proxy-ITR And Proxy-ETR network elements to allow		[RFC6832] defines Proxy-ITR and Proxy-ETR network elements to allow
	LISP and non-LISP sites to communicate. The Proxy-ITR has		LISP and non-LISP sites to communicate. The Proxy-ITR has
	functionality similar to the ITR, however, its main purpose is to		functionality similar to the ITR, however, its main purpose is to
	encapsulate packets arriving from the DFZ in order to reach LISP		encapsulate packets arriving from the DFZ in order to reach LISP
	sites. A Proxy-ETR has functionality similar to the ETR, however,		sites. A Proxy-ETR has functionality similar to the ETR, however,
	its main purpose is to inject de-encapsulated packets in the DFZ in		its main purpose is to inject de-encapsulated packets in the DFZ in
	order to reach non-LISP Sites from LISP sites. As a PITR (resp.		order to reach non-LISP Sites from LISP sites. As a PITR (resp.
	PETR) is a particular case of ITR (resp. ETR), it is subject to same		PETR) is a particular case of ITR (resp. ETR), it is subject to same
	attacks than ITRs (resp. ETR).		attacks than ITRs (resp. ETR).
	PxTRs can be targeted by attacks aiming to influence traffic between		PxTRs can be targeted by attacks aiming to influence traffic between
	skipping to change at page 9, line 51		skipping to change at page 9, line 45
	send a Map-Request for the source EID.		send a Map-Request for the source EID.
	An off-path attacker could use the Map-Version bit to force an ETR to		An off-path attacker could use the Map-Version bit to force an ETR to
	send Map-Request messages. The attacker could retrieve the current		send Map-Request messages. The attacker could retrieve the current
	source and destination Map-Version for both HA and HB. Based on this		source and destination Map-Version for both HA and HB. Based on this
	information, it could send a spoofed packet with an older Source Map-		information, it could send a spoofed packet with an older Source Map-
	Version or Destination Map-Version. If the size of the Map-Request		Version or Destination Map-Version. If the size of the Map-Request
	message is larger than the size of the smallest LISP-encapsulated		message is larger than the size of the smallest LISP-encapsulated
	packet that could trigger such a message, this could lead to		packet that could trigger such a message, this could lead to
	amplification attacks (see Section 4.4.1) so that more bandwidth is		amplification attacks (see Section 4.4.1) so that more bandwidth is
	consumed on the target than the bandwidth necessary at the attacker		consumed on the target (because of the larger packets) than the
	side.		bandwidth necessary at the attacker side.
	4.3.2.3. Attacks using the Nonce-Present and the Echo-Nonce bits		4.3.2.3. Attacks using the Nonce-Present and the Echo-Nonce bits
	The Nonce-Present and Echo-Nonce bits are used when verifying the		The Nonce-Present and Echo-Nonce bits are used when verifying the
	reachability of a remote ETR. Assume that LR3 wants to verify that		reachability of a remote ETR. Assume that LR3 wants to verify that
	LR1 receives the packets that it sends. LR3 can set the Echo-Nonce		LR1 receives the packets that it sends. LR3 can set the Echo-Nonce
	and the Nonce-Present bits in LISP data encapsulated packets and		and the Nonce-Present bits in LISP data encapsulated packets and
	include a random nonce in these packets. Upon reception of these		include a random nonce in these packets. Upon reception of these
	packets, LR1 will store the nonce sent by LR3 and echo it when it		packets, LR1 will store the nonce sent by LR3 and echo it when it
	returns LISP encapsulated data packets to LR3.		returns LISP encapsulated data packets to LR3.
	skipping to change at page 10, line 32		skipping to change at page 10, line 27
	Echo-Nonce bits both set and the appropriate source and		Echo-Nonce bits both set and the appropriate source and
	destination RLOCs. These packets will force the receiving ETR to		destination RLOCs. These packets will force the receiving ETR to
	store the received nonce and echo it in the LISP encapsulated		store the received nonce and echo it in the LISP encapsulated
	packets that it sends.		packets that it sends.
	The first type of packet should not cause any major problem to ITRs.		The first type of packet should not cause any major problem to ITRs.
	As the reachability test uses a 24 bits nonce, it is unlikely that an		As the reachability test uses a 24 bits nonce, it is unlikely that an
	off-path attacker could send a single packet that causes an ITR to		off-path attacker could send a single packet that causes an ITR to
	believe that the ETR it is testing is reachable while in reality it		believe that the ETR it is testing is reachable while in reality it
	is not reachable. To increase the success likelihood of such attack,		is not reachable. To increase the success likelihood of such attack,
	the attacker should created a massive amount of packets carrying all		the attacker should create a massive amount of packets carrying all
	possible nonce values.		possible nonce values.
	The second type of packet could be exploited to attack the nonce-		The second type of packet could be exploited to attack the nonce-
	based reachability test. Consider a spoofing off-path attacker (SA)		based reachability test. Consider a spoofing off-path attacker (SA)
	that sends a continuous flow of spoofed LISP data encapsulated		that sends a continuous flow of spoofed LISP data encapsulated
	packets that contain the Nonce-Present and the Echo-Nonce bit and		packets that contain the Nonce-Present and the Echo-Nonce bit and
	each packet contains a different random nonce. The ETR that receives		each packet contains a different random nonce. The ETR that receives
	such packets will continuously change the nonce that it returns to		such packets will continuously change the nonce that it returns to
	the remote ITR. If the remote ITR starts a nonce-reachability test,		the remote ITR. If the remote ITR starts a nonce-reachability test,
	this test may fail because the ETR has received a spoofed LISP data		this test may fail because the ETR has received a spoofed LISP data
	skipping to change at page 11, line 10		skipping to change at page 11, line 6
	4.3.2.4. Attacks using the Instance ID bits		4.3.2.4. Attacks using the Instance ID bits
	LISP allows to carry in its header a 24-bits value called "Instance		LISP allows to carry in its header a 24-bits value called "Instance
	ID" and used on the ITR to indicate which local Instance ID has been		ID" and used on the ITR to indicate which local Instance ID has been
	used for encapsulation, while on the ETR can be used to select the		used for encapsulation, while on the ETR can be used to select the
	forwarding table used for forwarding the decapsulated packet.		forwarding table used for forwarding the decapsulated packet.
	The Instance ID increases exposure to attacks ([RFC6169]) as if an		The Instance ID increases exposure to attacks ([RFC6169]) as if an
	off-path attacker can randomly guess a valid Instance ID value to get		off-path attacker can randomly guess a valid Instance ID value to get
	access to network that might not been accessible in normal		access to network that might not been accessible in normal
	conditions. However, the impact of such attack is directly on end-		conditions. However, such attacks target end-systems, which is out
	systems which is is out of the scope of this document.		of the scope of this document.
	4.4. Attacks using the control-plane		4.4. Attacks using the control-plane
	In this section, we discuss the different types of attacks that could		In this section, we discuss the different types of attacks that could
	occur when an off-path attacker sends control-plane packets. We		occur when an off-path attacker sends control-plane packets. We
	focus on the packets that are sent directly to the ETR and do not		focus on the packets that are sent directly to the ETR and do not
	analyze the particularities of the different LISP indexing sub-		analyze the particularities of the different LISP indexing sub-
	system.		system.
	4.4.1. Attacks with Map-Request messages		4.4.1. Attacks with Map-Request messages
	skipping to change at page 11, line 39		skipping to change at page 11, line 35
	The first possible exploitation is the RLOC record P bit. The RLOC		The first possible exploitation is the RLOC record P bit. The RLOC
	record P bit is used to probe the reachability of remote ETRs. In		record P bit is used to probe the reachability of remote ETRs. In
	our reference environment, LR3 could probe the reachability of LR1 by		our reference environment, LR3 could probe the reachability of LR1 by
	sending a Map-Request with the RLOC record P bit set. LR1 would		sending a Map-Request with the RLOC record P bit set. LR1 would
	reply by sending a Map-Reply message with the RLOC record P bit set		reply by sending a Map-Reply message with the RLOC record P bit set
	and the same nonce as in the Map-Request message.		and the same nonce as in the Map-Request message.
	A spoofing off-path attacker (SA) could use the RLOC record P bit to		A spoofing off-path attacker (SA) could use the RLOC record P bit to
	force a victim ETR to send a Map-Reply to the spoofed source address		force a victim ETR to send a Map-Reply to the spoofed source address
	of the Map-Request message. As the Map-Reply can be larger than the		of the Map-Request message. As the Map-Reply can be larger than the
	Map-Request message, there is a risk of amplification attack.		Map-Request message, there is a risk of amplification attack. Map-
	Considering only IPv6 addresses, a Map-Request can be as small as 40		Requests are usually smaller than a hundred bytes while the maximum
	bytes, considering one single ITR address and no Mapping Protocol		size of a Map-Reply (without considering any MTU constrain) can be
	Data. The Map-Reply instead has a proportional to the maximum number		above 1 MB, largely bigger than the message sent by the attacker.
	of RLOCs in a mapping and maximum number of records in a Map-Reply.		These numbers are however theoretical values not considering
	Since up to 255 RLOCs can be associated to an EID-Prefix and 255		transport layer limitations and it is more likely that the reply will
	records can be stored in a Map-Reply, the maximum size of a Map-Reply		contain only one record with at most a dozen of locators, limiting so
	is thus above 1 MB, largely bigger than the message sent by the		the amplification factor.
	attacker. These numbers are however theoretical values not
	considering transport layer limitations and it is more likely that
	the reply will contain only one record with at most a dozen of
	locators, limiting so the amplification factor.
	Similarly, if a non-spoofing off-path attacker (NSA) sends a Map-		Similarly, if a non-spoofing off-path attacker (NSA) sends a Map-
	Request with the RLOC record P bit set, it will receive a Map-Reply		Request with the RLOC record P bit set, it will receive a Map-Reply
	with the RLOC record P bit set.		with the RLOC record P bit set.
	An amplification attack could be launched by a spoofing off-path		An amplification attack could be launched by a spoofing off-path
	attacker (SA) as follows. Consider an attacker SA and EID-Prefix		attacker (SA) as follows. Consider an attacker SA and EID-Prefix
	192.0.2.0/24 and a victim ITR, SA could send spoofed Map-Request		192.0.2.0/24 and a victim ITR, SA could send spoofed Map-Request
	messages whose source EID addresses are all the addresses inside		messages whose source EID addresses are all the addresses inside
	192.0.2.0/24 and source RLOC address is the victim ITR. Upon		192.0.2.0/24 and source RLOC address is the victim ITR. Upon
	reception of these Map-Request messages, the ETR would send large		reception of these Map-Request messages, the ETR would send large
	Map-Reply messages for each of the addresses inside p/P back to the		Map-Reply messages, for each of the addresses back to the victim ITR.
	victim ITR.
	The Map-Request message may also contain the SMR bit. Upon reception		The Map-Request message may also contain the SMR bit. Upon reception
	of a Map-Request message with the SMR bit, an ETR must return to the		of a Map-Request message with the SMR bit, an ETR must return to the
	source of the Map-Request message a Map-Request message to retrieve		source of the Map-Request message a Map-Request message to retrieve
	the corresponding mapping. This raises similar problems as the RLOC		the corresponding mapping. Note that according to [RFC6830] the SMR-
	record P bit discussed above except that as the Map-Request messages		triggered Map-Request might be sent through the mapping system,
	are smaller than Map-Reply messages, the risk of amplification		depending on the number of RLOCs in the locators set. This raises
	attacks is reduced. This is not true anymore if the ETR append to		similar problems as the RLOC record P bit discussed above except that
	the Map-Request messages its own Map-Records. This mechanism is		as the Map-Request messages are smaller than Map-Reply messages, the
	meant to reduce the delay in mapping distribution since mapping		risk of amplification attacks is reduced. This is not true anymore
	information is provided in the Map-Request message.		if the ETR append to the Map-Request messages its own Map-Records.
			This mechanism is meant to reduce the delay in mapping distribution
			since mapping information is provided in the Map-Request message.
	Furthermore, appending Map-Records to Map-Request messages allows an		Furthermore, appending Map-Records to Map-Request messages allows an
	off-path attacker to generate a (spoofed or not) Map-Request message		off-path attacker to generate a (spoofed or not) Map-Request message
	and include in the Map-Reply portion of the message mapping for EID		and include in the Map-Reply portion of the message mapping for EID
	prefixes that it does not serve.		prefixes that it does not serve.
	Moreover, attackers can use Map Resolver and/or Map Server network		Moreover, attackers can use Map Resolver and/or Map Server network
	elements to perform relay attacks. Indeed, on the one hand, a Map		elements to perform relay attacks. Indeed, on the one hand, a Map
	Resolver is used to dispatch Map-Request to the mapping system and,		Resolver is used to dispatch Map-Request to the mapping system and,
	on the other hand, a Map Server is used to dispatch Map-Requests		on the other hand, a Map Server is used to dispatch Map-Requests
	skipping to change at page 14, line 20		skipping to change at page 14, line 10
	register more EID prefixes than necessary to its Map Servers.		register more EID prefixes than necessary to its Map Servers.
	Similarly, a compromised Map Server can accept invalid registration		Similarly, a compromised Map Server can accept invalid registration
	or advertise invalid EID prefix to the indexing sub-system.		or advertise invalid EID prefix to the indexing sub-system.
	4.4.4. Attacks with Map-Notify messages		4.4.4. Attacks with Map-Notify messages
	Map-Notify messages are sent by a Map Server to an ETR to acknowledge		Map-Notify messages are sent by a Map Server to an ETR to acknowledge
	the good reception and processing of a Map-Register message.		the good reception and processing of a Map-Register message.
	An compromised ETR using EID that it is not authoritative for can		A compromised ETR using EID that it is not authoritative for can send
	send a Map-Register with the M-bit set and a spoofed source address		a Map-Register with the M-bit set and a spoofed source address to
	to force the Map Server to send a Map-Notify message to the spoofed		force the Map Server to send a Map-Notify message to the spoofed
	address and then succeed a relay attack. Similarly to the pair Map-		address and then succeed a relay attack. Similarly to the pair Map-
	Request/Map-Reply, the pair Map-Register/Map-Notify is protected by a		Request/Map-Reply, the pair Map-Register/Map-Notify is protected by a
	nonce making it hard for an attacker to inject a falsified		nonce making it hard for an attacker to inject a falsified
	notification to an ETR to make this ETR believe that the registration		notification to an ETR to make this ETR believe that the registration
	succeeded while it has not.		succeeded while it has not.
	5. Attack categories		5. Attack categories
	5.1. Intrusion		5.1. Intrusion
	skipping to change at page 16, line 4		skipping to change at page 15, line 43
	requirement to carry out and eavesdropping attack. Indeed the		requirement to carry out and eavesdropping attack. Indeed the
	attacker might be able, for instance through an intrusion attack on a		attacker might be able, for instance through an intrusion attack on a
	weaker system, either to duplicate or even re-direct the traffic, in		weaker system, either to duplicate or even re-direct the traffic, in
	both cases having access to the raw packets.		both cases having access to the raw packets.
	5.3.2. Vectors		5.3.2. Vectors
	Subversion attacks can be mounted using		Subversion attacks can be mounted using
	o Gleaning		o Gleaning
	o Locator Status Bits		o Locator Status Bits
	o Nonce-Present and the Echo-Nonce bits		o Nonce-Present and the Echo-Nonce bits
	o Map-Request messages		o Map-Request messages
	o Map-Reply messages		o Map-Reply messages
	6. Note on privacy		6. Note on Privacy
	As presented by [RFC6973], universal privacy considerations are		As presented by [RFC6973], universal privacy considerations are
	impossible to establish as the privacy definition may vary from one		impossible to establish as the privacy definition may vary from one
	to another. As a consequence, this document does not aim at		to another. As a consequence, this document does not aim at
	identifying privacy issues related to the LISP protocol but it is		identifying privacy issues related to the LISP protocol but it is
	necessary to highlight that security threats identified in this		necessary to highlight that security threats identified in this
	document could play a role in privacy threats as defined in section 5		document could play a role in privacy threats as defined in section 5
	of [RFC6973].		of [RFC6973].
	7. IANA Considerations		7. IANA Considerations
	skipping to change at page 16, line 39		skipping to change at page 16, line 32
	Separation Protocol and is then a piece of choice to understand the		Separation Protocol and is then a piece of choice to understand the
	security risks at stake while deploying LISP in non-trustable		security risks at stake while deploying LISP in non-trustable
	environment.		environment.
	The purpose of this document is not to provide recommendations to		The purpose of this document is not to provide recommendations to
	protect against attacks, however most of threats can be prevented		protect against attacks, however most of threats can be prevented
	with careful deployment and configuration (e.g., filter) and also by		with careful deployment and configuration (e.g., filter) and also by
	applying the general rules in security that consist in activating		applying the general rules in security that consist in activating
	only features that are necessary in the deployment and verifying the		only features that are necessary in the deployment and verifying the
	validity of the information obtained from third parties. More		validity of the information obtained from third parties. More
	detailed recommendation are given in [book_chapter].		detailed recommendations are given in [Saucez13].
	The control-plane is probably the most critical part of LISP from a		The control-plane is probably the most critical part of LISP from a
	security viewpoint and it is worth to notice that the specifications		security viewpoint and it is worth to notice that the specifications
	already offer authentication mechanism for Map-Register messages		already offer authentication mechanism for Map-Register messages
	([RFC6833]) and that [I-D.ietf-lisp-sec] and [I-D.ietf-lisp-ddt] are		([RFC6833]) and that [I-D.ietf-lisp-sec] and [I-D.ietf-lisp-ddt] are
	clearly going in the direction of a secure control-plane.		clearly going in the direction of a secure control-plane.
	9. Acknowledgments		9. Acknowledgments
	This document builds upon the draft of Marcelo Bagnulo		This document builds upon the draft of Marcelo Bagnulo
	skipping to change at page 17, line 19		skipping to change at page 17, line 8
	reference environment were first described.		reference environment were first described.
	The authors would like to thank Ronald Bonica, Albert Cabellos, Noel		The authors would like to thank Ronald Bonica, Albert Cabellos, Noel
	Chiappa, Florin Coras, Vina Ermagan, Dino Farinacci, Stephen Farrell,		Chiappa, Florin Coras, Vina Ermagan, Dino Farinacci, Stephen Farrell,
	Joel Halpern, Emily Hiltzik, Darrel Lewis, Edward Lopez, Fabio Maino,		Joel Halpern, Emily Hiltzik, Darrel Lewis, Edward Lopez, Fabio Maino,
	Terry Manderson, and Jeff Wheeler for their comments.		Terry Manderson, and Jeff Wheeler for their comments.
	This work has been partially supported by the INFSO-ICT-216372		This work has been partially supported by the INFSO-ICT-216372
	TRILOGY Project (www.trilogy-project.org).		TRILOGY Project (www.trilogy-project.org).
			The work of Luigi Iannone has been partially supported by the ANR-13-
			INFR-0009 LISP-Lab Project (www.lisp-lab.org) and the EIT KIC ICT-
			Labs SOFNETS Project.
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	[RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security		[RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security
	Concerns with IP Tunneling", RFC 6169, April 2011.		Concerns with IP Tunneling", RFC 6169, April 2011.
	[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The		[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
	Locator/ID Separation Protocol (LISP)", RFC 6830, January		Locator/ID Separation Protocol (LISP)", RFC 6830,
	2013.		January 2013.
	[RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,		[RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
	"Interworking between Locator/ID Separation Protocol		"Interworking between Locator/ID Separation Protocol
	(LISP) and Non-LISP Sites", RFC 6832, January 2013.		(LISP) and Non-LISP Sites", RFC 6832, January 2013.
	[RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation		[RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation
	Protocol (LISP) Map-Server Interface", RFC 6833, January		Protocol (LISP) Map-Server Interface", RFC 6833,
	2013.		January 2013.
	[RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID		[RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID
	Separation Protocol (LISP) Map-Versioning", RFC 6834,		Separation Protocol (LISP) Map-Versioning", RFC 6834,
	January 2013.		January 2013.
	[RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis,
	"Locator/ID Separation Protocol Alternative Logical
	Topology (LISP+ALT)", RFC 6836, January 2013.
	[RFC6837] Lear, E., "NERD: A Not-so-novel Endpoint ID (EID) to
	Routing Locator (RLOC) Database", RFC 6837, January 2013.
	[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,		[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
	Morris, J., Hansen, M., and R. Smith, "Privacy		Morris, J., Hansen, M., and R. Smith, "Privacy
	Considerations for Internet Protocols", RFC 6973, July		Considerations for Internet Protocols", RFC 6973,
	2013.		July 2013.
	10.2. Informative References		10.2. Informative References
	[Chu] Jerry Chu, H., "Tuning TCP Parameters for the 21st Century		[Florin13]
	", 75th IETF, Stockholm, July 2009,		Coras, F., Domingo-Pascual, J., Lewis, D., and A.
	<http://tools.ietf.org/wg/savi/>.		Cabellos-Aparicio, "An Analytical Model for Loc/ID
			Mappings Caches", Technical Report. arXiv:1312.1378v2,
			2013, <http://arxiv.org/pdf/1312.1378v2.pdf>.
	[I-D.bagnulo-lisp-threat]		[I-D.bagnulo-lisp-threat]
	Bagnulo, M., "Preliminary LISP Threat Analysis", draft-		Bagnulo, M., "Preliminary LISP Threat Analysis",
	bagnulo-lisp-threat-01 (work in progress), July 2007.		draft-bagnulo-lisp-threat-01 (work in progress),
			July 2007.
	[I-D.ietf-lisp-ddt]		[I-D.ietf-lisp-ddt]
	Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP		Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP
	Delegated Database Tree", draft-ietf-lisp-ddt-01 (work in		Delegated Database Tree", draft-ietf-lisp-ddt-01 (work in
	progress), March 2013.		progress), March 2013.
			[I-D.ietf-lisp-deployment]
			Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo-
			Pascual, J., and D. Lewis, "LISP Network Element
			Deployment Considerations", draft-ietf-lisp-deployment-12
			(work in progress), January 2014.
	[I-D.ietf-lisp-sec]		[I-D.ietf-lisp-sec]
	Maino, F., Ermagan, V., Cabellos-Aparicio, A., Saucez, D.,		Maino, F., Ermagan, V., Cabellos-Aparicio, A., Saucez, D.,
	and O. Bonaventure, "LISP-Security (LISP-SEC)", draft-		and O. Bonaventure, "LISP-Security (LISP-SEC)",
	ietf-lisp-sec-04 (work in progress), October 2012.		draft-ietf-lisp-sec-05 (work in progress), October 2013.
	[I-D.ietf-tcpm-tcp-security]
	Gont, F., "Survey of Security Hardening Methods for
	Transmission Control Protocol (TCP) Implementations",
	draft-ietf-tcpm-tcp-security-03 (work in progress), March
	2012.
	[I-D.meyer-lisp-cons]
	Brim, S., "LISP-CONS: A Content distribution Overlay
	Network Service for LISP", draft-meyer-lisp-cons-04 (work
	in progress), April 2008.
	[I-D.saucez-lisp-mapping-security]
	Saucez, D. and O. Bonaventure, "Securing LISP Mapping
	replies", draft-saucez-lisp-mapping-security-00 (work in
	progress), February 2011.
	[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
	Networks", BCP 84, RFC 3704, March 2004.
	[RFC4301] Kent, S. and K. Seo, "Security Architecture for the		[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
	Internet Protocol", RFC 4301, December 2005.		Internet Protocol", RFC 4301, December 2005.
	[RFC5386] Williams, N. and M. Richardson, "Better-Than-Nothing		[Saucez13]
	Security: An Unauthenticated Mode of IPsec", RFC 5386,
	November 2008.
	[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support
	Secure Internet Routing", RFC 6480, February 2012.
	[SAVI] IETF, "Source Address Validation Improvements Working
	Group ", 2013, <http://tools.ietf.org/wg/savi/>.
	[Saucez09]
	Saucez, D. and L. Iannone, "How to mitigate the effect of
	scans on mapping systems ", Trilogy Summer School on
	Future Internet, 2009.
	[book_chapter]
	Saucez, D., Iannone, L., and O. Bonaventure, "The Map-and-		Saucez, D., Iannone, L., and O. Bonaventure, "The Map-and-
	Encap Locator/Identifier separation paradigm: a Security		Encap Locator/Identifier separation paradigm: a Security
	Analysis ", Solutions for Sustaining Scalability in		Analysis", Solutions for Sustaining Scalability in
	Internet Growth, IGI Global, 2013.		Internet Growth, IGI Global, 2013.
	Appendix A. Document Change Log		Appendix A. Document Change Log
			o Version 09 Posted March 2014.
			* Updated document according to the review of A. Cabellos.
	o Version 08 Posted October 2013.		o Version 08 Posted October 2013.
	* Addition of a privacy consideration note.		* Addition of a privacy consideration note.
	* Editorial changes		* Editorial changes
	o Version 07 Posted October 2013.		o Version 07 Posted October 2013.
	* This version is updated according to the thorough review made		* This version is updated according to the thorough review made
	during October 2013 LISP WG interim meeting.		during October 2013 LISP WG interim meeting.
End of changes. 45 change blocks.
	176 lines changed or deleted		147 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/