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/