--- 1/draft-ietf-lisp-threats-01.txt 2012-09-12 00:13:51.809341693 +0200 +++ 2/draft-ietf-lisp-threats-02.txt 2012-09-12 00:13:51.865342566 +0200 @@ -1,21 +1,21 @@ Network Working Group D. Saucez Internet-Draft INRIA Intended status: Informational L. Iannone -Expires: September 2, 2012 Telekom Innovation Laboratories +Expires: March 16, 2013 Telecom ParisTech O. Bonaventure Universite catholique de Louvain - March 1, 2012 + September 12, 2012 LISP Threats Analysis - draft-ietf-lisp-threats-01.txt + draft-ietf-lisp-threats-02.txt Abstract This document analyzes the threats against the security of the Locator/Identifier Separation Protocol and proposes a set of recommendations to mitigate some of the identified security risks. Status of this Memo This Internet-Draft is submitted in full conformance with the @@ -24,21 +24,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 September 2, 2012. + This Internet-Draft will expire on March 16, 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 @@ -81,21 +81,21 @@ 11.2. Map-Resolver . . . . . . . . . . . . . . . . . . . . . . . 24 12. Suggested Recommendations . . . . . . . . . . . . . . . . . . 25 13. Document Status and Plans . . . . . . . . . . . . . . . . . . 27 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 15. Security Considerations . . . . . . . . . . . . . . . . . . . 28 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 17.1. Normative References . . . . . . . . . . . . . . . . . . . 28 17.2. Informative References . . . . . . . . . . . . . . . . . . 29 Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 30 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 1. Requirements notation 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]. 2. Introduction The Locator/ID Separation Protocol (LISP) is defined in @@ -550,23 +550,23 @@ Packets sent by a non-spoofing off-path attacker (NSA) can cause similar problem if no check is done with the EID-to-RLOC Cache (see Section 6.3 for the EID-to-RLOC Cache check). Otherwise, if the check is performed the packets will be rejected by the ETR that receives them and cannot cause problems. 6.4.4. Attacks using the ID Instance bits LISP allows to carry in its header a 24-bits value called "Instance - ID" and used on the ITR to indicate which private AFI has been used - for encapsulation, while on the ETR can be used to select the - forwarding table used for forwarding the decapsulated packet. + ID" and used on the ITR to indicate which private Instance ID has + been used for encapsulation, while on the ETR can be used to select + the forwarding table used for forwarding the decapsulated packet. Even if an off-path attacker could randomly guess a valid Instance ID value, there is no LISP specific problem. Obviously the attacker could be now able to reach hosts that are only reachable through the routing table identified by the attacked Instance ID, however, end- system security is out of the scope of this document. Nevertheless, access lists can be configured to protect the network from Instance ID based attacks. 7. Control Plane Threats @@ -599,22 +599,22 @@ Considering only IPv6 addresses, a Map-Request can be as small as 40 bytes, considering one single ITR address and no Mapping Protocol Data. The Map-Reply instead has a size of O(12 + (R * (28 + N * 24))) bytes, where N is the maximum number of RLOCs in a mapping and R the maximum number of records in a Map-Reply. Since up to 255 RLOCs can be associated to an EID-Prefix and 255 records can be stored in a Map-Reply, the maximum size of a Map-Reply is thus above 1 MB showing a size factor of up to 39,193 between the message sent by the attacker and the message sent by the ETR. These numbers are however theoretical values not considering transport layer - limitations and it is more likely that the reply will contain only on - record with at most a dozen of locators, giving an amplification + limitations and it is more likely that the reply will contain only + one record with at most a dozen of locators, giving an amplification factor around 8. Any ISP with a large number of potential RLOCs for a given EID-Prefix should carefully ponder the best trade-off between the number of RLOCs through which it wants that the EID is reachable and the consequences that an amplification attack can produce. It should be noted that the maximum rate of Map-Reply messages should apply to all Map-Replies and also be associated to each destination that receives Map-Reply messages. Otherwise, a possible @@ -680,37 +680,49 @@ Note, however, that the nonce only confirms that the Map-Reply was sent by the ETR that received the Map-Request. It does not validate the content of the Map-Reply message. In addition, an attacker can perform EID-to-RLOC Cache overflow attack by de-aggregating (i.e., splitting an EID prefix into artificially smaller EID prefixes) either positive or negative mappings. + An attacker can combine overclaiming and de-aggregation to succeed a + cache poisoning attack. For example, if the attacker EID prefix is + 10.0.0.0/24, she cannot provide a mapping for 10.0.1.0/24. But, as a + Map-Reply can contain several mappings, it is possible to finally + control this prefix. To do so, the attacker sends a mapping with an + EID prefix that covers at the same time the requested EID and the + prefix she wants to control. For example, if the request is for + 10.0.0.1, and the target prefix is 10.0.1.0/24, the Map-Reply can + contain the mapping 10.0.0.0/23 and a mapping for 10.0.1.0/24. The + reply is perfectly legitimate according to the requested EID and the + attack is a success. + 7.3. Gleaning Attacks A third type of attack involves the gleaning mechanism proposed in [I-D.ietf-lisp] and discussed in [Saucez09]. In order to reduce the time required to obtain a mapping, [I-D.ietf-lisp] allows an ITR to learn a mapping from the LISP data encapsulated packets and the Map- Request packets that it receives. LISP data encapsulated packet contains a source RLOC, destination RLOC, source EID and destination - EID. When a ITR receives a data encapsulated packet coming from a + EID. When an ITR receives a data encapsulated packet coming from a source EID for which it does not already know a mapping, it may insert the mapping between the source RLOC and the source EID in its EID-to-RLOC Cache. Gleaning can also be used when an ITR receives a Map-Request as the Map-Request also contains a source EID address and - a source RLOC. Once a gleaned entry has been added to the cache, the - LISP ITR sends a Map-Request to retrieve the mapping for the gleaned - EID from the mapping system. [I-D.ietf-lisp] recommends to store the - gleaned entries for only a few seconds. + a source RLOC. Once a gleaned entry has been added to the EID-to- + RLOC cache, the LISP ITR sends a Map-Request to retrieve the mapping + for the gleaned EID from the mapping system. [I-D.ietf-lisp] + recommends to store the gleaned entries for only a few seconds. The first risk of gleaning is the ability to temporarily hijack an identity. Consider an off-path attacker that wants to temporarily hijack host HA's identity and send packets to host HB with host HA's identity. If the xTRs that serve host HB do not store a mapping for host HA, a non-spoofing off-path attacker (NSA) could send a LISP encapsulated data packet to LR3 or LR4. The ETR will store the gleaned entry and use it to return the packets sent by host HB to the attacker. In parallel, the ETR will send a Map-Request to retrieve the mapping for HA. During a few seconds or until the reception of @@ -755,21 +767,21 @@ toward non-LISP sites. For these elements some of the attack based on the LISP specific header are not possible, for the simple reason that some of the fields cannot be used due to the unidirectional nature of the traffic. The Proxy-ITR has functionalities similar to the ITR, however, its main purpose is to encapsulate packets arriving from the DFZ in order to reach LISP sites. This means that it is no bound to any particular EID-Prefix, hence no mapping exists and no mapping can be configured in the EID-to-RLOC Database. This means that the Proxy- - ITR element itself is not able, to check whether or not the arriving + ITR element itself is not able to check whether or not the arriving traffic has the right to be encapsulated or not. To limit such an issue it is recommended to use the current practice based on firewalls and ACLs on the machine running the Proxy-ITR service. On the other side, the Proxy-ITR is meant to encapsulate only packets that are destined to one of the LISP sites it is serving. This is the case for instance for a service provider selling Proxy-ITR services. For this purpose a static EID-to-RLOC Cache can be configured in order to encapsulate only valid packets. In case of a cache-miss no Map-Request needs to be sent and the packet can be silently dropped. @@ -1238,41 +1250,41 @@ This work has been partially supported by the INFSO-ICT-216372 TRILOGY Project (www.trilogy-project.org). 17. References 17.1. Normative References [I-D.ietf-lisp] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol (LISP)", - draft-ietf-lisp-22 (work in progress), February 2012. + draft-ietf-lisp-23 (work in progress), May 2012. [I-D.ietf-lisp-alt] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "LISP Alternative Topology (LISP+ALT)", draft-ietf-lisp-alt-10 (work in progress), December 2011. [I-D.ietf-lisp-interworking] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, "Interworking LISP with IPv4 and IPv6", - draft-ietf-lisp-interworking-05 (work in progress), - February 2012. + draft-ietf-lisp-interworking-06 (work in progress), + March 2012. [I-D.ietf-lisp-map-versioning] Iannone, L., Saucez, D., and O. Bonaventure, "LISP Map- - Versioning", draft-ietf-lisp-map-versioning-08 (work in - progress), February 2012. + Versioning", draft-ietf-lisp-map-versioning-09 (work in + progress), March 2012. [I-D.ietf-lisp-ms] Fuller, V. and D. Farinacci, "LISP Map Server Interface", - draft-ietf-lisp-ms-15 (work in progress), January 2012. + draft-ietf-lisp-ms-16 (work in progress), March 2012. [I-D.ietf-lisp-multicast] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "LISP for Multicast Environments", draft-ietf-lisp-multicast-14 (work in progress), February 2012. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. @@ -1291,27 +1303,28 @@ Lewis, D., Farinacci, D., and V. Fuller, "LISP Delegated Database Tree", draft-fuller-lisp-ddt-00 (work in progress), November 2011. [I-D.ietf-sidr-arch] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", draft-ietf-sidr-arch-13 (work in progress), May 2011. [I-D.ietf-tcpm-tcp-security] - Gont, F., "Security Assessment of the Transmission Control - Protocol (TCP)", draft-ietf-tcpm-tcp-security-02 (work in - progress), January 2011. + Gont, F., "Survey of Security Hardening Methods for + Transmission Control Protocol (TCP) Implementations", + draft-ietf-tcpm-tcp-security-03 (work in progress), + March 2012. [I-D.lear-lisp-nerd] Lear, E., "NERD: A Not-so-novel EID to RLOC Database", - draft-lear-lisp-nerd-08 (work in progress), March 2010. + draft-lear-lisp-nerd-09 (work in progress), April 2012. [I-D.maino-lisp-sec] Maino, F., Ermagan, V., Cabellos-Aparicio, A., Saucez, D., and O. Bonaventure, "LISP-Security (LISP-SEC)", draft-maino-lisp-sec-00 (work in progress), March 2011. [I-D.meyer-lisp-cons] Brim, S., "LISP-CONS: A Content distribution Overlay Network Service for LISP", draft-meyer-lisp-cons-04 (work in progress), April 2008. @@ -1334,51 +1347,58 @@ [SAVI] IETF, "Source Address Validation Improvements Working Group", . [Saucez09] Saucez, D. and L. Iannone, "How to mitigate the effect of scans on mapping systems", Submitted to the Trilogy Summer School on Future Internet. Appendix A. Document Change Log + o Version 02 Posted September 2012. + + * Added a new attack that combines overclaiming and de- + aggregation (see Section 7.2). + + * Editorial polishing. + o Version 01 Posted February 2012. * Added discussion on LISP-DDT in Section 10.2. o Version 00 Posted July 2011. * Added discussion on LISP-MS in Section 11. * Added discussion on Instance ID in Section 6.4. * Editorial polishing of the whole document. * Added "Change Log" appendix to keep track of main changes. * Renamed "draft-saucez-lisp-security-03.txt. Authors' Addresses Damien Saucez INRIA - 2004 route des Luciolles BP 93 + 2004 route des Lucioles BP 93 06902 Sophia Antipolis Cedex France Email: damien.saucez@inria.fr Luigi Iannone - Telekom Innovation Laboratories - Ernst-Reuter Platz 7 - Berlin - Germany + Telecom ParisTech + 23, Avenue d'Italie, CS 51327 + 75214 PARIS Cedex 13 + France - Email: luigi@net.t-labs.tu-berlin.de + Email: luigi.iannone@telecom-paristech.fr Olivier Bonaventure Universite catholique de Louvain Place St. Barbe 2 Louvain la Neuve Belgium Email: olivier.bonaventure@uclouvain.be