draft-ietf-lisp-sec-05.txt		draft-ietf-lisp-sec-06.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: April 24, 2014 A. Cabellos		Expires: October 26, 2014 A. Cabellos
	Technical University of Catalonia		Technical University of Catalonia
	D. Saucez		D. Saucez
	INRIA		INRIA
	O. Bonaventure		April 24, 2014
	Universite Catholique de Louvain
	October 21, 2013
	LISP-Security (LISP-SEC)		LISP-Security (LISP-SEC)
	draft-ietf-lisp-sec-05		draft-ietf-lisp-sec-06
	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		provides 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
	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].
	skipping to change at page 1, line 46		skipping to change at page 1, line 44
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on April 24, 2014.		This Internet-Draft will expire on October 26, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the
			Copyright (c) 2014 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 2, line 27		skipping to change at page 2, line 30
	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 . . . . . . . . . . . . . . . . . . . . . 4		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. Map-Register LISP-SEC Extentions . . . . . . . . . . . . 10		5.3. Map-Register LISP-SEC Extentions . . . . . . . . . . . . 10
	5.4. ITR Processing . . . . . . . . . . . . . . . . . . . . . 11		5.4. ITR Processing . . . . . . . . . . . . . . . . . . . . . 10
	5.4.1. Map-Reply Record Validation . . . . . . . . . . . . . 12		5.4.1. Map-Reply Record Validation . . . . . . . . . . . . . 12
	5.4.2. PITR Processing . . . . . . . . . . . . . . . . . . . 13		5.4.2. PITR Processing . . . . . . . . . . . . . . . . . . . 13
	5.5. Encrypting and Decrypting an OTK . . . . . . . . . . . . 13		5.5. Encrypting and Decrypting an OTK . . . . . . . . . . . . 13
	5.6. Map-Resolver Processing . . . . . . . . . . . . . . . . . 14		5.6. Map-Resolver Processing . . . . . . . . . . . . . . . . . 14
	5.7. Map-Server Processing . . . . . . . . . . . . . . . . . . 14		5.7. Map-Server Processing . . . . . . . . . . . . . . . . . . 14
	5.7.1. Map-Server Processing in Proxy mode . . . . . . . . . 15		5.7.1. Map-Server Processing in Proxy mode . . . . . . . . . 15
	5.8. ETR Processing . . . . . . . . . . . . . . . . . . . . . 15		5.8. ETR Processing . . . . . . . . . . . . . . . . . . . . . 15
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 16		6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
	6.1. Mapping System Security . . . . . . . . . . . . . . . . . 16		6.1. Mapping System Security . . . . . . . . . . . . . . . . . 16
	6.2. Random Number Generation . . . . . . . . . . . . . . . . 16		6.2. Random Number Generation . . . . . . . . . . . . . . . . 16
	6.3. Map-Server and ETR Colocation . . . . . . . . . . . . . . 17		6.3. Map-Server and ETR Colocation . . . . . . . . . . . . . . 16
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
	7.1. HMAC functions . . . . . . . . . . . . . . . . . . . . . 17		7.1. HMAC functions . . . . . . . . . . . . . . . . . . . . . 16
	7.2. Key Wrap Functions . . . . . . . . . . . . . . . . . . . 17		7.2. Key Wrap Functions . . . . . . . . . . . . . . . . . . . 17
	7.3. Key Derivation Functions . . . . . . . . . . . . . . . . 18		7.3. Key Derivation Functions . . . . . . . . . . . . . . . . 17
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
	9. Normative References . . . . . . . . . . . . . . . . . . . . 18		9. Normative References . . . . . . . . . . . . . . . . . . . . 18
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
	1. Introduction		1. Introduction
	The Locator/ID Separation Protocol [RFC6830] defines a set of		The Locator/ID Separation Protocol [RFC6830] defines a set of
	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.ietf-lisp-threats].		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		provides 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
	an RLOC, is out of the scope of LISP-SEC. Additional security		an RLOC, is out of the scope of LISP-SEC. Additional security
	considerations are described in Section 6.		considerations are described in Section 6.
	2. Definition of Terms		2. Definition of Terms
	One-Time Key (OTK): An ephemeral randomly generated key that must		One-Time Key (OTK): An ephemeral randomly generated key that must
	be used for a single Map-Request/Map-Reply exchange.		be used for a single Map-Request/Map-Reply exchange.
	ITR-OTK: The One-Time Key generated at the ITR.		ITR-OTK: The One-Time Key generated at the ITR.
	skipping to change at page 4, line 16		skipping to change at page 4, line 16
	One-Time Key.		One-Time Key.
	EID-AD: The portion of ECM and Map-Reply Authentication Data		EID-AD: The portion of ECM and Map-Reply Authentication Data
	used for verification of EID-prefix authorization.		used for verification of EID-prefix authorization.
	PKT-AD: The portion of Map-Reply Authentication Data used to		PKT-AD: The portion of Map-Reply Authentication Data used to
	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
	[RFC6830].		[RFC6830].
	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.ietf-lisp-threats], that target EID-to-RLOC mappings, including		[I-D.ietf-lisp-threats], that target EID-to-RLOC mappings, including
	manipulations of Map-Request and Map-Reply messages, and malicious		manipulations of Map-Request and Map-Reply messages, and malicious
	ETR EID prefix overclaiming. However LISP-SEC makes two main		ETR EID prefix overclaiming. LISP-SEC makes two main assumptions:
	assumptions that are not part of [I-D.ietf-lisp-threats]. First, the		(1) the LISP mapping system is expected to deliver a Map-Request
	LISP mapping system is expected to deliver a Map-Request message to		message to their intended destination ETR as identified by the EID,
	their intended destination ETR as identified by the EID. Second, no		and (2) no man-in-the-middle (MITM) attack can be mounted within the
	man-in-the-middle attack can be mounted within the LISP Mapping		LISP Mapping System. Furthermore, while LISP-SEC enables detection
	System. Furthermore, while LISP-SEC enables detection of EID prefix		of EID prefix overclaiming attacks, it assumes that Map-Servers can
	overclaiming attacks, it assumes that Map Servers can verify the EID		verify the EID prefix authorization at time of registration.
	prefix authorization at time of registration.
	According to the threat model described in [I-D.ietf-lisp-threats]		According to the threat model described in [I-D.ietf-lisp-threats]
	LISP-SEC assumes that any kind of attack, including MITM attacks, can		LISP-SEC assumes that any kind of attack, including MITM attacks, can
	be mounted in the access network, outside of the boundaries of the		be mounted in the access network, outside of the boundaries of the
	LISP mapping system. An on-path attacker, outside of the LISP		LISP mapping system. An on-path attacker, outside of the LISP
	mapping system can, for example, hijack Map-Request and Map-Reply		mapping system can, for example, hijack Map-Request and Map-Reply
	messages, spoofing the identity of a LISP node. Another example of		messages, spoofing the identity of a LISP node. Another example of
	on-path attack, called over claiming attack, can be mounted by a		on-path attack, called overclaiming attack, can be mounted by a
	malicious Egress Tunnel Router (ETR), by overclaiming the EID-		malicious Egress Tunnel Router (ETR), by overclaiming the EID-
	prefixes for which it is authoritative. In this way the ETR can		prefixes for which it is authoritative. In this way the ETR can
	maliciously redirect traffic directed to a large number of hosts.		maliciously redirect traffic directed to a large number of hosts.
	4. Protocol Operations		4. Protocol Operations
	The goal of the security mechanisms defined in [RFC6830] is to		The goal of the security mechanisms defined in [RFC6830] 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
	[RFC6830] to address the threats described in Section 3 by leveraging		[RFC6830] to address the threats described in Section 3 by leveraging
	the trust relationships existing among the LISP entities		the trust relationships existing among the LISP entities
	participating to the exchange of the Map-Request/Map-Reply messages.		participating to the exchange of the Map-Request/Map-Reply messages.
	Those trust relationships are used to securely distribute a One-Time		Those trust relationships are used to securely distribute a One-Time
	Key (OTK) that provides origin authentication, integrity and anti-		Key (OTK) that provides origin authentication, integrity and anti-
	replay protection to mapping data conveyed via the mapping lookup		replay protection to mapping data conveyed via the mapping lookup
	process, and that effectively prevent over claiming attacks. The		process, and that effectively prevent overclaiming attacks. The
	processing of security parameters during the Map-Request/Map-Reply		processing of security parameters during the Map-Request/Map-Reply
	exchange is as follows:		exchange is as follows:
	o The ITR-OTK is generated and stored at the ITR, and securely		o The ITR-OTK is generated and stored at the ITR, and securely
	transported to the Map-Server.		transported to the Map-Server.
	o The Map-Server uses the ITR-OTK to compute an HMAC that protects		o The Map-Server uses the ITR-OTK to compute an HMAC that protects
	the integrity of the mapping data known to the Map-Server to		the integrity of the mapping data known to the Map-Server to
	prevent overclaiming attacks. The Map-Server also derives a new		prevent overclaiming attacks. The Map-Server also derives a new
	OTK, the MS-OTK, that is passed to the ETR, by applying a Key		OTK, the MS-OTK, that is passed to the ETR, by applying a Key
	skipping to change at page 6, line 23		skipping to change at page 6, line 16
	information for the ETR responsible for the EID destination		information for the ETR responsible for the EID destination
	address. Using this preconfigured information, the Map-Server,		address. Using this preconfigured information, the Map-Server,
	after the decapsulation of the ECM message, finds the longest		after the decapsulation of the ECM message, finds the longest
	match EID-prefix that covers the requested EID in the received		match EID-prefix that covers the requested EID in the received
	Map-Request. The Map-Server adds this EID-prefix, together with		Map-Request. The Map-Server adds this EID-prefix, together with
	an HMAC computed using the ITR-OTK, to a new Encapsulated Control		an HMAC computed using the ITR-OTK, to a new Encapsulated Control
	Message that contains the received Map-Request.		Message that contains the received Map-Request.
	o The Map-Server derives a new OTK, the MS-OTK, by applying a Key		o The Map-Server derives a new OTK, the MS-OTK, by applying a Key
	Derivation Function (KDF) to the ITR-OTK. This MS-OTK is included		Derivation Function (KDF) to the ITR-OTK. This MS-OTK is included
	in the Encapsulated Control Message that the Map Server uses to		in the Encapsulated Control Message that the Map-Server uses to
	forward the Map-Request to the ETR. To provide MS-OTK		forward the Map-Request to the ETR. To provide MS-OTK
	confidentiality over the path between the Map-Server and the ETR,		confidentiality over the path between the Map-Server and the ETR,
	the MS-OTK should be encrypted using the key shared between the		the MS-OTK should be encrypted using the key shared between the
	ETR and the Map-Server in order to secure ETR registration		ETR and the Map-Server in order to secure ETR registration
	[RFC6833].		[RFC6833].
	o If the Map-Server is acting in proxy mode, as specified in		o If the Map-Server is acting in proxy mode, as specified in
	[RFC6830], the ETR is not involved in the generation of the Map-		[RFC6830], the ETR is not involved in the generation of the Map-
	Reply. In this case the Map-Server generates the Map-Reply on		Reply. In this case the Map-Server generates the Map-Reply on
	behalf of the ETR as described below.		behalf of the ETR as described below.
	skipping to change at page 7, line 25		skipping to change at page 7, line 22
	5.1. Encapsulated Control Message LISP-SEC Extensions		5.1. Encapsulated Control Message LISP-SEC Extensions
	LISP-SEC uses the ECM (Encapsulated Control Message) defined in		LISP-SEC uses the ECM (Encapsulated Control Message) defined in
	[RFC6830] with Type set to 8, and S bit set to 1 to indicate that the		[RFC6830] with Type set to 8, and S bit set to 1 to indicate that the
	LISP header includes Authentication Data (AD). The format of the		LISP header includes Authentication Data (AD). The format of the
	LISP-SEC ECM Authentication Data is defined in the following figure.		LISP-SEC ECM Authentication Data is defined in the following figure.
	OTK-AD stands for One-Time Key Authentication Data and EID-AD stands		OTK-AD stands for One-Time Key Authentication Data and EID-AD stands
	for EID Authentication Data.		for EID Authentication Data.
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| AD Type |V| Reserved | Requested HMAC ID |		| AD Type |V| Reserved | Requested HMAC ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\
	| OTK Length | OTK Encryption ID | |		| OTK Length | OTK Encryption ID | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
	| One-Time-Key Preamble ... | |		| One-Time-Key Preamble ... | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ OTK-AD		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ OTK-AD
	| ... One-Time-Key Preamble | |		| ... One-Time-Key Preamble | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
	~ One-Time Key (128 bits) ~/		~ One-Time Key (128 bits) ~/
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <---+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <---+
	| EID-AD Length | KDF ID | |		| EID-AD Length | KDF ID | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
	| Record Count | Reserved | EID HMAC ID | EID-AD		| Record Count | Reserved | EID HMAC ID | EID-AD
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ |		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ |
	| Reserved | EID mask-len | EID-AFI | | |		| Reserved | EID mask-len | EID-AFI | | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Rec |		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Rec |
	~ EID-prefix ... ~ | |		~ EID-prefix ... ~ | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ |		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ |
	~ EID HMAC ~ |		~ EID HMAC ~ |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <---+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <---+
			-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ &lt;---+
	LISP-SEC ECM Authentication Data		LISP-SEC ECM Authentication Data
	AD Type: 1 (LISP-SEC Authentication Data)		AD Type: 1 (LISP-SEC Authentication Data)
	V: Key Version bit. This bit is toggled when the sender switches		V: Key Version bit. This bit is toggled when the sender switches
	to a new OTK wrapping key		to a new OTK wrapping key
	Reserved: Set to 0 on transmission and ignored on receipt.		Reserved: Set to 0 on transmission and ignored on receipt.
	Requested HMAC ID: The HMAC algorithm requested by the ITR. See		Requested HMAC ID: The HMAC algorithm requested by the ITR. See
	Section 5.4 for details.		Section 5.4 for details.
	OTK Length: The length (in bytes) of the OTK Authentication Data		OTK Length: The length (in bytes) of the OTK Authentication Data
	(OTK-AD), that contains the OTK Preamble and the OTK.		(OTK-AD), that contains the OTK Preamble and the OTK.
	OTK Encryption ID: The identifier of the key wrapping algorithm		OTK Encryption ID: The identifier of the key wrapping algorithm
	used to encrypt the One-Time-Key. When a 128-bit OTK is sent		used to encrypt the One-Time-Key. When a 128-bit OTK is sent
	skipping to change at page 9, line 25		skipping to change at page 9, line 20
	to 0. The HMAC covers the entire EID-AD.		to 0. The HMAC covers the entire EID-AD.
	5.2. Map-Reply LISP-SEC Extensions		5.2. Map-Reply LISP-SEC Extensions
	LISP-SEC uses the Map-Reply defined in [RFC6830], with Type set to 2,		LISP-SEC uses the Map-Reply defined in [RFC6830], with Type set to 2,
	and S bit set to 1 to indicate that the Map-Reply message includes		and S bit set to 1 to indicate that the Map-Reply message includes
	Authentication Data (AD). The format of the LISP-SEC Map-Reply		Authentication Data (AD). The format of the LISP-SEC Map-Reply
	Authentication Data is defined in the following figure. PKT-AD is		Authentication Data is defined in the following figure. PKT-AD is
	the Packet Authentication Data that covers the Map-Reply payload.		the Packet Authentication Data that covers the Map-Reply payload.
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| AD Type | Reserved |		| AD Type | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <---+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <---+
	| EID-AD Length | KDF ID | |		| EID-AD Length | KDF ID | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
	| Record Count | Reserved | EID HMAC ID | EID-AD		| Record Count | Reserved | EID HMAC ID | EID-AD
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ |		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ |
	| Reserved | EID mask-len | EID-AFI | | |		| Reserved | EID mask-len | EID-AFI | | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Rec |		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Rec |
	~ EID-prefix ... ~ | |		~ EID-prefix ... ~ | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ |		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ |
	~ EID HMAC ~ |		~ EID HMAC ~ |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <---+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <---+
	| PKT-AD Length | PKT HMAC ID |\		| PKT-AD Length | PKT HMAC ID |\
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
	~ PKT HMAC ~ PKT-AD		~ PKT HMAC ~ PKT-AD
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/
			-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/
	LISP-SEC Map-Reply Authentication Data		LISP-SEC Map-Reply Authentication Data
	AD Type: 1 (LISP-SEC Authentication Data)		AD Type: 1 (LISP-SEC Authentication Data)
	EID-AD Length: length (in bytes) of the EID-AD. An EID-AD MAY		EID-AD Length: length (in bytes) of the EID-AD. An EID-AD MAY
	contain multiple EID-records. Each EID-record is 4-byte long plus		contain multiple EID-records. Each EID-record is 4-byte long plus
	the length of the AFI-encoded EID-prefix.		the length of the AFI-encoded EID-prefix.
	KDF ID: Identifier of the Key Derivation Function used to derive		KDF ID: Identifier of the Key Derivation Function used to derive
	skipping to change at page 12, line 24		skipping to change at page 12, line 17
	Each individual Map-Reply EID-record is considered valid only if: (1)		Each individual Map-Reply EID-record is considered valid only if: (1)
	both EID-AD and PKT-AD are valid, and (2) the intersection of the		both EID-AD and PKT-AD are valid, and (2) the intersection of the
	EID-prefix in the Map-Reply EID-record with one of the EID-prefixes		EID-prefix in the Map-Reply EID-record with one of the EID-prefixes
	contained in the EID-AD is not empty. After identifying the Map-		contained in the EID-AD is not empty. After identifying the Map-
	Reply record as valid, the ITR sets the EID-prefix in the Map-Reply		Reply record as valid, the ITR sets the EID-prefix in the Map-Reply
	record to the value of the intersection set computed before, and adds		record to the value of the intersection set computed before, and adds
	the Map-Reply EID-record to its EID-to-RLOC cache, as described in		the Map-Reply EID-record to its EID-to-RLOC cache, as described in
	[RFC6830]. An example of Map-Reply record validation is provided in		[RFC6830]. An example of Map-Reply record validation is provided in
	Section 5.4.1.		Section 5.4.1.
	The ITR SHOULD send SMR triggered Map Requests over the mapping		The ITR SHOULD send SMR triggered Map-Requests over the mapping
	system in order to receive a secure Map-Reply. If an ITR accepts		system in order to receive a secure Map-Reply. If an ITR accepts
	piggybacked Map-Replies, it SHOULD also send a Map-Request over the		piggybacked Map-Replies, it SHOULD also send a Map-Request over the
	mapping system in order to securely verify the piggybacked Map-Reply.		mapping system in order to securely verify the piggybacked Map-Reply.
	5.4.1. Map-Reply Record Validation		5.4.1. Map-Reply Record Validation
	The payload of a Map-Reply may contain multiple EID-records. The		The payload of a Map-Reply may contain multiple EID-records. The
	whole Map-Reply is signed by the ETR, with the PKT HMAC, to provide		whole Map-Reply is signed by the ETR, with the PKT HMAC, to provide
	integrity protection and origin authentication to the EID-prefix		integrity protection and origin authentication to the EID-prefix
	records claimed by the ETR. The Authentication Data field of a Map-		records claimed by the ETR. The Authentication Data field of a Map-
	skipping to change at page 16, line 26		skipping to change at page 16, line 19
	6. Security Considerations		6. Security Considerations
	6.1. Mapping System Security		6.1. Mapping System Security
	The LISP-SEC threat model described in Section 3, assumes that the		The LISP-SEC threat model described in Section 3, assumes that the
	LISP Mapping System is working properly and eventually delivers Map-		LISP Mapping System is working properly and eventually delivers Map-
	Request messages to a Map-Server that is authoritative for the		Request messages to a Map-Server that is authoritative for the
	requested EID.		requested EID.
	Security is not yet embedded in LISP+ALT but BGP route filtering
	SHOULD be deployed in the ALT infrastructure to enforce proper
	routing in the mapping system. The SIDR working group is currently
	addressing prefix and route advertisement authorization and
	authentication for BGP. While following SIDR recommendations in the
	global Internet will take time, applying these recommendations to the
	ALT, which relies on BGP, should be less complex, as ALT is currently
	small and with a limited number of operators. Ultimately, deploying
	the SIDR recommendations in ALT further ensures that the fore
	mentioned assumption is true.
	It is also assumed that no man-in-the-middle attack can be carried
	out against the ALT router to ALT router tunnels, and that the
	information included into the Map-Requests, in particular the OTK,
	cannot be read by third-party entities. It should be noted that the
	integrity of the Map-Request in the ALT is protected by BGP
	authentication, and that in order to provide OTK confidentiality in
	the ALT mapping system the ALT router to ALT router tunnels MAY be
	deployed using IPsec (ESP).
	Map-Register security, including the right for a LISP entity to		Map-Register security, including the right for a LISP entity to
	register an EID-prefix or to claim presence at an RLOC, is out of the		register an EID-prefix or to claim presence at an RLOC, is out of the
	scope of LISP-SEC.		scope of LISP-SEC.
	6.2. Random Number Generation		6.2. Random Number Generation
	The ITR-OTK MUST be generated by a properly seeded pseudo-random (or		The ITR-OTK MUST be generated by a properly seeded pseudo-random (or
	strong random) source. See [RFC4086] for advice on generating		strong random) source. See [RFC4086] for advice on generating
	security-sensitive random data		security-sensitive random data
	6.3. Map-Server and ETR Colocation		6.3. Map-Server and ETR Colocation
	If the Map-Server and the ETR are colocated, LISP-SEC does not		If the Map-Server and the ETR are colocated, LISP-SEC does not
	provide protection from overclaiming attacks mounted by the ETR.		provide protection from overclaiming attacks mounted by the ETR.
	However, in this particular case, since the ETR is within the trust		However, in this particular case, since the ETR is within the trust
	boundaries of the Map-Server, ETR's overclaiming attacks are not		boundaries of the Map-Server, ETR's overclaiming attacks are not
	skipping to change at page 18, line 37		skipping to change at page 18, line 16
	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-threats]		[I-D.ietf-lisp-threats]
	Saucez, D., Iannone, L., and O. Bonaventure, "LISP Threats		Saucez, D., Iannone, L., and O. Bonaventure, "LISP Threats
	Analysis", draft-ietf-lisp-threats-08 (work in progress),		Analysis", draft-ietf-lisp-threats-09 (work in progress),
	October 2013.		April 2014.
	[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, February		Hashing for Message Authentication", RFC 2104, February
	1997.		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.
	skipping to change at page 20, line 4		skipping to change at page 19, line 27
	Email: vermagan@cisco.com		Email: vermagan@cisco.com
	Albert Cabellos		Albert Cabellos
	Technical University of Catalonia		Technical University of Catalonia
	c/ Jordi Girona s/n		c/ Jordi Girona s/n
	Barcelona 08034		Barcelona 08034
	Spain		Spain
	Email: acabello@ac.upc.edu		Email: acabello@ac.upc.edu
	Damien Saucez		Damien Saucez
	INRIA		INRIA
	2004 route des Lucioles - BP 93		2004 route des Lucioles - BP 93
	Sophia Antipolis		Sophia Antipolis
	France		France
	Email: damien.saucez@inria.fr		Email: damien.saucez@inria.fr
	Olivier Bonaventure
	Universite Catholique de Louvain
	Place St. Barbe 2
	Louvain-la-Neuve
	Belgium
	Email: olivier.bonaventure@uclouvain.be
End of changes. 30 change blocks.
	95 lines changed or deleted		77 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/