[RAM] LISP threat analysis

[marcelo bagnulo braun <[e-mail]>]

Hi,

I have performed a preliminary threat analysis for LISP. I guess that 
some threats are missing, but here are some that i have been able to 
identify with my current undersranding of LISP. I know that LISP does 
not have security features yet, the goal of the draft is to cosnider 
what type of threats need to be taken into account when designing the 
security (i don't mean that all the threats described in the analysis 
must be prevented, but just that they need to be considered in the 
analysis at least)

Since the 00 deadline already passed, i am sending it to the ml

It will appear in the ID directory after prague i guess


Regards, marcelo




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: [phone]
    Email: [e-mail]
    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
    [e-mail].


Acknowledgment

    Funding for the RFC Editor function is provided by the IETF
    Administrative Support Activity (IASA).





Bagnulo                 Expires September 5, 2007              [Page 10]



  

_______________________________________________
RAM mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ram