draft-ietf-lisp-sec-00.txt		draft-ietf-lisp-sec-01.txt
	Network Working Group F. Maino		Network Working Group F. Maino
	Internet-Draft V. Ermagan		Internet-Draft V. Ermagan
	Intended status: Experimental Cisco Systems		Intended status: Experimental Cisco Systems
	Expires: January 2, 2012 A. Cabellos		Expires: July 4, 2012 A. Cabellos
	Technical University of		Technical University of
	Catalonia		Catalonia
	D. Saucez		D. Saucez
	O. Bonaventure		O. Bonaventure
	Universite catholique de Louvain		Universite catholique de Louvain
	July 1, 2011		January 1, 2012
	LISP-Security (LISP-SEC)		LISP-Security (LISP-SEC)
	draft-ietf-lisp-sec-00.txt		draft-ietf-lisp-sec-01.txt
	Abstract		Abstract
	This memo specifies LISP-SEC, a set of security mechanisms that		This memo specifies LISP-SEC, a set of security mechanisms that
	provide origin authentication, integrity and anti-replay protection		provide origin authentication, integrity and anti-replay protection
	to LISP's EID-to-RLOC mapping data conveyed via mapping lookup		to LISP's EID-to-RLOC mapping data conveyed via mapping lookup
	process. LISP-SEC also enables verification of authorization on EID-		process. LISP-SEC also enables verification of authorization on EID-
	prefix claims in Map-Reply messages.		prefix claims in Map-Reply messages.
	Requirements Language		Requirements Language
	skipping to change at page 1, line 46		skipping to change at page 1, line 46
	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 2, 2012.		This Internet-Draft will expire on July 4, 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
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3		2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3
	3. LISP-SEC Threat Model . . . . . . . . . . . . . . . . . . . . 4		3. LISP-SEC Threat Model . . . . . . . . . . . . . . . . . . . . 4
	4. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 5		4. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 4
	5. LISP-SEC Control Messages Details . . . . . . . . . . . . . . 7		5. LISP-SEC Control Messages Details . . . . . . . . . . . . . . 7
	5.1. Encapsulated Control Message LISP-SEC Extensions . . . . . 7		5.1. Encapsulated Control Message LISP-SEC Extensions . . . . . 7
	5.2. Map-Reply LISP-SEC Extensions . . . . . . . . . . . . . . 9		5.2. Map-Reply LISP-SEC Extensions . . . . . . . . . . . . . . 9
	5.3. ITR Processing . . . . . . . . . . . . . . . . . . . . . . 10		5.3. ITR Processing . . . . . . . . . . . . . . . . . . . . . . 10
	5.3.1. Map-Reply Record Validation . . . . . . . . . . . . . 12		5.3.1. Map-Reply Record Validation . . . . . . . . . . . . . 12
	5.3.2. PITR Processing . . . . . . . . . . . . . . . . . . . 13		5.3.2. PITR Processing . . . . . . . . . . . . . . . . . . . 13
	5.4. Encrypting and Decrypting an OTK . . . . . . . . . . . . . 13		5.4. Encrypting and Decrypting an OTK . . . . . . . . . . . . . 13
	5.5. Map-Resolver Processing . . . . . . . . . . . . . . . . . 14		5.5. Map-Resolver Processing . . . . . . . . . . . . . . . . . 14
	5.6. Map-Server Processing . . . . . . . . . . . . . . . . . . 14		5.6. Map-Server Processing . . . . . . . . . . . . . . . . . . 14
	5.6.1. Map-Server Processing in Proxy mode . . . . . . . . . 15		5.6.1. Map-Server Processing in Proxy mode . . . . . . . . . 15
	skipping to change at page 3, line 18		skipping to change at page 3, line 18
	functions for routers to exchange information used to map from non-		functions for routers to exchange information used to map from non-
	routable Endpoint Identifiers (EIDs) to routable Routing Locators		routable Endpoint Identifiers (EIDs) to routable Routing Locators
	(RLOCs). If these EID-to-RLOC mappings, carried through Map-Reply		(RLOCs). If these EID-to-RLOC mappings, carried through Map-Reply
	messages, are transmitted without integrity protection, an adversary		messages, are transmitted without integrity protection, an adversary
	can manipulate them and hijack the communication, impersonate the		can manipulate them and hijack the communication, impersonate the
	requested EID or mount Denial of Service or Distributed Denial of		requested EID or mount Denial of Service or Distributed Denial of
	Service attacks. Also, if the Map-Reply message is transported		Service attacks. Also, if the Map-Reply message is transported
	unauthenticated, an adversarial LISP entity can overclaim an EID-		unauthenticated, an adversarial LISP entity can overclaim an EID-
	prefix and maliciously redirect traffic directed to a large number of		prefix and maliciously redirect traffic directed to a large number of
	hosts. A detailed description of "overclaiming" attack is provided		hosts. A detailed description of "overclaiming" attack is provided
	in [I-D.saucez-lisp-security].		in [I-D.ietf-lisp-threats].
	This memo specifies LISP-SEC, a set of security mechanisms that		This memo specifies LISP-SEC, a set of security mechanisms that
	provide origin authentication, integrity and anti-replay protection		provide origin authentication, integrity and anti-replay protection
	to LISP's EID-to-RLOC mapping data conveyed via mapping lookup		to LISP's EID-to-RLOC mapping data conveyed via mapping lookup
	process. LISP-SEC also enables verification of authorization on EID-		process. LISP-SEC also enables verification of authorization on EID-
	prefix claims in Map-Reply messages, ensuring that the sender of a		prefix claims in Map-Reply messages, ensuring that the sender of a
	Map-Reply that provides the location for a given EID-prefix is		Map-Reply that provides the location for a given EID-prefix is
	entitled to do so according to the EID prefix registered in the		entitled to do so according to the EID prefix registered in the
	associated Map Server. Map-Register security, including the right		associated Map Server. Map-Register security, including the right
	for a LISP entity to register an EID-prefix or to claim presence at		for a LISP entity to register an EID-prefix or to claim presence at
	skipping to change at page 4, line 23		skipping to change at page 4, line 23
	protect the integrity of the Map-Reply message.		protect the integrity of the Map-Reply message.
	For definitions of other terms, notably Map-Request, Map-Reply,		For definitions of other terms, notably Map-Request, Map-Reply,
	Ingress Tunnel Router (ITR), Egress Tunnel Router (ETR), Map-Server		Ingress Tunnel Router (ITR), Egress Tunnel Router (ETR), Map-Server
	(MS) and Map-Resolver (MR) please consult the LISP specification		(MS) and Map-Resolver (MR) please consult the LISP specification
	[I-D.ietf-lisp].		[I-D.ietf-lisp].
	3. LISP-SEC Threat Model		3. LISP-SEC Threat Model
	LISP-SEC addresses the control plane threats, described in		LISP-SEC addresses the control plane threats, described in
	[I-D.saucez-lisp-security], that target EID-to-RLOC mappings,		[I-D.ietf-lisp-threats], that target EID-to-RLOC mappings, including
	including manipulations of Map-Request and Map-Reply messages, and		manipulations of Map-Request and Map-Reply messages, and malicious
	malicious xTR EID overclaiming. However LISP-SEC makes two main		xTR EID overclaiming. However LISP-SEC makes two main assumptions
	assumptions that are not part of [I-D.saucez-lisp-security]. First,		that are not part of [I-D.ietf-lisp-threats]. First, the LISP
	the LISP Mapping System is expected to deliver Map-Request messages		Mapping System is expected to deliver Map-Request messages to their
	to their intended destinations as identified by the EID. Second, no		intended destinations as identified by the EID. Second, no man-in-
	man-in-the-middle attack can be mounted within the LISP Mapping		the-middle attack can be mounted within the LISP Mapping System.
	System. Furthermore, while LISP-SEC enables detection of EID prefix		Furthermore, while LISP-SEC enables detection of EID prefix over
	over claiming attacks, it assumes that Map Servers can verify the EID		claiming attacks, it assumes that Map Servers can verify the EID
	prefix authorization at time of registration.		prefix authorization at time of registration.
	Accordingly to the threat model described in		Accordingly to the threat model described in [I-D.ietf-lisp-threats]
	[I-D.saucez-lisp-security] LISP-SEC assumes that any kind of attack,		LISP-SEC assumes that any kind of attack, including MITM attacks, can
	including MITM attacks, can be mounted in the access network, outside		be mounted in the access network, outside of the boundaries of the
	of the boundaries of the LISP mapping system. An on-path attacker,		LISP mapping system. An on-path attacker, outside of the LISP
	outside of the LISP mapping service system can, for instance, hijack		mapping service system can, for instance, hijack mapping requests and
	mapping requests and replies, spoofing the identity of a LISP node.		replies, spoofing the identity of a LISP node. Another example of
	Another example of on-path attack, called over claiming attack, can		on-path attack, called over claiming attack, can be mounted by a
	be mounted by a malicious Egress Tunnel Router (ETR), by over		malicious Egress Tunnel Router (ETR), by over claiming the EID-
	claiming the EID-prefixes for which it is authoritative. In this way		prefixes for which it is authoritative. In this way the ETR can
	the ETR can maliciously redirect traffic directed to a large number		maliciously redirect traffic directed to a large number of hosts.
	of hosts.
	4. Protocol Operations		4. Protocol Operations
	The goal of the security mechanisms defined in [I-D.ietf-lisp] is to		The goal of the security mechanisms defined in [I-D.ietf-lisp] is to
	prevent unauthorized insertion of mapping data, by providing origin		prevent unauthorized insertion of mapping data, by providing origin
	authentication and integrity protection for the Map-Registration, and		authentication and integrity protection for the Map-Registration, and
	by using the nonce to detect unsolicited Map-Reply sent by off-path		by using the nonce to detect unsolicited Map-Reply sent by off-path
	attackers.		attackers.
	LISP-SEC builds on top of the security mechanisms defined in		LISP-SEC builds on top of the security mechanisms defined in
	skipping to change at page 17, line 16		skipping to change at page 17, line 16
	7.1. HMAC functions		7.1. HMAC functions
	The following HMAC ID values are defined by this memo for use as		The following HMAC ID values are defined by this memo for use as
	Requested HMAC ID, EID HMAC ID, and PKT HMAC ID in the LISP-SEC		Requested HMAC ID, EID HMAC ID, and PKT HMAC ID in the LISP-SEC
	Authentication Data:		Authentication Data:
	Name Number Defined In		Name Number Defined In
	-------------------------------------------------		-------------------------------------------------
	NONE 0		NONE 0
	AUTH-HMAC-SHA-1-160 1 [RFC2104]		AUTH-HMAC-SHA-1-96 1 [RFC2104]
	AUTH-HMAC-SHA-256-128 2 [RFC4634]		AUTH-HMAC-SHA-256-128 2 [RFC4634]
	values 2-65535 are reserved to IANA.		values 2-65535 are reserved to IANA.
	HMAC Functions		HMAC Functions
	AUTH-HMAC-SHA-1-160 MUST be supported, AUTH-HMAC-SHA-256-128 should		AUTH-HMAC-SHA-1-96 MUST be supported, AUTH-HMAC-SHA-256-128 should be
	be supported.		supported.
	7.2. Key Wrap Functions		7.2. Key Wrap Functions
	The following OTK Encryption ID values are defined by this memo for		The following OTK Encryption ID values are defined by this memo for
	use as OTK key wrap algorithms ID in the LISP-SEC Authentication		use as OTK key wrap algorithms ID in the LISP-SEC Authentication
	Data:		Data:
	Name Number Defined In		Name Number Defined In
	-------------------------------------------------		-------------------------------------------------
	NULL-KEY-WRAP-128 1		NULL-KEY-WRAP-128 1
	skipping to change at page 18, line 28		skipping to change at page 18, line 28
	The authors would like to acknowledge Pere Monclus, Dave Meyer, Dino		The authors would like to acknowledge Pere Monclus, Dave Meyer, Dino
	Farinacci, Brian Weis, David McGrew, Darrel Lewis and Landon Curt		Farinacci, Brian Weis, David McGrew, Darrel Lewis and Landon Curt
	Noll for their valuable suggestions provided during the preparation		Noll for their valuable suggestions provided during the preparation
	of this document.		of this document.
	9. Normative References		9. 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-18 (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-01 (work in progress),		draft-ietf-lisp-interworking-02 (work in progress),
	August 2010.		June 2011.
	[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-14 (work in progress), December 2011.
	[I-D.saucez-lisp-security]		[I-D.ietf-lisp-threats]
	Saucez, D., Iannone, L., and O. Bonaventure, "LISP		Saucez, D., Iannone, L., and O. Bonaventure, "LISP Threats
	Security Threats", draft-saucez-lisp-security-03 (work in		Analysis", draft-ietf-lisp-threats-00 (work in progress),
	progress), March 2011.		July 2011.
	[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-		[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
	Hashing for Message Authentication", RFC 2104,		Hashing for Message Authentication", RFC 2104,
	February 1997.		February 1997.
	[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.
	[RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard		[RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard
	(AES) Key Wrap Algorithm", RFC 3394, September 2002.		(AES) Key Wrap Algorithm", RFC 3394, September 2002.
End of changes. 15 change blocks.
	39 lines changed or deleted		38 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/