Network Working Group M. Bagnulo Internet-Draft Huawei Lab at UC3M Intended status: Informational March 4, 2007 Expires: September 5, 2007 Preliminary LISP Threat Analysis draft-bagnulo-lisp-threat-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 5, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document performs a preliminary threat analysis on the Locator/ID Separation Protocol (LISP) as defined in draft- farinacci- lisp-00.txt. Bagnulo Expires September 5, 2007 [Page 1] Internet-Draft Preliminary LISP Threat Analysis March 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Application Scenario . . . . . . . . . . . . . . . . . . . . . 3 3. Threat analysis . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Identity hijacking . . . . . . . . . . . . . . . . . . . . 4 3.1.1. Attacker initiated communication (Hijacking a client identity) . . . . . . . . . . . . . . . . . . . 4 3.1.2. Victim initiated communication (Hijacking a server identity) . . . . . . . . . . . . . . . . . . . . . . 5 3.1.3. Intercepting ongoing communications (becoming a MITM) . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. DoS attacks . . . . . . . . . . . . . . . . . . . . . . . 7 3.2.1. Flooding a third party . . . . . . . . . . . . . . . . 7 3.2.2. Preventing future communications . . . . . . . . . . . 8 3.2.3. Interrupt ongoing communication . . . . . . . . . . . 8 3.2.4. DoS attacks against LISP infrastructure . . . . . . . 8 4. Security considerations . . . . . . . . . . . . . . . . . . . 8 5. Normative References . . . . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . . . 10 Bagnulo Expires September 5, 2007 [Page 2] Internet-Draft Preliminary LISP Threat Analysis March 2007 1. Introduction The first version of the Locator/ID Separation Protocol (LISP) is defined in draft-farinacci-lisp-00.txt [1]. This first version of the LIPS specification does not contain any security mechanisms. The goal of this document is to identify the different threats in the current LISP protocol in order to understand the security mechanisms that are needed to protect the LISP protocol. 2. Application Scenario We will consider the following application scenario. +----+ | HA | +----+ | EID: P1:IIDA ----------------- | | RLOC: P1:IIDLR1, P2:IIDLR2 +----+ +----+ |LR1 | |LR2 | +----+ +----+ | | | | +----+ +----+ |ISP1| |ISP2| +----+ +----+ +----+ | | +--| HC | IPC +----------------+ | +----+ | |--+ | Internet | +----+ | |-----| AT | IPAT +----------------+ +----+ | | +----+ +----+ |LR3 | | HB | +----+ +----+ | | EID=IPB RLOC=IPLR3 -------------------- LR [ETH] LISP Router that behaves bots as ITR and ETR In the depicted scenario we have two LISP capable sites. One of the sites, depicted on top of the figure, is multihomed to ISP1 and ISP2. Bagnulo Expires September 5, 2007 [Page 3] Internet-Draft Preliminary LISP Threat Analysis March 2007 We assume that we are using LISP1, so one of the routable addresses is used as EID, let's say that for host HA P1:IIDA is used as EID. In addition, the locators for that host will be the two addresses of the exit routers that are playing the role of ITR namely LR1 and LR2, so RLOCs are P1:IIDLR1 and P2:IIDLR2. (LR stands for LISP router since it plays both the roles of ITR and ETR). The other LISP capable site is the one depicted in the lower part of the figure and it has a single ISP and a single ITR/ETR namely, LR3. Host H3 located in this site has IPB as EID and the address of the LR3, LPLR3 as RLOC. Since we are using LISP1, IPB is a routable address Hosts HC and AT are other hosts in the Internet, with addresses IPC and IPAT respectively. HA, HB and HC are victims and AT is the attacker. 3. Threat analysis Off-path attacker assumption We will limit the considered attacks to those where the attacker is not located along the path used to route packets of the communication being attacked. 3.1. Identity hijacking In the attacks considered in this section the attacker will try to hijack the identity of one victim on the eyes of another victim. This means that two parties are deceived, one that thinks that is communicating with the owner of a given identify, but it is communicating with the attacker instead and the party whose identify is being stolen. 3.1.1. Attacker initiated communication (Hijacking a client identity) In this case, the attacker will initiate a communication with one victim pretending to be someone else. In the scenario above, the attacker AT will try to initiate a communication with HA pretending to be HC. In order to do that it will send a LISP packet with the following parameters: - Destination RLOC (outer header destination address): P1:IIDA Bagnulo Expires September 5, 2007 [Page 4] Internet-Draft Preliminary LISP Threat Analysis March 2007 - Destination EID (Inner header destination address): P1:IIDA - Source RLOC (outer header source address): IPAT - Source EID (inner header source address): IPC The packet will be received by LR1 who will generate the ICMP EID-to- RLOC Mapping message back to IPAT and will store the EID to RLOC mapping information for the received data packet as described in section 6.2 of draft-farinacci- lisp-00. The EID to RLOC mapping information stored at LR1 contains the following information: EID = HC, RLOC=IPAT In this case HA will be communicating with the attacker AT but HA believes that he is communicating with HC. HC identity has been stolen by AT in the eyes of HA. A similar attack could be launched using ICMP EID-to-RLOC Mapping messages instead of data packets. This would work in the following way. First that attacker sends an ICMP EID-to-RLOC Mapping message containing the false EID to RLOC mapping information and then it starts sending data packets using such state. 3.1.2. Victim initiated communication (Hijacking a server identity) In the previous section, the attacker is hijacking the identity of a client, since the attacker is the one that initiates the communication. While this is problematic, a much more ambitious attacks would to hijack the identity of a server, i.e. to hijack the identity of a server when the victim initiates a communication towards the server. This is also possible with LISP. It would work in the following way. Suppose that HC is a server that HA uses regularly (e.g. a newspaper web site) Suppose that AT wants that future communication initiated by HA to HC are directed to AT i.e. AT wants to hijack HC identity for all the communications initiated by HA. In order to do that, AT performs the following actions. It first needs to install false EID-to-RLOC mapping information in LR1. In order to do that, it has two options. It either sends a data packet containing the following information - Destination RLOC (outer header destination address): P1:IIDA Bagnulo Expires September 5, 2007 [Page 5] Internet-Draft Preliminary LISP Threat Analysis March 2007 - Destination EID (Inner header destination address): P1:IIDA - Source RLOC (outer header source address): IPAT - Source EID (inner header source address): IPC The data packet could be a UDP packet that will be discarded upon reception because there is no process listening in the requested port or an ICMP EID-to-RLOC Mapping message containing the mapping information from EID HC and RLOC IPAT. In any case LR1 will store that in order to reach IPC it must tunnel the packets to IPAT. However, there is no actual ongoing communication between HA and HC at the moment, so the attack has no effect so far. The attacker must then keep the EID to RLOC mapping information alive in LR1 for when HA decides to initiate a communication to HC. The attacker can do that by sending periodic data packets or ICMP EID-to-RLOC Mapping messages with the same information detailed before. Suppose that at any point in the future, HA decides to initiate a communication with HC. It will send a data packet with destination address IPC. The data packet will be intercepted by LR1 and tunnelled to the attacker at IPAT, since this is the mapping information available at LR1. Note that these attacks affect all future communications started by HA and that it affects communication initiated by HA. 3.1.3. Intercepting ongoing communications (becoming a MITM) In the two previous sections, we have considered the case where the attacker wants to hijack a future communication pretending to be one of the involved parties. In this section we will consider the case where there is an ongoing communication and the attacker wants to hijack the ongoing communication. Suppose that there is an ongoing communication between HA and HB. In this case, LR1 contains a mapping between EID=IPB and RLOC=IPLR3. LR3 contain a mapping between EID= P1:IIDA and RLOC=P1:IIDLR1, P2: IIDLR2. Suppose now that AT sends two packets, one to LR1 and another to LR3. These again can be data packets or ICMP EID-to-RLOC Mapping messages. Bagnulo Expires September 5, 2007 [Page 6] Internet-Draft Preliminary LISP Threat Analysis March 2007 In any case, the packet sent to LR1 will contain mapping information of EID=IPB and RLOC=IPAT. The packet sent to LR3 will contain mapping information EID=P1:IIDA and RLOC=IPAT. (One may think that ingress filtering could help here, but note that the attacker is sending packets from the claimed locator, so ingress filters won't be of any use to prevent this attack) The result is that LR1 will tunnel packets addressed to HB to the attacker at IPAT and LR2 will tunnel packets addressed to HA to the attacker at IPAT. The attacker has now placed himself as a man in the middle in the communication. It can either modify packets or simply sniff them. 3.2. DoS attacks In this section, we describe DoS attacks related to LISP. 3.2.1. Flooding a third party In this case, the attacker AT wants to use HA to flood a victim HC. In order to do that, it first initiates a communication with HA and starts a download of a heavy flow. Once that the flow is downloading, it redirects the heavy flow towards HC, flooding it. This is performed in the following way. AT initiates a communication with HA. In this case, AT uses IPAT as EID and IPAT as RLOC. This mapping information is stored in LR1 using either a data packet or an ICMP EID-to- RLOC Mapping message. AT then starts downloading a heavy flow form HA. At some point then, AT redirects the flow towards HC. It can do so by including IPC as a RLOC for the EID IPAT that is being used in the communication that is downloading the heavy flow. The IPC RLOC could be included since the beginning with a low priority and now simply send a new ICMP EID-to- RLOC Mapping message with a higher priority to IPC. In any case the result is that the flow will flood HC. It should be noted that in some cases, in order to keep the flow going, it is necessary that the receiver sends some ACK packets or similar. In this case, it is possible that the attacker can send such packets, since EID IPAT in LR1 can contain two valid RLOCs i.e. IPAT and IPC. In this case, if IPC has higher priority that IPAT, LR1 will send packets to IPC but will accept packets coming from IPAT as valid packets from the EID IPAT. In this case, the attacker could send ACK packets from its own location, and keep the flooding going towards IPC. Bagnulo Expires September 5, 2007 [Page 7] Internet-Draft Preliminary LISP Threat Analysis March 2007 3.2.2. Preventing future communications This case is similar to the one described in section Victim initiated communication (Hijacking a server identity), but only that instead of the attackers RLOC, a back hole IP address is included as the RLOC for a given EID. The result is that the traffic addressed to the EID is sent to a black hole, resulting in a DoS attacks form communications to that EID. Note that since LISP allows EID to be aggregated, the EIDs to be aggregated, this attack could affect really big prefixes of EIDs, in particular an attack to the prefix 0.0.0.0/0 would result in blocking all communications of the site. 3.2.3. Interrupt ongoing communication This case is similar to the one described in the section Intercepting ongoing communications (becoming a MITM) with the only difference that an back hole IP address is included as RLOC for the ongoing communication, terminating it. 3.2.4. DoS attacks against LISP infrastructure Another type of DoS attacks that must be considered are the DoS attacks against the LISP architecture itself. In particular LISP routers (ITR and ETR) are susceptible to DoS attacks. LISP routers store information about EID-to- RLOC mappings. They learn that information from data packets and from ICMP messages. An attacker could massively generate either tunnelled data packets or ICMP packets so that the router cache is overflowed. The result is that routers will not be able to store legitimate EID-to-RLOC mapping information and that LISP features will be annulled. (in the case of using non routable EIDs, all communication would be annulled if LISP functionality is not available) 4. Security considerations All this note considers security issues of the LISP protocol 5. Normative References [1] Farinacci, D., "Locator/ID Separation Protocol (LISP)", draft-farinacci-lisp-00 (work in progress), January 2007. Bagnulo Expires September 5, 2007 [Page 8] Internet-Draft Preliminary LISP Threat Analysis March 2007 Author's Address Marcelo Bagnulo Huawei Lab at UC3M Av. Universidad 30 Leganes, Madrid 28911 SPAIN Phone: 34 91 6249500 Email: marcelo@it.uc3m.es URI: http://www.it.uc3m.es Bagnulo Expires September 5, 2007 [Page 9] Internet-Draft Preliminary LISP Threat Analysis March 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Bagnulo Expires September 5, 2007 [Page 10]