--- 1/draft-ietf-lisp-sec-03.txt 2012-10-13 00:14:12.285341481 +0200 +++ 2/draft-ietf-lisp-sec-04.txt 2012-10-13 00:14:12.329342598 +0200 @@ -1,25 +1,25 @@ Network Working Group F. Maino Internet-Draft V. Ermagan Intended status: Experimental Cisco Systems -Expires: March 16, 2013 A. Cabellos +Expires: April 15, 2013 A. Cabellos Technical University of Catalonia D. Saucez INRIA O. Bonaventure Universite Catholique de Louvain - September 12, 2012 + October 12, 2012 LISP-Security (LISP-SEC) - draft-ietf-lisp-sec-03 + draft-ietf-lisp-sec-04 Abstract This memo specifies LISP-SEC, a set of security mechanisms that provide origin authentication, integrity and anti-replay protection to LISP's EID-to-RLOC mapping data conveyed via mapping lookup process. LISP-SEC also enables verification of authorization on EID- prefix claims in Map-Reply messages. Requirements Language @@ -36,21 +36,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect @@ -148,140 +148,142 @@ For definitions of other terms, notably Map-Request, Map-Reply, Ingress Tunnel Router (ITR), Egress Tunnel Router (ETR), Map-Server (MS) and Map-Resolver (MR) please consult the LISP specification [I-D.ietf-lisp]. 3. LISP-SEC Threat Model LISP-SEC addresses the control plane threats, described in [I-D.ietf-lisp-threats], that target EID-to-RLOC mappings, including manipulations of Map-Request and Map-Reply messages, and malicious - xTR EID overclaiming. However LISP-SEC makes two main assumptions - that are not part of [I-D.ietf-lisp-threats]. First, the LISP - Mapping System is expected to deliver Map-Request messages to their - intended destinations as identified by the EID. Second, no man-in- - the-middle attack can be mounted within the LISP Mapping System. - Furthermore, while LISP-SEC enables detection of EID prefix over - claiming attacks, it assumes that Map Servers can verify the EID + ETR EID prefix overclaiming. However LISP-SEC makes two main + assumptions that are not part of [I-D.ietf-lisp-threats]. First, the + LISP mapping system is expected to deliver a Map-Request message to + its intended destination ETR as identified by the EID. Second, no + man-in-the-middle attack can be mounted within the LISP Mapping + System. Furthermore, while LISP-SEC enables detection of EID prefix + overclaiming attacks, it assumes that Map Servers can verify the EID 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 be mounted in the access network, outside of the boundaries of the LISP mapping system. An on-path attacker, outside of the LISP - mapping service system can, for instance, hijack mapping requests and - replies, spoofing the identity of a LISP node. Another example of + mapping system can, for example, hijack Map-Request and Map-Reply + messages, spoofing the identity of a LISP node. Another example of on-path attack, called over claiming attack, can be mounted by a malicious Egress Tunnel Router (ETR), by over claiming the EID- prefixes for which it is authoritative. In this way the ETR can maliciously redirect traffic directed to a large number of hosts. 4. Protocol Operations 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 by using the nonce to detect unsolicited Map-Reply sent by off-path attackers. LISP-SEC builds on top of the security mechanisms defined in [I-D.ietf-lisp] to address the threats described in Section 3 by leveraging the trust relationships existing among the LISP entities participating to the exchange of the Map-Request/Map-Reply messages. Those trust relationships are used to securely distribute a One-Time Key (OTK) that provides origin authentication, integrity and anti- replay protection to mapping data conveyed via the mapping lookup process, and that effectively prevent over claiming attacks. The processing of security parameters during the Map-Request/Map-Reply exchange is as follows: o The ITR-OTK is generated and stored at the ITR, and securely transported to the Map-Server. 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 - 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. o The ETR uses the MS-OTK to compute an HMAC that protects the integrity of the Map-Reply sent to the ITR. 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, and to verify that no overclaiming attacks were mounted along the path between the Map-Server and the ITR. Section 5 provides the detailed description of the LISP-SEC control messages and their processing, while the rest of this section describes the flow of protocol operations at each entity involved in the Map-Request/Map-Reply exchange: - o The ITR, upon transmitting a Map-Request message, generates and - stores an OTK (ITR-OTK). This key is included into the + o The ITR, upon needing to transmit a Map-Request message, generates + and stores an OTK (ITR-OTK). This ITR-OTK is included into the Encapsulated Control Message (ECM) that contains the Map-Request 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 SHOULD be encrypted using a preconfigured 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 [I-D.ietf-lisp-ms]. o The Map-Resolver decapsulates the ECM message, decrypts the ITR- OTK, if needed, and forwards through the Mapping System the received Map-Request and the ITR-OTK, as part of a new ECM message. As described in Section 5.6, the LISP Mapping System delivers the ECM to the appropriate Map-Server, as identified by the EID destination address of the Map-Request. o The Map-Server is configured with the location mappings and policy - information for the ETR responsible for the destination EID - address. Using this preconfigured information the Map-Server, + information for the ETR responsible for the EID destination + address. Using this preconfigured information, the Map-Server, after the decapsulation of the ECM message, finds the longest match EID-prefix that covers the requested EID in the received Map-Request. The Map-Server adds this EID-prefix, together with an HMAC computed using the ITR-OTK, to a new Encapsulated Control Message that contains the received Map-Request. - o The Map-Server derives a new OTK (MS-OTK) by applying a Key - Derivation Function (KDF) to the ITR-OTK. MS-OTK is included in - the Encapsulated Control Message sent to the ETR. To provide MS- - OTK confidentiality over the path between the Map-Server and the - ETR, the MS-OTK should be encrypted using the key shared between - the ETR and the Map-Server in order to secure ETR registration + 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 + in the Encapsulated Control Message that the Map Server uses to + forward the Map-Request to the ETR. To provide MS-OTK + confidentiality over the path between the Map-Server and the ETR, + 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]. 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 Map-Reply. In this case the Map-Server generates the Map-Reply on behalf of the ETR as described below. - o The ETR, upon receiving the Encapsulated Map-Request from the Map- - Server, decrypts the MS-OTK, if needed, and originates a Map-Reply - that contains the EID-to-RLOC mapping information as specified in - [I-D.ietf-lisp]. + o The ETR, upon receiving the ECM encapsulated Map-Request from the + Map-Server, decrypts the MS-OTK, if needed, and originates a + standard Map-Reply that contains the EID-to-RLOC mapping + information as specified in [I-D.ietf-lisp]. - o The ETR computes an HMAC over the original LISP Map-Reply, keyed - with MS-OTK to protect the integrity of the whole Map-Reply. The - ETR also copies the EID-prefix authorization data that the Map- - Server included in the Encapsulated Map-Request into the Map-Reply - message. + o The ETR computes an HMAC over this standard Map-Reply, keyed with + MS-OTK to protect the integrity of the whole Map-Reply. The ETR + also copies the EID-prefix authorization data that the Map-Server + included in the ECM encapsulated Map-Request into the Map-Reply + 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 ITR-OTK to verify the integrity of the EID-prefix authorization 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- Server, and verifies the integrity of the Map-Reply. If the 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 - or less specific than the EID-prefix authorization data inserted - by the Map-Server, the ITR MUST discard the Map-Reply. + to or more specific than the EID-prefix authorization data + inserted by the Map-Server, the ITR MUST discard the Map-Reply. 5. LISP-SEC Control Messages Details LISP-SEC metadata associated with a Map-Request is transported within the Encapsulated Control Message that contains the Map-Request. LISP-SEC metadata associated with the Map-Reply is transported within the Map-Reply itself. 5.1. Encapsulated Control Message LISP-SEC Extensions @@ -680,27 +682,27 @@ 5.7.1. Map-Server Processing in Proxy mode 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 includes the Authentication Data that contains the EID-AD, computed as specified in Section 5.7, as well as the PKT-AD computed as specified in Section 5.8. 5.8. ETR Processing - Upon receiving an encapsulated Map-Request with the S-bit set, the - ETR decapsulates the ECM message. The OTK field, if encrypted, is - decrypted as specified in Section 5.5 to obtain the unencrypted MS- - OTK. + Upon receiving an ECM encapsulated Map-Request with the S-bit set, + the ETR decapsulates the ECM message. The OTK field, if encrypted, + is decrypted as specified in Section 5.5 to obtain the unencrypted + MS-OTK. 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. The EID-AD is copied from the Authentication Data of the received encapsulated Map-Request. 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 the Requested HMAC ID field of the received encapsulated Map-Request. If the ETR does not support the Requested HMAC ID, it uses a different algorithm and updates the PKT HMAC ID field accordingly.