draft-ietf-lisp-threats-11.txt		draft-ietf-lisp-threats-12.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: July 3, 2015 Telecom ParisTech		Expires: September 6, 2015 Telecom ParisTech
	O. Bonaventure		O. Bonaventure
	Universite catholique de Louvain		Universite catholique de Louvain
	December 30, 2014		March 5, 2015
	LISP Threats Analysis		LISP Threats Analysis
	draft-ietf-lisp-threats-11.txt		draft-ietf-lisp-threats-12.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).		Separation Protocol (LISP).
	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.
	skipping to change at page 1, line 34		skipping to change at page 1, line 34
	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 July 3, 2015.		This Internet-Draft will expire on September 6, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Threat model . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Threat model . . . . . . . . . . . . . . . . . . . . . . . . 3
	2.1. Attacker's Operation Modes . . . . . . . . . . . . . . . 3		2.1. Attacker's Operation Modes . . . . . . . . . . . . . . . 4
	2.1.1. On-path vs. Off-path Attackers . . . . . . . . . . . 4		2.1.1. On-path vs. Off-path Attackers . . . . . . . . . . . 4
	2.1.2. Internal vs. External Attackers . . . . . . . . . . . 4		2.1.2. Internal vs. External Attackers . . . . . . . . . . . 4
	2.1.3. Live vs. Time-shifted attackers . . . . . . . . . . . 4		2.1.3. Live vs. Time-shifted attackers . . . . . . . . . . . 4
	2.1.4. Control-plane vs. Data-plane attackers . . . . . . . 4		2.1.4. Control-plane vs. Data-plane attackers . . . . . . . 5
	2.1.5. Cross mode attackers . . . . . . . . . . . . . . . . 5		2.1.5. Cross mode attackers . . . . . . . . . . . . . . . . 5
	2.2. Threat categories . . . . . . . . . . . . . . . . . . . . 5		2.2. Threat categories . . . . . . . . . . . . . . . . . . . . 5
	2.2.1. Replay attack . . . . . . . . . . . . . . . . . . . . 5		2.2.1. Replay attack . . . . . . . . . . . . . . . . . . . . 5
	2.2.2. Packet manipulation . . . . . . . . . . . . . . . . . 5		2.2.2. Packet manipulation . . . . . . . . . . . . . . . . . 5
	2.2.3. Packet interception and suppression . . . . . . . . . 5		2.2.3. Packet interception and suppression . . . . . . . . . 6
	2.2.4. Spoofing . . . . . . . . . . . . . . . . . . . . . . 5		2.2.4. Spoofing . . . . . . . . . . . . . . . . . . . . . . 6
	2.2.5. Rogue attack . . . . . . . . . . . . . . . . . . . . 6		2.2.5. Rogue attack . . . . . . . . . . . . . . . . . . . . 7
	2.2.6. Denial of Service (DoS) attack . . . . . . . . . . . 6		2.2.6. Denial of Service (DoS) attack . . . . . . . . . . . 7
	2.2.7. Performance attack . . . . . . . . . . . . . . . . . 7		2.2.7. Performance attack . . . . . . . . . . . . . . . . . 7
	2.2.8. Intrusion attack . . . . . . . . . . . . . . . . . . 7		2.2.8. Intrusion attack . . . . . . . . . . . . . . . . . . 7
	2.2.9. Amplification attack . . . . . . . . . . . . . . . . 7		2.2.9. Amplification attack . . . . . . . . . . . . . . . . 7
	2.2.10. Multi-category attacks . . . . . . . . . . . . . . . 7		2.2.10. Multi-category attacks . . . . . . . . . . . . . . . 7
	3. Attack vectors . . . . . . . . . . . . . . . . . . . . . . . 7		3. Attack vectors . . . . . . . . . . . . . . . . . . . . . . . 7
	3.1. Gleaning . . . . . . . . . . . . . . . . . . . . . . . . 7		3.1. Gleaning . . . . . . . . . . . . . . . . . . . . . . . . 8
	3.2. Locator Status Bits . . . . . . . . . . . . . . . . . . . 9		3.2. Locator Status Bits . . . . . . . . . . . . . . . . . . . 9
	3.3. Map-Version . . . . . . . . . . . . . . . . . . . . . . . 9		3.3. Map-Version . . . . . . . . . . . . . . . . . . . . . . . 10
	3.4. Echo-Nonce . . . . . . . . . . . . . . . . . . . . . . . 10		3.4. Routing Locator Reachability . . . . . . . . . . . . . . 11
	3.5. Instance ID . . . . . . . . . . . . . . . . . . . . . . . 11		3.5. Instance ID . . . . . . . . . . . . . . . . . . . . . . . 12
	3.6. Interworking . . . . . . . . . . . . . . . . . . . . . . 11		3.6. Interworking . . . . . . . . . . . . . . . . . . . . . . 12
	3.7. Map-Request messages . . . . . . . . . . . . . . . . . . 12		3.7. Map-Request messages . . . . . . . . . . . . . . . . . . 12
	3.8. Map-Reply messages . . . . . . . . . . . . . . . . . . . 12		3.8. Map-Reply messages . . . . . . . . . . . . . . . . . . . 13
	3.9. Map-Register messages . . . . . . . . . . . . . . . . . . 14		3.9. Map-Register messages . . . . . . . . . . . . . . . . . . 14
	3.10. Map-Notify messages . . . . . . . . . . . . . . . . . . . 14		3.10. Map-Notify messages . . . . . . . . . . . . . . . . . . . 15
	4. Note on Privacy . . . . . . . . . . . . . . . . . . . . . . . 14		4. Note on Privacy . . . . . . . . . . . . . . . . . . . . . . . 15
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15		5. Threats Mitigation . . . . . . . . . . . . . . . . . . . . . 15
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 15		6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
	7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16		8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
	8.1. Normative References . . . . . . . . . . . . . . . . . . 16		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
	8.2. Informative References . . . . . . . . . . . . . . . . . 16		9.1. Normative References . . . . . . . . . . . . . . . . . . 17
	Appendix A. Document Change Log . . . . . . . . . . . . . . . . 17		9.2. Informative References . . . . . . . . . . . . . . . . . 17
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19		Appendix A. Document Change Log . . . . . . . . . . . . . . . . 18
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
	1. Introduction		1. Introduction
	The Locator/ID Separation Protocol (LISP) is specified in [RFC6830].		The Locator/ID Separation Protocol (LISP) is specified in [RFC6830].
	The present document assess the potential security threats identified		The present document assess the potential security threats identified
	in the LISP specifications if LISP is deployed in the Internet (i.e.,		in the LISP specifications if LISP is deployed in the Internet (i.e.,
	a public non-trustable environment).		a public non-trustable environment).
	The document is composed of three main parts: the first defines the		The document is composed of three main parts: the first defines the
	general threat model that attackers can follow to mount attacks. The		general threat model that attackers can follow to mount attacks. The
	second describing the techniques based on the LISP protocol and		second describes the techniques based on the LISP protocol and
	architecture that attackers can use to construct attacks. The third		architecture that attackers can use to construct attacks. The third
	discussing mitigation techniques and general solutions to protect the		discusses mitigation techniques and general solutions to protect the
	LISP protocol and architecture from attacks.		LISP protocol and architecture from attacks.
	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] and [RFC7215]. The document focuses on LISP		discussed in [RFC6830] and [RFC7215]. The document focuses on LISP
	unicast, including as well LISP Interworking [RFC6832], LISP-MS		unicast, including as well LISP Interworking [RFC6832], LISP-MS
	[RFC6833], and LISP Map-Versioning [RFC6834]. The reading of these		[RFC6833], and LISP Map-Versioning [RFC6834]. The reading of these
	documents is a prerequisite for understanding the present document.		documents is a prerequisite for understanding the present document.
	This document assumes a generic IP service and does not discuss the		This document assumes a generic IP service and does not discuss the
	difference, from a security viewpoint, between using IPv4 or IPv6.		difference, from a security viewpoint, between using IPv4 or IPv6.
	skipping to change at page 4, line 19		skipping to change at page 4, line 24
	entities. On-path attackers are located either directly on the		entities. On-path attackers are located either directly on the
	normal communication path (either by gaining access to a node on the		normal communication path (either by gaining access to a node on the
	path or by placing themselves directly on the path) or outside the		path or by placing themselves directly on the path) or outside the
	location path but manage to deviate (or gain a copy of) packets sent		location path but manage to deviate (or gain a copy of) packets sent
	between the communication entities. On-path attackers hence mount		between the communication entities. On-path attackers hence mount
	their attacks by modifying packets initially sent legitimately		their attacks by modifying packets initially sent legitimately
	between communication entities.		between communication entities.
	An attacker is called off-path attacker if it does not have access to		An attacker is called off-path attacker if it does not have access to
	packets exchanged during the communication or if there is no		packets exchanged during the communication or if there is no
	communication. To succeed their attacks, off-path attackers must		communication. In order for their attacks to succeed, off-path
	hence generate packets and inject them in the network.		attackers must hence generate packets and inject them in the network.
	2.1.2. Internal vs. External Attackers		2.1.2. Internal vs. External Attackers
	An internal attacker launches its attack from a node located within a		An internal attacker launches its attack from a node located within a
	legitimate LISP site. Such an attacker is either a legitimate node		legitimate LISP site. Such an attacker is either a legitimate node
	of the site or it exploits a vulnerability to gain access to a		of the site or it exploits a vulnerability to gain access to a
	legitimate node in the site. Because of their location, internal		legitimate node in the site. Because of their location, internal
	attackers are trusted by the site they are in.		attackers are trusted by the site they are in.
	On the contrary, an external attacker launches its attacks from the		On the contrary, an external attacker launches its attacks from the
	skipping to change at page 7, line 24		skipping to change at page 7, line 35
	(e.g., a host, a router, or a network) or information that it		(e.g., a host, a router, or a network) or information that it
	normally doesn't have access to. Intrusion attacks can lead to		normally doesn't have access to. Intrusion attacks can lead to
	privacy leakages.		privacy leakages.
	2.2.9. Amplification attack		2.2.9. Amplification attack
	In an amplification attack, the traffic generated by the target of		In an amplification attack, the traffic generated by the target of
	the attack in response to the attack is larger than the traffic that		the attack in response to the attack is larger than the traffic that
	the attacker must generate.		the attacker must generate.
			In some cases, the data-plane can be several order of magnitude
			faster than the control-plane at processing packets. This difference
			can be exploited to overload the control-plane via the data-plane
			without overloading the data-plane.
	2.2.10. Multi-category attacks		2.2.10. Multi-category attacks
	Attacks categories are not mutually exclusive and any combination can		Attacks categories are not mutually exclusive and any combination can
	be used to perform specific attacks.		be used to perform specific attacks.
	For example, one can mount a rogue attack to perform a performance		For example, one can mount a rogue attack to perform a performance
	attack starving the memory of an ITR resulting in a DoS on the ITR.		attack starving the memory of an ITR resulting in a DoS on the ITR.
	3. Attack vectors		3. Attack vectors
	This section presents techniques that can be used by attackers to		This section presents techniques that can be used by attackers in
	succeed attacks leveraging the LISP protocol and/or architecture.		order to succeed attacks leveraging the LISP protocol and/or
			architecture.
	3.1. Gleaning		3.1. Gleaning
	To reduce the time required to obtain a mapping, the optional		To reduce the time required to obtain a mapping, the optional
	gleaning mechanism allows an xTR to directly learn a mapping from the		gleaning mechanism allows an xTR to directly learn a mapping from the
	LISP data encapsulated packets and the Map-Request packets that it		LISP data encapsulated packets and the Map-Request packets that it
	receives. LISP encapsulated data packets contain a source RLOC,		receives. LISP encapsulated data packets contain a source RLOC,
	destination RLOC, source EID and destination EID. When an xTR		destination RLOC, source EID and destination EID. When an xTR
	receives an encapsulated data packet coming from a source EID for		receives an encapsulated data packet coming from a source EID for
	which it does not already know a mapping, it may insert the mapping		which it does not already know a mapping, it may insert the mapping
	skipping to change at page 8, line 13		skipping to change at page 8, line 29
	EID from the mapping system.		EID from the mapping system.
	If a packet injected by an off-path attacker and with a spoofed inner		If a packet injected by an off-path attacker and with a spoofed inner
	address is gleaned by an xTR then the attacker may divert the traffic		address is gleaned by an xTR then the attacker may divert the traffic
	meant to be delivered to the spoofed EID as long as the gleaned entry		meant to be delivered to the spoofed EID as long as the gleaned entry
	is used by the xTR. This attack can be used as part of replay,		is used by the xTR. This attack can be used as part of replay,
	packet manipulation, packet interception and suppression, or DoS		packet manipulation, packet interception and suppression, or DoS
	attacks as the packets are sent to the attacker.		attacks as the packets are sent to the attacker.
	If the packet sent by the attacker contains a spoofed outer address		If the packet sent by the attacker contains a spoofed outer address
	instead of a spoofed inner address then it can succeed a DoS or a		instead of a spoofed inner address then it can achieve a DoS or a
	performance attack as the traffic normally destined to the attacker		performance attack as the traffic normally destined to the attacker
	will be redirected to the spoofed source RLOC. Such traffic may		will be redirected to the spoofed source RLOC. Such traffic may
	overload the owner of the spoofed source RLOC, preventing it from		overload the owner of the spoofed source RLOC, preventing it from
	operating properly.		operating properly.
	If the packet injected uses both inner and outer spoofing, the		If the packet injected uses both inner and outer spoofing, the
	attacker can succeed a spoofing, a performance, or an amplification		attacker can achieve a spoofing, a performance, or an amplification
	attack as traffic normally destined to the spoofed EID address will		attack as traffic normally destined to the spoofed EID address will
	be sent to the spoofed RLOC address. If the attacked LISP site also		be sent to the spoofed RLOC address. If the attacked LISP site also
	generates traffic to the spoofed EID address, such traffic may have a		generates traffic to the spoofed EID address, such traffic may have a
	positive amplification factor.		positive amplification factor.
	A gleaning attack does not only impact the data-plane but can also		A gleaning attack does not only impact the data-plane but can also
	have repercussions on the control-plane as a Map-Request is sent		have repercussions on the control-plane as a Map-Request is sent
	after the creation of a gleaned entry. The attacker can then succeed		after the creation of a gleaned entry. The attacker can then achieve
	DoS and performance attacks on the control-plane. For example, if an		DoS and performance attacks on the control-plane. For example, if an
	attacker sends a packet for each address of a prefix not yet cached		attacker sends a packet for each address of a prefix not yet cached
	in the EID-to-RLOC cache of an xTR, the xTR will potentially send a		in the EID-to-RLOC cache of an xTR, the xTR will potentially send a
	Map-Request for each such packet until the mapping is installed which		Map-Request for each such packet until the mapping is installed which
	leads to an over-utilisation of the control-plane as each packet		leads to an over-utilisation of the control-plane as each packet
	generates a control-plane event. For succeeding this example, the		generates a control-plane event. In order for this attack to
	attacker may not need to use spoofing.		succeed, the attacker may not need to use spoofing. This issue can
			occur even if gleaning is turned off since whether or not gleaning is
			used the ITR may need to send a Map-Request in response to incoming
			packets whose EID is not currently in the cache.
	Gleaning attacks are fundamentally involving a time-shifted mode of		Gleaning attacks are fundamentally involving a time-shifted mode of
	operation as the attack may last as long as the gleaned entry is kept		operation as the attack may last as long as the gleaned entry is kept
	by the targeted xTR. RFC 6830 [RFC6830] recommends to store the		by the targeted xTR. RFC 6830 [RFC6830] recommends to store the
	gleaned entries for only a few seconds which limits the duration of		gleaned entries for only a few seconds which limits the duration of
	the attack.		the attack.
	Gleaning attacks always involve external data-plane attackers but		Gleaning attacks always involve external data-plane attackers but
	results in attacks on either the control-plane or data-plane.		results in attacks on either the control-plane or data-plane.
	skipping to change at page 9, line 24		skipping to change at page 9, line 38
	When an attacker sends a LISP encapsulated packet with a crafted LSB		When an attacker sends a LISP encapsulated packet with a crafted LSB
	to an xTR, it can influence the xTR's choice of the locators for the		to an xTR, it can influence the xTR's choice of the locators for the
	prefix associated to the source EID. In case of an off-path		prefix associated to the source EID. In case of an off-path
	attacker, the attacker must inject a forged packet in the network		attacker, the attacker must inject a forged packet in the network
	with a spoofed inner address. An on-path attacker can manipulate the		with a spoofed inner address. An on-path attacker can manipulate the
	LSB of legitimate packets passing through it and hence does not need		LSB of legitimate packets passing through it and hence does not need
	to use spoofing. Instead of manipulating the LSB field, an on-path		to use spoofing. Instead of manipulating the LSB field, an on-path
	attacker can also obtain the same result of injecting packets with		attacker can also obtain the same result of injecting packets with
	invalid LSB values by replaying packets.		invalid LSB values by replaying packets.
	The LSB field can be leveraged to succeed a DoS attack by either		The LSB field can be leveraged to mount a DoS attack by either
	declaring all RLOCs as unreachable (all LSB set to 0), or by		declaring all RLOCs as unreachable (all LSB set to 0), or by
	concentrating all the traffic to one RLOC (e.g., all but one LSB set		concentrating all the traffic to one RLOC (e.g., all but one LSB set
	to 0) and hence overloading the RLOC concentrating all the traffic		to 0) and hence overloading the RLOC concentrating all the traffic
	from the xTR, or by forcing packets to be sent to RLOCs that are		from the xTR, or by forcing packets to be sent to RLOCs that are
	actually not reachable (e.g., invert LSB values).		actually not reachable (e.g., invert LSB values).
	The LSB field can also be used to mount a replay, a packet		The LSB field can also be used to mount a replay, a packet
	manipulation, or a packet interception and suppression attack.		manipulation, or a packet interception and suppression attack.
	Indeed, if the attacker manages to be on the path between the xTR and		Indeed, if the attacker manages to be on the path between the xTR and
	one of the RLOCs specified in the mapping, forcing packets to go via		one of the RLOCs specified in the mapping, forcing packets to go via
	skipping to change at page 10, line 20		skipping to change at page 10, line 37
	Map-Version found in the header of the packet. If the stored		Map-Version found in the header of the packet. If the stored
	mapping is older (i.e., the Map-Version is smaller) than the		mapping is older (i.e., the Map-Version is smaller) than the
	source version of the LISP encapsulated packet, the xTR should		source version of the LISP encapsulated packet, the xTR should
	send a Map-Request for the source EID.		send a Map-Request for the source EID.
	A cross-mode attacker can use the Map-Version bit to mount a DoS		A cross-mode attacker can use the Map-Version bit to mount a DoS
	attack, an amplification attack, or a spoofing attack. For instance		attack, an amplification attack, or a spoofing attack. For instance
	if the mapping cached at the xTR is outdated, the xTR will send a		if the mapping cached at the xTR is outdated, the xTR will send a
	Map-Request to retrieve the new mapping which can yield to a DoS		Map-Request to retrieve the new mapping which can yield to a DoS
	attack (by excess of signalling traffic) or an amplification attack		attack (by excess of signalling traffic) or an amplification attack
	if the data-plane packet sent by the attacker is smaller than the		if the data-plane packet sent by the attacker is smaller, or
	control-plane packets sent in response to the attacker's packet.		otherwise uses fewer resources, than the control-plane packets sent
	With a spoofing attack and if the xTR considers that the spoofed ITR		in response to the attacker's packet. With a spoofing attack and if
	has an outdated mapping, it will send an SMR to the spoofed ITR which		the xTR considers that the spoofed ITR has an outdated mapping, it
	can result in performance, amplification, or DoS attack as well.		will send an SMR to the spoofed ITR which can result in performance,
			amplification, or DoS attack as well.
	Map-Version attackers are inherently cross mode as the Map-Version is		Map-Version attackers are inherently cross mode as the Map-Version is
	a method to put control information in the data-plane. Moreover,		a method to put control information in the data-plane. Moreover,
	this vector involves live attackers. Nevertheless, on-path attackers		this vector involves live attackers. Nevertheless, on-path attackers
	do not take specific advantage over off-path attackers.		do not take specific advantage over off-path attackers.
	3.4. Echo-Nonce		3.4. Routing Locator Reachability
	The Nonce-Present and Echo-Nonce bits in the LISP header are used to		The Nonce-Present and Echo-Nonce bits in the LISP header are used to
	verify the reachability of an xTR. A testing xTR sets the Echo-Nonce		verify the reachability of an xTR. A testing xTR sets 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 the LISP header of packets. Upon reception		include a random nonce in the LISP header of packets. Upon reception
	of these packets, the tested xTR stores the nonce and echo it		of these packets, the tested xTR stores the nonce and echo it
	whenever it returns a LISP encapsulated data packets to the testing		whenever it returns a LISP encapsulated data packets to the testing
	xTR. The reception of the echoed nonce confirms that the tested xTR		xTR. The reception of the echoed nonce confirms that the tested xTR
	is reachable.		is reachable.
	skipping to change at page 11, line 25		skipping to change at page 11, line 47
	receives such packets will continuously change the nonce that it		receives such packets will continuously change the nonce that it
	returns to the remote ITR, which can yield to a performance attack.		returns to the remote ITR, which can yield to a performance attack.
	If the remote ITR tries a nonce-reachability test, this test may fail		If the remote ITR tries a nonce-reachability test, this test may fail
	because the ETR may echo an invalid nonce. This hence yields to a		because the ETR may echo an invalid nonce. This hence yields to a
	DoS attack.		DoS attack.
	In the case of an on-path attacker, a packet manipulation attack is		In the case of an on-path attacker, a packet manipulation attack is
	necessary to mount the attack. To mount such an attack, an off-path		necessary to mount the attack. To mount such an attack, an off-path
	attacker must mount an outer address spoofing attack.		attacker must mount an outer address spoofing attack.
			If an xTR chooses to periodically check with active probes the
			liveness of entries in its EID-to-RLOC cache (as described in section
			6.3 of [RFC6830]), then this may amplify the attack that caused the
			insertion of entries being checked.
	3.5. Instance ID		3.5. Instance ID
	LISP allows to carry in its header a 24-bits value called Instance ID		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 used		and used on the ITR to indicate which local Instance ID has been used
	for encapsulation, while on the ETR the instance ID decides the		for encapsulation, while on the ETR the instance ID decides the
	forwarding table to use to forward the decapsulated packet in the		forwarding table to use to forward the decapsulated packet in the
	LISP site.		LISP site.
	An attacker (either a control-plane or data-plane attacker) can use		An attacker (either a control-plane or data-plane attacker) can use
	the instance ID functionality to mount an intrusion attack.		the instance ID functionality to mount an intrusion attack.
	skipping to change at page 12, line 36		skipping to change at page 13, line 13
	messages. When an xTR receives a Map-Request with appended Map-		messages. When an xTR receives a Map-Request with appended Map-
	Records, it does the same operations as for the other Map-Request		Records, it does the same operations as for the other Map-Request
	messages and is so subject to the same attacks. However, it also		messages and is so subject to the same attacks. However, it also
	installs in its EID-to-RLOC cache the Map-Records contained in the		installs in its EID-to-RLOC cache the Map-Records contained in the
	Map-Request. An attacker can then use this vector to force the		Map-Request. An attacker can then use this vector to force the
	installation of mappings in its target xTR. Consequently, the EID-		installation of mappings in its target xTR. Consequently, the EID-
	to-RLOC cache of the xTR is polluted by potentially forged mappings		to-RLOC cache of the xTR is polluted by potentially forged mappings
	allowing the attacker to mount any of the attacks categorized in		allowing the attacker to mount any of the attacks categorized in
	Section 2.2 (see Section 3.8 for more details). It is worth to		Section 2.2 (see Section 3.8 for more details). It is worth to
	mention that the attacker does not need to forge the mappings present		mention that the attacker does not need to forge the mappings present
	in the Map-Request to succeed a performance or DoS attack. Indeed,		in the Map-Request to achieve a performance or DoS attack. Indeed,
	if the attacker owns a large enough EID prefix it can de-aggregate it		if the attacker owns a large enough EID prefix it can de-aggregate it
	in many small prefixes, each corresponding to another mapping and it		in many small prefixes, each corresponding to another mapping and it
	installs them in the xTR cache by mean of the Map-Request.		installs them in the xTR cache by mean of the Map-Request.
	Moreover, attackers can use Map Resolver and/or Map Server network		Moreover, attackers can use Map Resolver and/or Map Server network
	elements to relay its attacks and hide the origin of the attack.		elements to relay its attacks and hide the origin of the attack.
	Indeed, on the one hand, a Map Resolver is used to dispatch Map-		Indeed, on the one hand, a Map Resolver is used to dispatch Map-
	Request to the mapping system and, on the other hand, a Map Server is		Request to the mapping system and, on the other hand, a Map Server is
	used to dispatch Map-Requests coming from the mapping system to ETRs		used to dispatch Map-Requests coming from the mapping system to ETRs
	that are authoritative for the EID in the Map-Request.		that are authoritative for the EID in the Map-Request.
	3.8. Map-Reply messages		3.8. Map-Reply messages
	Most of the security of the Map-Reply messages depends on the 64 bits		Most of the security of the Map-Reply messages depends on the 64 bits
	nonce that is included in a Map-Request and returned in the Map-		nonce that is included in a Map-Request and returned in the Map-
	Reply. If an ETR does not accept Map-Reply messages with an invalid		Reply. If an ETR does not accept Map-Reply messages with an invalid
	nonce, the risk of attack is limited given the size of the nonce (64		nonce, the risk of an off-path attack is limited given the size of
	bits). Nevertheless, the nonce only confirms that the Map-Reply		the nonce (64 bits). Nevertheless, the nonce only confirms that the
	received was sent in response to a Map-Request sent, it does not		Map-Reply received was sent in response to a Map-Request sent, it
	validate the contents of that Map-Reply.		does not validate the contents of that Map-Reply.
	If an attacker manages to send a valid (i.e., in response to a Map-		If an attacker manages to send a valid (i.e., in response to a Map-
	Request and with the correct nonce) Map-Reply to an ITR, then it can		Request and with the correct nonce) Map-Reply to an ITR, then it can
	perform any of the attack categorised in Section 2.2 as it can inject		perform any of the attack categorised in Section 2.2 as it can inject
	forged mappings directly in the ITR EID-to-RLOC cache. For instance,		forged mappings directly in the ITR EID-to-RLOC cache. For instance,
	if the mapping injected to the ITR points to the address of a node		if the mapping injected to the ITR points to the address of a node
	controlled by the attacker, it can mount replay, packet manipulation,		controlled by the attacker, it can mount replay, packet manipulation,
	packet interception and suppression, or DoS attacks as it will		packet interception and suppression, or DoS attacks as it will
	receive every packet destined to a destination lying in the EID		receive every packet destined to a destination lying in the EID
	prefix of the injected mapping. In addition, the attacker can inject		prefix of the injected mapping. In addition, the attacker can inject
	skipping to change at page 13, line 47		skipping to change at page 14, line 25
	force its target ITR to send a Map-Request, nothing prevents the		force its target ITR to send a Map-Request, nothing prevents the
	attacker to initiate some communication with the ITR. This method		attacker to initiate some communication with the ITR. This method
	can be used by internal attackers that want to control the mappings		can be used by internal attackers that want to control the mappings
	installed in their site. To that aim, they simply have to collude		installed in their site. To that aim, they simply have to collude
	with an external attacker ready to over-claim prefixes on behalf of		with an external attacker ready to over-claim prefixes on behalf of
	the internal attacker.		the internal attacker.
	It is worth to notice that when the Map-Reply is in response to a		It is worth to notice that when the Map-Reply is in response to a
	Map-Request sent via the mapping system (i.e., not send directly from		Map-Request sent via the mapping system (i.e., not send directly from
	the ITR to an ETR), the attacker does not need to use a spoofing		the ITR to an ETR), the attacker does not need to use a spoofing
	attack to succeed its attack as by design the source IP address of a		attack to achieve its attack as by design the source IP address of a
	Map-Reply is not known in advance by the ITR.		Map-Reply is not known in advance by the ITR.
	Map-Request and Map-Reply messages are exposed to any type of		Map-Request and Map-Reply messages are exposed to any type of
	attackers, on-path or off-path but also external or internal		attackers, on-path or off-path but also external or internal
	attackers. Also, even though they are control message, they can be		attackers. Also, even though they are control message, they can be
	leveraged by data-plane attackers. As the decision of removing		leveraged by data-plane attackers. As the decision of removing
	mappings is based on the TTL indicated in the mapping, time-shifted		mappings is based on the TTL indicated in the mapping, time-shifted
	attackers can take benefit of injecting forged mappings as well.		attackers can take benefit of injecting forged mappings as well.
	3.9. Map-Register messages		3.9. Map-Register messages
	skipping to change at page 15, line 5		skipping to change at page 15, line 30
	4. Note on Privacy		4. 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].
	Note, however, that like public deployments of any other control		Like public deployments of any other control plane protocols, in an
	plane protocol, in an Internet deployment mappings are public and		Internet deployment mappings are public and hence provide information
	hence provide information about the infrastructure and reachability		about the infrastructure and reachability of LISP sites (i.e., the
	of LISP sites (i.e., the addresses of the edge routers).		addresses of the edge routers). Depending upon deployment details,
			LISP map replies might or might not provide finer grained and more
			detailed information than is available with currently deployed
			routing and control protocols.
	5. IANA Considerations		5. Threats Mitigation
	This document makes no request to IANA.		Most of threats can be mitigated with careful deployment and
			configuration (e.g., filter) and also by applying the general rules
			in security that consist in activating only features that are
			necessary in the deployment and verifying the validity of the
			information obtained from third parties.
			The control-plane is the most critical part of LISP from a security
			viewpoint and it is worth to notice that the specifications already
			offer authentication mechanism for mappings registration ([RFC6833])
			and this mechanism combined with LISP-SEC [I-D.ietf-lisp-sec]
			strongly mitigates threats in non-trustable environments such as the
			Internet. Moreover, LISP specifications define an authentication
			data field for Map-Request messages and Encapsulated Control messages
			without specifying how to use it [RFC6830]. The presence of this
			field in the specifications allows to propose a general
			authentication mechanisms for the LISP control-plane while staying
			backward compatible. The exact technique still has to be designed
			and defined. To maximally mitigate the threats on the mapping
			system, authentication must be used, whenever possible, for both Map-
			Request and Map-Reply messages and for messages exchanged internally
			among elements of the mapping system, such as specified in
			[I-D.ietf-lisp-sec] and [I-D.ietf-lisp-ddt].
			Systematically applying filters and rate-limitation, as proposed in
			[RFC6830], mitigates most of the threats presented in this document.
			In order to minimise the risk of overloading the control-plane with
			actions triggered from data-plane events, such actions should be rate
			limited.
			Finally, all information opportunistically learned (e.g., with LSB or
			gleaning) should be used with care until they are verified. For
			instance, a reachability change learned with LSB should not be used
			directly to decide the destination RLOC, but instead should trigger a
			rate-limited reachability test. Similarly, a gleaned entry should be
			used only for the flow that triggered the gleaning procedure until
			the gleaned entry has been verified [Trilogy].
	6. Security Considerations		6. Security Considerations
	This document is devoted to threat analysis of the Locator/Identifier		This entire document is dedicated to threat analysis and mitigation
	Separation Protocol and is then a piece of choice to understand the		of the Locator/Identifier Separation Protocol, aiming at helping to
	security risks at stake while deploying LISP in non-trustable		understand the security risks at stake, and how to mitigate them,
	environment.		while deploying LISP in non-trustable environments.
	The purpose of this document is not to provide recommendations to		7. IANA Considerations
	protect against attacks, however most of threats can be prevented
	with careful deployment and configuration (e.g., filter) and also by
	applying the general rules in security that consist in activating
	only features that are necessary in the deployment and verifying the
	validity of the information obtained from third parties. More
	detailed recommendations are given in [Saucez13].
	The control-plane is probably the most critical part of LISP from a		This document makes no request to IANA.
	security viewpoint and it is worth to notice that the specifications
	already offer authentication mechanism for Map-Register messages
	([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.
	7. Acknowledgments		8. Acknowledgments
	This document builds upon the draft of Marcelo Bagnulo		This document builds upon the draft of Marcelo Bagnulo
	([I-D.bagnulo-lisp-threat]), where the flooding attack and the		([I-D.bagnulo-lisp-threat]), where the flooding attack and the
	reference environment were first described.		reference environment were first described.
	The authors would like to thank Ronald Bonica, Albert Cabellos, Ross		The authors would like to thank Ronald Bonica, Albert Cabellos, Ross
	Callon, Noel Chiappa, Florin Coras, Vina Ermagan, Dino Farinacci,		Callon, Noel Chiappa, Florin Coras, Vina Ermagan, Dino Farinacci,
	Stephen Farrell, Joel Halpern, Emily Hiltzik, Darrel Lewis, Edward		Stephen Farrell, Joel Halpern, Emily Hiltzik, Darrel Lewis, Edward
	Lopez, Fabio Maino, Terry Manderson, and Jeff Wheeler for their		Lopez, Fabio Maino, Terry Manderson, and Jeff Wheeler for their
	comments.		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-		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-		13-INFR-0009 LISP-Lab Project (www.lisp-lab.org) and the EIT KIC ICT-
	Labs SOFNETS Project.		Labs SOFNETS Project.
	8. References		9. References
	8.1. Normative References		9.1. Normative References
	[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, January
	2013.		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
	skipping to change at page 16, line 30		skipping to change at page 17, line 37
	[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.
	[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, July
	2013.		2013.
	8.2. Informative References		9.2. Informative References
	[I-D.bagnulo-lisp-threat]		[I-D.bagnulo-lisp-threat]
	Bagnulo, M., "Preliminary LISP Threat Analysis", draft-		Bagnulo, M., "Preliminary LISP Threat Analysis", draft-
	bagnulo-lisp-threat-01 (work in progress), July 2007.		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-02 (work in		Delegated Database Tree", draft-ietf-lisp-ddt-02 (work in
	progress), October 2014.		progress), October 2014.
	[I-D.ietf-lisp-sec]		[I-D.ietf-lisp-sec]
	Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D.		Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D.
	Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-07		Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-07
	(work in progress), October 2014.		(work in progress), October 2014.
	[RFC7215] Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo-		[RFC7215] Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo-
	Pascual, J., and D. Lewis, "Locator/Identifier Separation		Pascual, J., and D. Lewis, "Locator/Identifier Separation
	Protocol (LISP) Network Element Deployment		Protocol (LISP) Network Element Deployment
	Considerations", RFC 7215, April 2014.		Considerations", RFC 7215, April 2014.
	[Saucez13]		[Trilogy] Saucez, D. and L. Iannone, "How to mitigate the effect of
	Saucez, D., Iannone, L., and O. Bonaventure, "The Map-and-		scans on mapping systems", Trilogy Future Internet Summer
	Encap Locator/Identifier separation paradigm: a Security		School., 2009.
	Analysis", Solutions for Sustaining Scalability in
	Internet Growth, IGI Global, 2013.
	Appendix A. Document Change Log		Appendix A. Document Change Log
			o Version 12 Posted March 2015.
			* Addressed comments by Ross Callon on the mailing list
			(http://www.ietf.org/mail-archive/web/lisp/current/
			msg05829.html).
			* Addition of a section discussing mitigation techniques for
			deployments in non-trustable environments.
	o Version 11 Posted December 2014.		o Version 11 Posted December 2014.
	* Editorial polishing. Clarifications added in few points.		* Editorial polishing. Clarifications added in few points.
	o Version 10 Posted July 2014.		o Version 10 Posted July 2014.
	* Document completely remodeled according to the discussions on		* Document completely remodeled according to the discussions on
	the mailing list in the thread http://www.ietf.org/mail-		the mailing list in the thread http://www.ietf.org/mail-
	archive/web/lisp/current/msg05206.html and to address comments		archive/web/lisp/current/msg05206.html and to address comments
	from Ronald Bonica and Ross Callon.		from Ronald Bonica and Ross Callon.
End of changes. 40 change blocks.
	82 lines changed or deleted		133 lines changed or added
This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/