--- 1/draft-ietf-lisp-sec-13.txt 2017-10-25 15:13:08.416233629 -0700 +++ 2/draft-ietf-lisp-sec-14.txt 2017-10-25 15:13:08.464234711 -0700 @@ -1,22 +1,22 @@ Network Working Group F. Maino Internet-Draft V. Ermagan -Intended status: Experimental Cisco Systems -Expires: March 24, 2018 A. Cabellos +Intended status: Standards Track Cisco Systems +Expires: April 28, 2018 A. Cabellos Universitat Politecnica de Catalunya D. Saucez INRIA - September 20, 2017 + October 25, 2017 LISP-Security (LISP-SEC) - draft-ietf-lisp-sec-13 + draft-ietf-lisp-sec-14 Abstract This memo specifies LISP-SEC, a set of security mechanisms that 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 @@ -26,37 +26,37 @@ document are to be interpreted as described in [RFC2119]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 https://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 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 24, 2018. + This Internet-Draft will expire on April 28, 2018. Copyright Notice Copyright (c) 2017 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 - (https://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 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 described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 @@ -73,28 +73,31 @@ 5.5. Encrypting and Decrypting an OTK . . . . . . . . . . . . 14 5.6. Map-Resolver Processing . . . . . . . . . . . . . . . . . 15 5.7. Map-Server Processing . . . . . . . . . . . . . . . . . . 15 5.7.1. Map-Server Processing in Proxy mode . . . . . . . . . 16 5.8. ETR Processing . . . . . . . . . . . . . . . . . . . . . 16 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 6.1. Mapping System Security . . . . . . . . . . . . . . . . . 17 6.2. Random Number Generation . . . . . . . . . . . . . . . . 17 6.3. Map-Server and ETR Colocation . . . . . . . . . . . . . . 17 6.4. Deploying LISP-SEC . . . . . . . . . . . . . . . . . . . 17 - 6.5. Provisioning of the shared keys . . . . . . . . . . . . . 18 - 6.6. Reply Attacks . . . . . . . . . . . . . . . . . . . . . . 18 + 6.5. Shared Keys Provisioning . . . . . . . . . . . . . . . . 18 + 6.6. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 18 + 6.7. Denial of Service and Distributed Denial of Service + Attacks . . . . . . . . . . . . . . . . . . . . . . . . . 19 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 7.1. ECM AD Type Registry . . . . . . . . . . . . . . . . . . 19 7.2. Map-Reply AD Type Registry . . . . . . . . . . . . . . . 19 - 7.3. HMAC Functions . . . . . . . . . . . . . . . . . . . . . 19 + 7.3. HMAC Functions . . . . . . . . . . . . . . . . . . . . . 20 7.4. Key Wrap Functions . . . . . . . . . . . . . . . . . . . 20 - 7.5. Key Derivation Functions . . . . . . . . . . . . . . . . 20 + 7.5. Key Derivation Functions . . . . . . . . . . . . . . . . 21 + 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 9. Normative References . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 1. Introduction The Locator/ID Separation Protocol [RFC6830] is a network-layer-based protocol that enables separation of IP addresses into two new numbering spaces: Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). EID-to-RLOC mappings are stored in a database, the LISP @@ -150,32 +153,33 @@ 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 [RFC6830]. 3. LISP-SEC Threat Model - LISP-SEC addresses the control plane threats, described in [RFC7835], - that target EID-to-RLOC mappings, including manipulations of Map- - Request and Map-Reply messages, and malicious 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. How the Mapping System is protected from MITM attacks - depends from the particular Mapping Systems used, and is out of the - scope of this memo. 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. + LISP-SEC addresses the control plane threats, described in section + 3.7 and 3.8 of [RFC7835], that target EID-to-RLOC mappings, including + manipulations of Map-Request and Map-Reply messages, and malicious + 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. How the Mapping System is protected from MITM + attacks depends from the particular Mapping Systems used, and is out + of the scope of this memo. 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 [RFC7835] 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 overclaiming 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 maliciously redirect traffic @@ -795,43 +799,52 @@ As an example at the other end of the spectrum, in certain other deployments, attackers may be very sophisticated, and force the deployers to enforce very strict policies in term of HMAC algorithms accepted by an ITR. Similar considerations apply to the entire LISP-SEC threat model, and should guide the deployers and implementors whenever they encounter the key word SHOULD across this memo. -6.5. Provisioning of the shared keys +6.5. Shared Keys Provisioning - Provisioning of the shared keys between the ITR and the Map-Resolver + Provisioning of the keys shared between the ITR and the Map-Resolver as well as between the ETR and the Map-Server should be performed via an orchestration infrastructure and it is out of the scope of this draft. It is recommended that both shared keys are refreshed at periodical intervals to address key aging or attackers gaining unauthorized access to the shared keys. Shared keys should be unpredictable random values. -6.6. Reply Attacks +6.6. Replay Attacks An attacker can capture a valid Map-Request and/or Map-Reply and - reply it, however once the ITR receives the original Map-Reply the + replay it, however once the ITR receives the original Map-Reply the pair stored at the ITR will be discarded. If a replayed Map-Reply arrives at the ITR, there is no that matches the incoming Map-Reply and will be discarded. In case of replayed Map-Request, the Map-Server, Map-Resolver and ETR will have to do a LISP-SEC computation. This is equivalent to a valid LISP-SEC computation and an attacker does not obtain any benefit. +6.7. Denial of Service and Distributed Denial of Service Attacks + + LISP-SEC mitigates the risks of Denial of Service and Distributed + Denial of Service attacks by protecting the integrity and + authenticating the origin of the Map-Request/Map-Reply messages, and + by preventing malicious ETRs from overclaiming EID prefixes that + could re-direct traffic directed to a potentially large number of + hosts. + 7. IANA Considerations 7.1. ECM AD Type Registry IANA is requested to create the "ECM Authentication Data Type" registry with values 0-255, for use in the ECM LISP-SEC Extensions Section 5.1. The registry MUST be initially populated with the following values: Name Value Defined In @@ -925,71 +938,71 @@ 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 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, - DOI 10.17487/RFC2104, February 1997, - . + DOI 10.17487/RFC2104, February 1997, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, - DOI 10.17487/RFC2119, March 1997, - . + DOI 10.17487/RFC2119, March 1997, . [RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard (AES) Key Wrap Algorithm", RFC 3394, DOI 10.17487/RFC3394, September 2002, . [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, - DOI 10.17487/RFC4086, June 2005, - . + DOI 10.17487/RFC4086, June 2005, . [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 5226, - DOI 10.17487/RFC5226, May 2008, - . + DOI 10.17487/RFC5226, May 2008, . [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, - DOI 10.17487/RFC5869, May 2010, - . + DOI 10.17487/RFC5869, May 2010, . [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, - DOI 10.17487/RFC6234, May 2011, - . + DOI 10.17487/RFC6234, May 2011, . [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The Locator/ID Separation Protocol (LISP)", RFC 6830, - DOI 10.17487/RFC6830, January 2013, - . + DOI 10.17487/RFC6830, January 2013, . [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation Protocol (LISP) Map-Server Interface", RFC 6833, - DOI 10.17487/RFC6833, January 2013, - . + DOI 10.17487/RFC6833, January 2013, . [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol Alternative Logical Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836, January 2013, . [RFC7835] Saucez, D., Iannone, L., and O. Bonaventure, "Locator/ID Separation Protocol (LISP) Threat Analysis", RFC 7835, - DOI 10.17487/RFC7835, April 2016, - . + DOI 10.17487/RFC7835, April 2016, . Authors' Addresses Fabio Maino Cisco Systems 170 Tasman Drive San Jose, California 95134 USA Email: fmaino@cisco.com