draft-ietf-lisp-sec-03.txt   draft-ietf-lisp-sec-04.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: March 16, 2013 A. Cabellos Expires: April 15, 2013 A. Cabellos
Technical University of Technical University of
Catalonia Catalonia
D. Saucez D. Saucez
INRIA INRIA
O. Bonaventure O. Bonaventure
Universite Catholique de Louvain Universite Catholique de Louvain
September 12, 2012 October 12, 2012
LISP-Security (LISP-SEC) LISP-Security (LISP-SEC)
draft-ietf-lisp-sec-03 draft-ietf-lisp-sec-04
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 47 skipping to change at page 1, line 47
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 March 16, 2013. This Internet-Draft will expire on April 15, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 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
skipping to change at page 4, line 25 skipping to change at page 4, line 25
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.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
xTR EID overclaiming. However LISP-SEC makes two main assumptions ETR EID prefix overclaiming. However LISP-SEC makes two main
that are not part of [I-D.ietf-lisp-threats]. First, the LISP assumptions that are not part of [I-D.ietf-lisp-threats]. First, the
Mapping System is expected to deliver Map-Request messages to their LISP mapping system is expected to deliver a Map-Request message to
intended destinations as identified by the EID. Second, no man-in- its intended destination ETR as identified by the EID. Second, no
the-middle attack can be mounted within the LISP Mapping System. man-in-the-middle attack can be mounted within the LISP Mapping
Furthermore, while LISP-SEC enables detection of EID prefix over System. Furthermore, while LISP-SEC enables detection of EID prefix
claiming attacks, it assumes that Map Servers can verify the EID overclaiming 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 [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 service system can, for instance, hijack mapping requests and mapping system can, for example, hijack Map-Request and Map-Reply
replies, 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 over claiming attack, can be mounted by a
malicious Egress Tunnel Router (ETR), by over claiming 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 [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
[I-D.ietf-lisp] to address the threats described in Section 3 by [I-D.ietf-lisp] to address the threats described in Section 3 by
leveraging the trust relationships existing among the LISP entities leveraging 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 over claiming 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 provided by 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 (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
Derivation Function (KDF) to the ITR-OTK. Derivation Function (KDF) to the ITR-OTK.
o The ETR uses the MS-OTK to compute an HMAC that protects the o The ETR uses the MS-OTK to compute an HMAC that protects the
integrity of the Map-Reply sent to the ITR. integrity of the Map-Reply sent to the ITR.
o Finally, the ITR uses the stored ITR-OTK to verify the integrity o Finally, the ITR uses the stored ITR-OTK to verify the integrity
of the mapping data provided by both the Map-Server and the ETR, of the mapping data provided by both the Map-Server and the ETR,
and to verify that no overclaiming attacks were mounted along the and to verify that no overclaiming attacks were mounted along the
path between the Map-Server and the ITR. path between the Map-Server and the ITR.
Section 5 provides the detailed description of the LISP-SEC control Section 5 provides the detailed description of the LISP-SEC control
messages and their processing, while the rest of this section messages and their processing, while the rest of this section
describes the flow of protocol operations at each entity involved in describes the flow of protocol operations at each entity involved in
the Map-Request/Map-Reply exchange: the Map-Request/Map-Reply exchange:
o The ITR, upon transmitting a Map-Request message, generates and o The ITR, upon needing to transmit a Map-Request message, generates
stores an OTK (ITR-OTK). This key is included into the and stores an OTK (ITR-OTK). This ITR-OTK is included into the
Encapsulated Control Message (ECM) that contains the Map-Request Encapsulated Control Message (ECM) that contains the Map-Request
sent to the Map-Resolver. To provide confidentiality to the ITR- sent to the Map-Resolver. To provide confidentiality to the ITR-
OTK over the path between the ITR and its Map-Resolver, the ITR- OTK over the path between the ITR and its Map-Resolver, the ITR-
OTK SHOULD be encrypted using a preconfigured key shared between OTK SHOULD be encrypted using a preconfigured key shared between
the ITR and the Map-Resolver, similar to the key shared between the ITR and the Map-Resolver, similar to the key shared between
the ETR and the Map-Server in order to secure ETR registration the ETR and the Map-Server in order to secure ETR registration
[I-D.ietf-lisp-ms]. [I-D.ietf-lisp-ms].
o The Map-Resolver decapsulates the ECM message, decrypts the ITR- o The Map-Resolver decapsulates the ECM message, decrypts the ITR-
OTK, if needed, and forwards through the Mapping System the OTK, if needed, and forwards through the Mapping System the
received Map-Request and the ITR-OTK, as part of a new ECM received Map-Request and the ITR-OTK, as part of a new ECM
message. As described in Section 5.6, the LISP Mapping System message. As described in Section 5.6, the LISP Mapping System
delivers the ECM to the appropriate Map-Server, as identified by delivers the ECM to the appropriate Map-Server, as identified by
the EID destination address of the Map-Request. the EID destination address of the Map-Request.
o The Map-Server is configured with the location mappings and policy o The Map-Server is configured with the location mappings and policy
information for the ETR responsible for the destination EID 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 (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. MS-OTK is included in Derivation Function (KDF) to the ITR-OTK. This MS-OTK is included
the Encapsulated Control Message sent to the ETR. To provide MS- in the Encapsulated Control Message that the Map Server uses to
OTK confidentiality over the path between the Map-Server and the forward the Map-Request to the ETR. To provide MS-OTK
ETR, the MS-OTK should be encrypted using the key shared between confidentiality over the path between the Map-Server and the ETR,
the ETR and the Map-Server in order to secure ETR registration the MS-OTK should be encrypted using the key shared between the
ETR and the Map-Server in order to secure ETR registration
[I-D.ietf-lisp-ms]. [I-D.ietf-lisp-ms].
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
[I-D.ietf-lisp], the ETR is not involved in the generation of the [I-D.ietf-lisp], the ETR is not involved in the generation of the
Map-Reply. In this case the Map-Server generates the Map-Reply on Map-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.
o The ETR, upon receiving the Encapsulated Map-Request from the Map- o The ETR, upon receiving the ECM encapsulated Map-Request from the
Server, decrypts the MS-OTK, if needed, and originates a Map-Reply Map-Server, decrypts the MS-OTK, if needed, and originates a
that contains the EID-to-RLOC mapping information as specified in standard Map-Reply that contains the EID-to-RLOC mapping
[I-D.ietf-lisp]. information as specified in [I-D.ietf-lisp].
o The ETR computes an HMAC over the original LISP Map-Reply, keyed o The ETR computes an HMAC over this standard Map-Reply, keyed with
with MS-OTK to protect the integrity of the whole Map-Reply. The MS-OTK to protect the integrity of the whole Map-Reply. The ETR
ETR also copies the EID-prefix authorization data that the Map- also copies the EID-prefix authorization data that the Map-Server
Server included in the Encapsulated Map-Request into the Map-Reply included in the ECM encapsulated Map-Request into the Map-Reply
message. message. The ETR then sends this complete Map-Reply message to
the requesting ITR.
o The ITR, upon receiving the Map-Reply, uses the locally stored o The ITR, upon receiving the Map-Reply, uses the locally stored
ITR-OTK to verify the integrity of the EID-prefix authorization ITR-OTK to verify the integrity of the EID-prefix authorization
data included in the Map-Reply by the Map-Server. The ITR data included in the Map-Reply by the Map-Server. The ITR
computes the MS-OTK by applying the same KDF used by the Map- computes the MS-OTK by applying the same KDF used by the Map-
Server, and verifies the integrity of the Map-Reply. If the Server, and verifies the integrity of the Map-Reply. If the
integrity checks fail, the Map-Reply MUST be discarded. Also, if integrity checks fail, the Map-Reply MUST be discarded. Also, if
the EID-prefixes claimed by the ETR in the Map-Reply are not equal the EID-prefixes claimed by the ETR in the Map-Reply are not equal
or less specific than the EID-prefix authorization data inserted to or more specific than the EID-prefix authorization data
by the Map-Server, the ITR MUST discard the Map-Reply. inserted by the Map-Server, the ITR MUST discard the Map-Reply.
5. LISP-SEC Control Messages Details 5. LISP-SEC Control Messages Details
LISP-SEC metadata associated with a Map-Request is transported within LISP-SEC metadata associated with a Map-Request is transported within
the Encapsulated Control Message that contains the Map-Request. the Encapsulated Control Message that contains the Map-Request.
LISP-SEC metadata associated with the Map-Reply is transported within LISP-SEC metadata associated with the Map-Reply is transported within
the Map-Reply itself. the Map-Reply itself.
5.1. Encapsulated Control Message LISP-SEC Extensions 5.1. Encapsulated Control Message LISP-SEC Extensions
skipping to change at page 15, line 36 skipping to change at page 15, line 36
5.7.1. Map-Server Processing in Proxy mode 5.7.1. Map-Server Processing in Proxy mode
If the Map-Server is in proxy mode, it generates a Map-Reply, as If the Map-Server is in proxy mode, it generates a Map-Reply, as
specified in [I-D.ietf-lisp], with the S-bit set to 1. The Map-Reply specified in [I-D.ietf-lisp], with the S-bit set to 1. The Map-Reply
includes the Authentication Data that contains the EID-AD, computed includes the Authentication Data that contains the EID-AD, computed
as specified in Section 5.7, as well as the PKT-AD computed as as specified in Section 5.7, as well as the PKT-AD computed as
specified in Section 5.8. specified in Section 5.8.
5.8. ETR Processing 5.8. ETR Processing
Upon receiving an encapsulated Map-Request with the S-bit set, the Upon receiving an ECM encapsulated Map-Request with the S-bit set,
ETR decapsulates the ECM message. The OTK field, if encrypted, is the ETR decapsulates the ECM message. The OTK field, if encrypted,
decrypted as specified in Section 5.5 to obtain the unencrypted MS- is decrypted as specified in Section 5.5 to obtain the unencrypted
OTK. MS-OTK.
The ETR then generates a Map-Reply as specified in [I-D.ietf-lisp] The ETR then generates a Map-Reply as specified in [I-D.ietf-lisp]
and includes an Authentication Data that contains the EID-AD, as and includes the Authentication Data that contains the EID-AD, as
received in the encapsulated Map-Request, as well as the PKT-AD. received in the encapsulated Map-Request, as well as the PKT-AD.
The EID-AD is copied from the Authentication Data of the received The EID-AD is copied from the Authentication Data of the received
encapsulated Map-Request. encapsulated Map-Request.
The PKT-AD contains the HMAC of the whole Map-Reply packet, keyed The PKT-AD contains the HMAC of the whole Map-Reply packet, keyed
with the MS-OTK and computed using the HMAC algorithm specified in with the MS-OTK and computed using the HMAC algorithm specified in
the Requested HMAC ID field of the received encapsulated Map-Request. the Requested HMAC ID field of the received encapsulated Map-Request.
If the ETR does not support the Requested HMAC ID, it uses a If the ETR does not support the Requested HMAC ID, it uses a
different algorithm and updates the PKT HMAC ID field accordingly. different algorithm and updates the PKT HMAC ID field accordingly.
 End of changes. 19 change blocks. 
44 lines changed or deleted 46 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/