[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01

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]


Html markup produced by rfcmarkup 1.128b, available from https://tools.ietf.org/tools/rfcmarkup/