--- 1/draft-ietf-lisp-sec-05.txt 2014-04-24 00:14:38.917017652 -0700 +++ 2/draft-ietf-lisp-sec-06.txt 2014-04-24 00:14:38.961018784 -0700 @@ -1,29 +1,27 @@ Network Working Group F. Maino Internet-Draft V. Ermagan Intended status: Experimental Cisco Systems -Expires: April 24, 2014 A. Cabellos +Expires: October 26, 2014 A. Cabellos Technical University of Catalonia D. Saucez INRIA - O. Bonaventure - Universite Catholique de Louvain - October 21, 2013 + April 24, 2014 LISP-Security (LISP-SEC) - draft-ietf-lisp-sec-05 + draft-ietf-lisp-sec-06 Abstract 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 process. LISP-SEC also enables verification of authorization on EID- prefix claims in Map-Reply messages. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. @@ -35,24 +33,25 @@ 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 April 24, 2014. + This Internet-Draft will expire on October 26, 2014. 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. 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 to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as @@ -61,63 +60,63 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3 3. LISP-SEC Threat Model . . . . . . . . . . . . . . . . . . . . 4 4. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 4 5. LISP-SEC Control Messages Details . . . . . . . . . . . . . . 7 5.1. Encapsulated Control Message LISP-SEC Extensions . . . . 7 5.2. Map-Reply LISP-SEC Extensions . . . . . . . . . . . . . . 9 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.2. PITR Processing . . . . . . . . . . . . . . . . . . . 13 5.5. Encrypting and Decrypting an OTK . . . . . . . . . . . . 13 5.6. Map-Resolver Processing . . . . . . . . . . . . . . . . . 14 5.7. Map-Server Processing . . . . . . . . . . . . . . . . . . 14 5.7.1. Map-Server Processing in Proxy mode . . . . . . . . . 15 5.8. ETR Processing . . . . . . . . . . . . . . . . . . . . . 15 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 6.1. Mapping System Security . . . . . . . . . . . . . . . . . 16 6.2. Random Number Generation . . . . . . . . . . . . . . . . 16 - 6.3. Map-Server and ETR Colocation . . . . . . . . . . . . . . 17 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 - 7.1. HMAC functions . . . . . . . . . . . . . . . . . . . . . 17 + 6.3. Map-Server and ETR Colocation . . . . . . . . . . . . . . 16 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 + 7.1. HMAC functions . . . . . . . . . . . . . . . . . . . . . 16 7.2. Key Wrap Functions . . . . . . . . . . . . . . . . . . . 17 - 7.3. Key Derivation Functions . . . . . . . . . . . . . . . . 18 + 7.3. Key Derivation Functions . . . . . . . . . . . . . . . . 17 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 9. Normative References . . . . . . . . . . . . . . . . . . . . 18 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 1. Introduction The Locator/ID Separation Protocol [RFC6830] defines a set of functions for routers to exchange information used to map from non- routable Endpoint Identifiers (EIDs) to routable Routing Locators (RLOCs). If these EID-to-RLOC mappings, carried through Map-Reply messages, are transmitted without integrity protection, an adversary 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 unauthenticated, an adversarial LISP entity can overclaim an EID- prefix and maliciously redirect traffic directed to a large number of hosts. A detailed description of "overclaiming" attack is provided in [I-D.ietf-lisp-threats]. 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 process. LISP-SEC also enables verification of authorization on EID- prefix claims in Map-Reply messages, ensuring that the sender of a Map-Reply that provides the location for a given EID-prefix is 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 an RLOC, is out of the scope of LISP-SEC. Additional security considerations are described in Section 6. 2. Definition of Terms One-Time Key (OTK): An ephemeral randomly generated key that must be used for a single Map-Request/Map-Reply exchange. ITR-OTK: The One-Time Key generated at the ITR. @@ -139,36 +138,35 @@ One-Time Key. EID-AD: The portion of ECM and Map-Reply Authentication Data used for verification of EID-prefix authorization. PKT-AD: The portion of Map-Reply Authentication Data used to protect the integrity of the Map-Reply message. 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 + (MS), and Map-Resolver (MR) please consult the LISP specification [RFC6830]. 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 - 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 - their 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. + ETR EID prefix overclaiming. LISP-SEC makes two main assumptions: + (1) the LISP mapping system is expected to deliver a Map-Request + message to their intended destination ETR as identified by the EID, + and (2) no man-in-the-middle (MITM) 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. 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 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 overclaiming the EID- prefixes for which it is authoritative. In this way the ETR can @@ -236,21 +234,21 @@ 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, 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 + 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 [RFC6833]. 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- Reply. In this case the Map-Server generates the Map-Reply on behalf of the ETR as described below. @@ -521,21 +518,21 @@ 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 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- 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 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 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 piggybacked Map-Replies, it SHOULD also send a Map-Request over the mapping system in order to securely verify the piggybacked Map-Reply. 5.4.1. Map-Reply Record Validation 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 integrity protection and origin authentication to the EID-prefix records claimed by the ETR. The Authentication Data field of a Map- @@ -715,45 +712,26 @@ 6. Security Considerations 6.1. Mapping System Security The LISP-SEC threat model described in Section 3, assumes that the LISP Mapping System is working properly and eventually delivers Map- Request messages to a Map-Server that is authoritative for the 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 register an EID-prefix or to claim presence at an RLOC, is out of the scope of LISP-SEC. 6.2. Random Number Generation + The ITR-OTK MUST be generated by a properly seeded pseudo-random (or strong random) source. See [RFC4086] for advice on generating security-sensitive random data 6.3. Map-Server and ETR Colocation If the Map-Server and the ETR are colocated, LISP-SEC does not provide protection from overclaiming attacks mounted by the ETR. However, in this particular case, since the ETR is within the trust boundaries of the Map-Server, ETR's overclaiming attacks are not @@ -820,22 +798,22 @@ The authors would like to acknowledge Pere Monclus, Dave Meyer, Dino Farinacci, Brian Weis, David McGrew, Darrel Lewis and Landon Curt Noll for their valuable suggestions provided during the preparation of this document. 9. Normative References [I-D.ietf-lisp-threats] Saucez, D., Iannone, L., and O. Bonaventure, "LISP Threats - Analysis", draft-ietf-lisp-threats-08 (work in progress), - October 2013. + Analysis", draft-ietf-lisp-threats-09 (work in progress), + April 2014. [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, February 1997. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard (AES) Key Wrap Algorithm", RFC 3394, September 2002. @@ -876,25 +853,18 @@ Email: vermagan@cisco.com Albert Cabellos Technical University of Catalonia c/ Jordi Girona s/n Barcelona 08034 Spain Email: acabello@ac.upc.edu + Damien Saucez INRIA 2004 route des Lucioles - BP 93 Sophia Antipolis France Email: damien.saucez@inria.fr - - Olivier Bonaventure - Universite Catholique de Louvain - Place St. Barbe 2 - Louvain-la-Neuve - Belgium - - Email: olivier.bonaventure@uclouvain.be