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]