draft-ietf-lisp-threats-00.txt		draft-ietf-lisp-threats-01.txt
	Network Working Group D. Saucez		Network Working Group D. Saucez
	Internet-Draft Universite catholique de Louvain		Internet-Draft INRIA
	Intended status: Informational L. Iannone		Intended status: Informational L. Iannone
	Expires: January 3, 2012 Deutsche Telekom Laboratories AG		Expires: September 2, 2012 Telekom Innovation Laboratories
	O. Bonaventure		O. Bonaventure
	Universite catholique de Louvain		Universite catholique de Louvain
	July 2, 2011		March 1, 2012
	LISP Threats Analysis		LISP Threats Analysis
	draft-ietf-lisp-threats-00.txt		draft-ietf-lisp-threats-01.txt
	Abstract		Abstract
	This document analyzes the threats against the security of the		This document analyzes the threats against the security of the
	Locator/Identifier Separation Protocol and proposes a set of		Locator/Identifier Separation Protocol and proposes a set of
	recommendations to mitigate some of the identified security risks.		recommendations to mitigate some of the identified security risks.
	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
	skipping to change at page 1, line 35		skipping to change at page 1, line 35
	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 January 3, 2012.		This Internet-Draft will expire on September 2, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2012 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
	skipping to change at page 2, line 28		skipping to change at page 2, line 28
	6.3. Attacks not leveraging on the LISP header . . . . . . . . 9		6.3. Attacks not leveraging on the LISP header . . . . . . . . 9
	6.4. Attacks leveraging on the LISP header . . . . . . . . . . 10		6.4. Attacks leveraging on the LISP header . . . . . . . . . . 10
	6.4.1. Attacks using the Locator Status Bits . . . . . . . . 10		6.4.1. Attacks using the Locator Status Bits . . . . . . . . 10
	6.4.2. Attacks using the Map-Version bit . . . . . . . . . . 11		6.4.2. Attacks using the Map-Version bit . . . . . . . . . . 11
	6.4.3. Attacks using the Nonce-Present and the Echo-Nonce		6.4.3. Attacks using the Nonce-Present and the Echo-Nonce
	bits . . . . . . . . . . . . . . . . . . . . . . . . . 12		bits . . . . . . . . . . . . . . . . . . . . . . . . . 12
	6.4.4. Attacks using the ID Instance bits . . . . . . . . . . 13		6.4.4. Attacks using the ID Instance bits . . . . . . . . . . 13
	7. Control Plane Threats . . . . . . . . . . . . . . . . . . . . 13		7. Control Plane Threats . . . . . . . . . . . . . . . . . . . . 13
	7.1. Attacks with Map-Request messages . . . . . . . . . . . . 13		7.1. Attacks with Map-Request messages . . . . . . . . . . . . 13
	7.2. Attacks with Map-Reply messages . . . . . . . . . . . . . 15		7.2. Attacks with Map-Reply messages . . . . . . . . . . . . . 15
	7.3. Gleaning Attacks . . . . . . . . . . . . . . . . . . . . . 15		7.3. Gleaning Attacks . . . . . . . . . . . . . . . . . . . . . 16
	8. Threats concerning Interworking . . . . . . . . . . . . . . . 17		8. Threats concerning Interworking . . . . . . . . . . . . . . . 17
	9. Threats with Malicious xTRs . . . . . . . . . . . . . . . . . 18		9. Threats with Malicious xTRs . . . . . . . . . . . . . . . . . 18
	10. Security of the ALT Mapping System . . . . . . . . . . . . . . 20		10. Security of the Proposed Mapping Systems . . . . . . . . . . . 20
	11. Threats concerning LISP-MS . . . . . . . . . . . . . . . . . . 21		10.1. LISP+ALT . . . . . . . . . . . . . . . . . . . . . . . . . 21
	11.1. Map Server . . . . . . . . . . . . . . . . . . . . . . . . 21		10.2. LISP-DDT . . . . . . . . . . . . . . . . . . . . . . . . . 22
	11.2. Map-Resolver . . . . . . . . . . . . . . . . . . . . . . . 22		11. Threats concerning LISP-MS . . . . . . . . . . . . . . . . . . 22
	12. Suggested Recommendations . . . . . . . . . . . . . . . . . . 23		11.1. Map Server . . . . . . . . . . . . . . . . . . . . . . . . 23
	13. Document Status and Plans . . . . . . . . . . . . . . . . . . 25		11.2. Map-Resolver . . . . . . . . . . . . . . . . . . . . . . . 24
	14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26		12. Suggested Recommendations . . . . . . . . . . . . . . . . . . 25
	15. Security Considerations . . . . . . . . . . . . . . . . . . . 26		13. Document Status and Plans . . . . . . . . . . . . . . . . . . 27
	16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26		14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
	17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26		15. Security Considerations . . . . . . . . . . . . . . . . . . . 28
	17.1. Normative References . . . . . . . . . . . . . . . . . . . 26		16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28
	17.2. Informative References . . . . . . . . . . . . . . . . . . 27		17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
	Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 28		17.1. Normative References . . . . . . . . . . . . . . . . . . . 28
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28		17.2. Informative References . . . . . . . . . . . . . . . . . . 29
			Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 30
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
	1. Requirements notation		1. Requirements notation
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	2. Introduction		2. Introduction
	The Locator/ID Separation Protocol (LISP) is defined in		The Locator/ID Separation Protocol (LISP) is defined in
	skipping to change at page 13, line 32		skipping to change at page 13, line 32
	routing table identified by the attacked Instance ID, however, end-		routing table identified by the attacked Instance ID, however, end-
	system security is out of the scope of this document. Nevertheless,		system security is out of the scope of this document. Nevertheless,
	access lists can be configured to protect the network from Instance		access lists can be configured to protect the network from Instance
	ID based attacks.		ID based attacks.
	7. Control Plane Threats		7. Control Plane Threats
	In this section, we discuss the different types of attacks that can		In this section, we discuss the different types of attacks that can
	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 a LISP mapping system. The ALT		analyze the particularities of a LISP mapping system. The LISP+ALT
	mapping system is discussed in Section 10.		and LISP-DDT mapping systems are discussed in Section 10.
	7.1. Attacks with Map-Request messages		7.1. Attacks with Map-Request messages
	An off-path attacker could send Map-Request packets to a victim ETR.		An off-path attacker could send Map-Request packets to a victim ETR.
	In theory, a Map-Request packet is only used to solicit an answer and		In theory, a Map-Request packet is only used to solicit an answer and
	as such it should not lead to security problems. However, the LISP		as such it should not lead to security problems. However, the LISP
	specification [I-D.ietf-lisp] contains several particularities that		specification [I-D.ietf-lisp] contains several particularities that
	could be exploited by an off-path attacker.		could be exploited by an off-path attacker.
	The first possible exploitation is the P bit. The P bit is used to		The first possible exploitation is the P bit. The P bit is used to
	skipping to change at page 15, line 36		skipping to change at page 15, line 36
	Prefix with an empty locator-set and specifying an action,		Prefix with an empty locator-set and specifying an action,
	which may be either Drop, Natively forward, or Send Map-		which may be either Drop, Natively forward, or Send Map-
	Request.		Request.
	Positive Map-Reply messages are used to map EID-Prefixes onto RLOCs.		Positive Map-Reply messages are used to map EID-Prefixes onto RLOCs.
	Negative Map-Reply messages are used to support PTR and interconnect		Negative Map-Reply messages are used to support PTR and interconnect
	the LISP Internet with the legacy Internet.		the LISP Internet with the legacy Internet.
	Most of the security of the Map-Reply messages depend on the 64 bits		Most of the security of the Map-Reply messages depend 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. An ETR must never accept a Map-Request message whose nonce		Reply. An ETR must never accept a Map-Reply message whose nonce does
	does not match one of the pending Map-Request messages. If an ETR		not match one of the pending Map-Request messages. If an ETR does
	does not accept Map-Reply messages with an invalid nonce, the risk of		not accept Map-Reply messages with an invalid nonce, the risk of
	attack is very small given the size of the nonce (64 bits).		attack is acceptable given the size of the nonce (64 bits).
	Note, however, that the nonce only confirms that the Map-Reply was		Note, however, that the nonce only confirms that the Map-Reply was
	sent by the ETR that received the Map-Request. It does not validate		sent by the ETR that received the Map-Request. It does not validate
	the content of the Map-Reply message.		the content of the Map-Reply message.
			In addition, an attacker can perform EID-to-RLOC Cache overflow
			attack by de-aggregating (i.e., splitting an EID prefix into
			artificially smaller EID prefixes) either positive or negative
			mappings.
	7.3. Gleaning Attacks		7.3. Gleaning Attacks
	A third type of attack involves the gleaning mechanism proposed in		A third type of attack involves the gleaning mechanism proposed in
	[I-D.ietf-lisp] and discussed in [Saucez09]. In order to reduce the		[I-D.ietf-lisp] and discussed in [Saucez09]. In order to reduce the
	time required to obtain a mapping, [I-D.ietf-lisp] allows an ITR to		time required to obtain a mapping, [I-D.ietf-lisp] allows an ITR to
	learn a mapping from the LISP data encapsulated packets and the Map-		learn a mapping from the LISP data encapsulated packets and the Map-
	Request packets that it receives. LISP data encapsulated packet		Request packets that it receives. LISP data encapsulated packet
	contains a source RLOC, destination RLOC, source EID and destination		contains a source RLOC, destination RLOC, source EID and destination
	EID. When a ITR receives a data encapsulated packet coming from a		EID. When a ITR receives a data encapsulated packet coming from a
	source EID for which it does not already know a mapping, it may		source EID for which it does not already know a mapping, it may
	skipping to change at page 20, line 9		skipping to change at page 20, line 46
	relies on the received mapping and possible reachability information		relies on the received mapping and possible reachability information
	to select the RLOC of the ETR that it uses to reach a given EID or		to select the RLOC of the ETR that it uses to reach a given EID or
	block of EIDs. However, if the ITR made a mistake, e.g., due to		block of EIDs. However, if the ITR made a mistake, e.g., due to
	configuration, implementation or other types of errors and has chosen		configuration, implementation or other types of errors and has chosen
	a RLOC that does not serve the destination EID, there is no easy way		a RLOC that does not serve the destination EID, there is no easy way
	for the LISP ETR to inform the ITR of its mistake. A possible		for the LISP ETR to inform the ITR of its mistake. A possible
	solution could be to force a ETR to perform a reachability test with		solution could be to force a ETR to perform a reachability test with
	the selected ITR as soon as it selects it. This will be analyzed in		the selected ITR as soon as it selects it. This will be analyzed in
	the next version of this document.		the next version of this document.
	10. Security of the ALT Mapping System		10. Security of the Proposed Mapping Systems
			10.1. LISP+ALT
	One of the assumptions in [I-D.ietf-lisp] is that the mapping system		One of the assumptions in [I-D.ietf-lisp] is that the mapping system
	is more secure than sending Map-Request and Map-Reply messages		is more secure than sending Map-Request and Map-Reply messages
	directly. We analyze this assumption in this section by analyzing		directly. We analyze this assumption in this section by analyzing
	the security of the ALT mapping system.		the security of the ALT mapping system.
	The ALT mapping system is basically a manually configured overlay of		The ALT mapping system is basically a manually configured overlay of
	GRE tunnels between ALT routers. BGP sessions are established		GRE tunnels between ALT routers. BGP sessions are established
	between ALT routers that are connected through such a tunnel. An ALT		between ALT routers that are connected through such a tunnel. An ALT
	router advertises the EID prefixes that it serves over its BGP		router advertises the EID prefixes that it serves over its BGP
	skipping to change at page 21, line 11		skipping to change at page 22, line 5
	advertisements and also answer to received Map-Requests without		advertisements and also answer to received Map-Requests without
	forwarding them to their final destination on the overlay. This		forwarding them to their final destination on the overlay. This
	could lead to various types of redirection attacks. Note that in		could lead to various types of redirection attacks. Note that in
	contrast with a regular IP router that could also manipulate in		contrast with a regular IP router that could also manipulate in
	transit packets, when a malicious or compromised ALT router replies		transit packets, when a malicious or compromised ALT router replies
	to a Map-Request, it can redirect legitimate traffic for a long		to a Map-Request, it can redirect legitimate traffic for a long
	period of time by sending an invalid Map-Reply message. Thus, the		period of time by sending an invalid Map-Reply message. Thus, the
	impact of a malicious ALT router could be much more severe than a		impact of a malicious ALT router could be much more severe than a
	malicious router in today's Internet.		malicious router in today's Internet.
			10.2. LISP-DDT
			The LISP Delegated Database Tree (LISP-DDT) mapping system is
			proposed as an alternative for LISP+ALT [I-D.fuller-lisp-ddt]. LISP-
			DDT is a hierarchical distributed database for EID-to-RLOC mappings.
			Each DDT node is configured with an EID prefix it owns, as well as
			the RLOC addresses and EID prefixes of the LISP-DDT nodes that own a
			more specific EID prefix than the one it owns. In LISP-DDT, mappings
			are retrieved iteratively. A MR that needs to locate a mapping
			traverses the tree of DDT nodes contacting them one after another
			until the leaf of the DDT tree that owns the longest matching EID
			prefix for the mapping's EID is reached. The MR traverses the
			hierarchy of LISP-DDT nodes by sending Map-Requests, with the LISP-
			DDT-originated bit set, to LISP-DDT nodes. The MR first contacts the
			root of the hierarchy. When a LISP-DDT node receives a Map-Request,
			it replies the MR with a Map-Referral that contains the list of the
			locators of its childrens that own a prefix that covers the EID in
			the Map-Request. The MR then contacts one of these childrens that
			will return, at its turn, a Map-Referral. This procedure is
			iteratively executed until a Map-Referral marked with the done flag
			is received. The locators that appear in a referral with the done
			flag are those of the authoritative ETRs for the EID in the Map-
			Request. At that moment, the MR falls back to its normal behavior
			and sends a Map-Request to the ETR in order for the ITR to obtain the
			mapping. It is worth noticing that the MR can cache the referrals to
			avoid traversing all the whole hierarchy for every mapping
			retrievals.
			The operation in LISP-DDT is different from ALT and thus it does not
			present the same threats as LISP+ALT. However, threats exist for
			LISP-DDT as well. First, a DoS attack can be performed on the MR by
			asking her to retrieve a large amount of mappings at the same time.
			Indeed, the iterative operation of the MR implies that it has to
			maintain state about the ITR that requested the mapping, this in
			order to send the final Map-Request to the ETR on behalf of the ITR.
			An attacker might leverage on this to fill the MR memory and then
			cause a DoS on the MR.
			If an attacker manages to compromise a LISP-DDT node it can send fake
			referrals to the MR and then control the mappings delivered to the
			ITRs. Furthermore, the effects of such an attack can be longer than
			the attack itself if the MR caches the referrals.
	11. Threats concerning LISP-MS		11. Threats concerning LISP-MS
	LISP-MS ([I-D.ietf-lisp-ms] specifies two network elements, namely		LISP-MS ([I-D.ietf-lisp-ms] specifies two network elements, namely
	the Map Server and the Map-Resolver, that are meant to be used by		the Map Server and the Map-Resolver, that are meant to be used by
	xTRs to access the mapping system. The advantage is clearly the fact		xTRs to access the mapping system. The advantage is clearly the fact
	that even if the mapping system changes in time xTRs do not need to		that even if the mapping system changes in time xTRs do not need to
	change anything since they deal only with Map Servers and Map-		change anything since they deal only with Map Servers and Map-
	Resolvers. This includes the security aspects, since no change in		Resolvers. This includes the security aspects, since no change in
	the local security policies is needed.		the local security policies is needed.
	skipping to change at page 26, line 24		skipping to change at page 28, line 15
	15. Security Considerations		15. Security Considerations
	Security considerations are the core of this document and do not need		Security considerations are the core of this document and do not need
	to be further discussed in this section.		to be further discussed in this section.
	16. Acknowledgments		16. Acknowledgments
	The flooding attack and the reference environment were first		The flooding attack and the reference environment were first
	described in Marcelo Bagnulo's draft [I-D.bagnulo-lisp-threat].		described in Marcelo Bagnulo's draft [I-D.bagnulo-lisp-threat].
			We would like to thank Jeff Wheeler for his 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).
	17. References		17. References
	17.1. Normative References		17.1. Normative References
	[I-D.ietf-lisp]		[I-D.ietf-lisp]
	Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,		Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
	"Locator/ID Separation Protocol (LISP)",		"Locator/ID Separation Protocol (LISP)",
	draft-ietf-lisp-14 (work in progress), June 2011.		draft-ietf-lisp-22 (work in progress), February 2012.
	[I-D.ietf-lisp-alt]		[I-D.ietf-lisp-alt]
	Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "LISP		Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "LISP
	Alternative Topology (LISP+ALT)", draft-ietf-lisp-alt-07		Alternative Topology (LISP+ALT)", draft-ietf-lisp-alt-10
	(work in progress), June 2011.		(work in progress), December 2011.
	[I-D.ietf-lisp-interworking]		[I-D.ietf-lisp-interworking]
	Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,		Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
	"Interworking LISP with IPv4 and IPv6",		"Interworking LISP with IPv4 and IPv6",
	draft-ietf-lisp-interworking-02 (work in progress),		draft-ietf-lisp-interworking-05 (work in progress),
	June 2011.		February 2012.
	[I-D.ietf-lisp-map-versioning]		[I-D.ietf-lisp-map-versioning]
	Iannone, L., Saucez, D., and O. Bonaventure, "LISP Map-		Iannone, L., Saucez, D., and O. Bonaventure, "LISP Map-
	Versioning", draft-ietf-lisp-map-versioning-01 (work in		Versioning", draft-ietf-lisp-map-versioning-08 (work in
	progress), March 2011.		progress), February 2012.
	[I-D.ietf-lisp-ms]		[I-D.ietf-lisp-ms]
	Fuller, V. and D. Farinacci, "LISP Map Server",		Fuller, V. and D. Farinacci, "LISP Map Server Interface",
	draft-ietf-lisp-ms-09 (work in progress), June 2011.		draft-ietf-lisp-ms-15 (work in progress), January 2012.
	[I-D.ietf-lisp-multicast]		[I-D.ietf-lisp-multicast]
	Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas,		Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas,
	"LISP for Multicast Environments",		"LISP for Multicast Environments",
	draft-ietf-lisp-multicast-06 (work in progress),		draft-ietf-lisp-multicast-14 (work in progress),
	June 2011.		February 2012.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	17.2. Informative References		17.2. Informative References
	[Chu] Jerry Chu, H., "Tuning TCP Parameters for the 21st		[Chu] Jerry Chu, H., "Tuning TCP Parameters for the 21st
	Century", 75th IETF, Stockholm, July 2009,		Century", 75th IETF, Stockholm, July 2009,
	<http://tools.ietf.org/wg/savi/>.		<http://tools.ietf.org/wg/savi/>.
	[I-D.bagnulo-lisp-threat]		[I-D.bagnulo-lisp-threat]
	Bagnulo, M., "Preliminary LISP Threat Analysis",		Bagnulo, M., "Preliminary LISP Threat Analysis",
	draft-bagnulo-lisp-threat-01 (work in progress),		draft-bagnulo-lisp-threat-01 (work in progress),
	July 2007.		July 2007.
			[I-D.fuller-lisp-ddt]
			Lewis, D., Farinacci, D., and V. Fuller, "LISP Delegated
			Database Tree", draft-fuller-lisp-ddt-00 (work in
			progress), November 2011.
	[I-D.ietf-sidr-arch]		[I-D.ietf-sidr-arch]
	Lepinski, M. and S. Kent, "An Infrastructure to Support		Lepinski, M. and S. Kent, "An Infrastructure to Support
	Secure Internet Routing", draft-ietf-sidr-arch-13 (work in		Secure Internet Routing", draft-ietf-sidr-arch-13 (work in
	progress), May 2011.		progress), May 2011.
	[I-D.ietf-tcpm-tcp-security]		[I-D.ietf-tcpm-tcp-security]
	Gont, F., "Security Assessment of the Transmission Control		Gont, F., "Security Assessment of the Transmission Control
	Protocol (TCP)", draft-ietf-tcpm-tcp-security-02 (work in		Protocol (TCP)", draft-ietf-tcpm-tcp-security-02 (work in
	progress), January 2011.		progress), January 2011.
	skipping to change at page 28, line 32		skipping to change at page 30, line 28
	[SAVI] IETF, "Source Address Validation Improvements Working		[SAVI] IETF, "Source Address Validation Improvements Working
	Group", <http://tools.ietf.org/wg/savi/>.		Group", <http://tools.ietf.org/wg/savi/>.
	[Saucez09]		[Saucez09]
	Saucez, D. and L. Iannone, "How to mitigate the effect of		Saucez, D. and L. Iannone, "How to mitigate the effect of
	scans on mapping systems", Submitted to the Trilogy		scans on mapping systems", Submitted to the Trilogy
	Summer School on Future Internet.		Summer School on Future Internet.
	Appendix A. Document Change Log		Appendix A. Document Change Log
			o Version 01 Posted February 2012.
			* Added discussion on LISP-DDT in Section 10.2.
	o Version 00 Posted July 2011.		o Version 00 Posted July 2011.
	* Added discussion on LISP-MS in Section 11.		* Added discussion on LISP-MS in Section 11.
	* Added discussion on Instance ID in Section 6.4.		* Added discussion on Instance ID in Section 6.4.
	* Editorial polishing of the whole document.		* Editorial polishing of the whole document.
	* Added "Change Log" appendix to keep track of main changes.		* Added "Change Log" appendix to keep track of main changes.
	* Renamed "draft-saucez-lisp-security-03.txt.		* Renamed "draft-saucez-lisp-security-03.txt.
	Authors' Addresses		Authors' Addresses
	Damien Saucez		Damien Saucez
	Universite catholique de Louvain		INRIA
	Place St. Barbe 2		2004 route des Luciolles BP 93
	Louvain la Neuve		06902 Sophia Antipolis Cedex
	Belgium		France
	Email: damien.saucez@uclouvain.be		Email: damien.saucez@inria.fr
	Luigi Iannone		Luigi Iannone
	Deutsche Telekom Laboratories AG		Telekom Innovation Laboratories
	Ernst-Reuter Platz 7		Ernst-Reuter Platz 7
	Berlin		Berlin
	Germany		Germany
	Email: luigi@net.t-labs.tu-berlin.de		Email: luigi@net.t-labs.tu-berlin.de
	Olivier Bonaventure		Olivier Bonaventure
	Universite catholique de Louvain		Universite catholique de Louvain
	Place St. Barbe 2		Place St. Barbe 2
	Louvain la Neuve		Louvain la Neuve
End of changes. 25 change blocks.
	45 lines changed or deleted		107 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/