[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01
Network Working Group M. Bagnulo
Internet-Draft Huawei Lab at UC3M
Intended status: Informational July 8, 2007
Expires: January 9, 2008
Preliminary LISP Threat Analysis
draft-bagnulo-lisp-threat-01
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 January 9, 2008.
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-01.txt.
Bagnulo Expires January 9, 2008 [Page 1]
Internet-Draft Preliminary LISP Threat Analysis July 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Application Scenario . . . . . . . . . . . . . . . . . . . . . 3
3. Threat analysis . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Identity hijacking . . . . . . . . . . . . . . . . . . . . 5
3.1.1. Attacks using the LISP data packets to create state . 5
3.1.2. Attacks using the Map-Reply message to create state . 10
3.2. DoS attacks . . . . . . . . . . . . . . . . . . . . . . . 12
3.2.1. Flooding a third party . . . . . . . . . . . . . . . . 12
3.2.2. Preventing future communications . . . . . . . . . . . 13
3.2.3. Interrupt ongoing communication . . . . . . . . . . . 13
3.2.4. DoS attacks against LISP infrastructure . . . . . . . 13
4. Security considerations . . . . . . . . . . . . . . . . . . . 14
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
6. Normative References . . . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 16
Bagnulo Expires January 9, 2008 [Page 2]
Internet-Draft Preliminary LISP Threat Analysis July 2007
1. Introduction
The Locator/ID Separation Protocol (LISP) is defined in
draft-farinacci-lisp-01.txt [1]. The goal of this document is to
identify the different threats in the current LISP protocol in order
to understand the current level of protection of the LISP protocol
and identify additional security mechanisms that are needed to
protect it.
As in any ID/loc split approach, the critical operation is the
creation of ID to locator binding state in any device that will use
it later on. In the particular case of LISP the critical operation
is the creation of EID to RLOC mappings in the ITR and the ETR. Such
operation is performed in 3 different ways:
Using the information obtained from a LISP data packet (looking into
the EID and RLOC information included by the originator of the
packet)
Using the information contained in the Map-Reply message
Using a EID-to-RLOC database
This document performs threat analysis for the first two cases. The
third case, the one of the EID-to-RLOC database, has a different
trust model, and a specific threat analysis needs to be performed for
that case.
2. Application Scenario
We will consider the following application scenario.
Bagnulo Expires January 9, 2008 [Page 3]
Internet-Draft Preliminary LISP Threat Analysis July 2007
+----+
| 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: LISP Router that behaves as both as the ITR and the 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.
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
Bagnulo Expires January 9, 2008 [Page 4]
Internet-Draft Preliminary LISP Threat Analysis July 2007
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
Full-time 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 during the whole duration of the attack.
There are then two type of attacks:
- Off-path attacks the attacker is off-path during the whole duration
of the attack
- Time shifted attacks: the attacker is located along path during a
limited period, but the duration of the attack is significantly
longer than the period that the attacker is along the path.
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.
As we mentioned earlier, there are two messages an attacker can use
to create the state required to launch an attack: the LISP data
packets or the Map-Reply message. In this section we will first
present the attacks based on using the LISP data packets and then the
attacks that use the Map-Reply messages.
3.1.1. Attacks using the LISP data packets to create state
3.1.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:
Bagnulo Expires January 9, 2008 [Page 5]
Internet-Draft Preliminary LISP Threat Analysis July 2007
- Destination RLOC (outer header destination address): P1:IIDA
- 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 LISP Map-
Reply message back to IPAT and will store the EID to RLOC mapping
information for the received data packet. The EID to RLOC mapping
information stored at LR1 contains the following information: EID =
IPC, 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.
Basically, in this case the packet that triggers all of this is (sent
from AT toward HA (who's EID is P1:11DA)) looks like:
DST SRC
+---------+------+
| P1:IIDA | IPAT |<-- RLOC (outer)
+---------+------+
| P1:IIDA | IPC |<-- EID (inner)
+---------+------+
The mapping installed in LR1 is {EID, RLOC} = {IPC, IPAT}, and thus
HC's identity is hijacked (at least from HA's perspective) by AT
(since it thinks that IPAT is the RLOC associated with EID HC =
inaddr(IPC)). As a result, subsequent packets emitted by HA will
look like
DST SRC
+-----+---------+
| IPC | P1:IIDA |
+-----+---------+
and LR1 will encap as follows (giving the installed mapping):
Bagnulo Expires January 9, 2008 [Page 6]
Internet-Draft Preliminary LISP Threat Analysis July 2007
DST SRC
+------+----------+
| IPAT | P1:IIDR1 | outer
+------+----------+
| IPC | P1:IIDA | innner
+------+----------+
and the hijack is complete.
3.1.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 sends a data packet containing the following
information
- Destination RLOC (outer header destination address): P1:IIDA
- 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.
LR1 will store that in order to reach IPC it must tunnel the packets
to IPAT.
Bagnulo Expires January 9, 2008 [Page 7]
Internet-Draft Preliminary LISP Threat Analysis July 2007
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 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.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.
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)
If the new EI-to-RLOC information overrides the previously available
mapping information (this would depend on how the new mapping
information is managed, but it seems that in the current version,
latest information supersedes older information) , 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
Bagnulo Expires January 9, 2008 [Page 8]
Internet-Draft Preliminary LISP Threat Analysis July 2007
communication. It can either modify packets or simply sniff them.
In this case, packets exchanged in this attack would look like this:
Suppose HA and HB are communicating. In this case, LR1 has
{IPB,IPLR3} and LR3 has {P1:IIDA, {P1:IIDLR1, P2:IIDLR2}} (P1:IIDA
has 2 possible RLOCs). Now, the attacker at IPAT sends
DST SRC
+---------+------+
| P1:IIDA | IPAT |<-- RLOC (outer)
+---------+------+
| P1:IIDA | IPB |<-- EID (inner)
+---------+------+
to HA. the packet is intercepted by LR1, which results in the mapping
{IPB, IPAT} (so AT has half of the connection). That is, packets
from HA -> HB look like
DST SRC
+-----+---------+
| IPB | P1:IIDA |
+-----+---------+
LR1 builds
DST SRC
+------+-----------+
| IPAT | P1:IIDLR1 |
+------+-----------+
| IPB | P1:IIDA |
+------+-----------+
and packets are delivered to the MITM.
Going the other way, AT sends
DST SRC
+-----+---------+
| IPB | IPAT |<-- RLOC (outer)
+-----+---------+
| IPB | P1:IIDA |<-- EID (inner)
+-----+---------+
Bagnulo Expires January 9, 2008 [Page 9]
Internet-Draft Preliminary LISP Threat Analysis July 2007
to HB. The packet is intercepted by LR3, which results in the
mapping {P1:IIDA, IPAT} (so AT has the other half of the connection),
so packets sent to P1:IIDA (HA) get delivered to AT (inaddr(IPAT)).
3.1.2. Attacks using the Map-Reply message to create state
Map-Reply messages are protected by a nonce, which is copied from the
LISP data packet that triggered the Map-Reply generation. Such nonce
protects from Map-Reply messages generated spontaneously (i.e. not
generated as a reply to an actual LISP data packet). While this
protection prevents a number of attacks, there are still a few
attacks that are possible, which are presented in this section.
3.1.2.1. Less-specific prefix attack
Map-Reply messages are very powerful because they can contain single
EIDs but also EID prefixes. Such capability allows any malicious
party receiving a LISP data packet to reply with a Map-Reply message
that includes a less specific EID prefix that contains more than its
own EIDs. Basically, the problem here is that the return routability
check only verifies the presence of a single EID and not the whole
EID prefix. The attack could be performed in the following way:
For whatever reason, HB decides to start a communication with AT. HB
generates a data packet containing:
DST SRC
+------+-----+
| IPAT | IPB |
+------+-----+
and LR3 will encap as follows:
DST SRC
+------+-------+
| IPAT | IPLR3 | outer
+------+-------+
| IPAT | IPB | innner
+------+-------+
In addition, the encapsulated packet will contain a nonce NB.
AT will receive the packet, will store the state corresponding to HB
(EID=IPB, RLOC=IPLR3). In addition, AT can reply with a Map_Reply
Bagnulo Expires January 9, 2008 [Page 10]
Internet-Draft Preliminary LISP Threat Analysis July 2007
message. However, AT can reply with an Map-Reply message that
contains amore specific prefix that contains other prefixes than its
own. In particular, AT can include the 0/0 prefix in the Map-Reply
message. The Map-Reply message is validated by the nonce NB the was
included in the received ISP data packet. The Map-Reply message that
AT will send back to LR3 will be:
- Nonce: NB
- EID mask-len: 0
- EID prefix: 0
- Locator: IPAT
Upon the reception of such Map-Reply message, LR3 will install the
EID-to-RLOC mapping which will map the whole EID space to the
attacker locator IPAT. All the following packets routed by LR3 will
be forwarded to the attacker AT. Note that this not only affects the
packets generated by HB but to all the packets generated by any host
behind LR3. Also note that this is the more extreme case, where the
whole EID space is hijacked, but it would also be possible to hijack
parts of the EID space, which would result in less severe attacks,
but probably more difficult to detect.
3.1.2.2. Time-shifted attack
Time-shifted attacks are those where the attacker is located along
the path during a short period and launches an attack that persists
in time long after the attacker left the on-path position. These
attacks have been considered relevant during the design of other
protocols for mapping identities and location, such as MIP. In
particular, in order to prevent time-shifted attacks in MIPv6 route
optimization, the MIPv6 specification requires the periodic
performance of the return routability check. The lifetime of the
state created using the validation information obtained using a
single return routability check is limited to 7 minutes in the MIPv6
spec. This implies that the maximum time span that a time-shifted
attack can be active after the attacker left the on-path position is
7 minutes. For additional information about the MIPv6 security
design, the reader is referred to [2].
In the case of LISP, an attacker can launch a time-shifted attacks if
he is able to learn a nonce of a LISP data packet generated by the
victim. Once the attacker has obtained the nonce, it can then
generate a Map-Reply message and hijack any portion of the the EID
space, thanks to the aforementioned capabilities of EID aggregation
by the means of less-specific EID prefixes. The Map-reply message
Bagnulo Expires January 9, 2008 [Page 11]
Internet-Draft Preliminary LISP Threat Analysis July 2007
would be accepted by the victim because it contains a valid nonce and
it will install the ED-to-RLOC mapping. The state will remain in the
victim even when the attacker has left the on-path position. The
attacker is able to keep the state alive by refreshing the state (is
likely that LISP provides some means for this since it should be able
for a genuine host to preserve the state in its peers, even when the
original path is unreachable)
The attack is then as follows:
The attacker is located along a path sniffing packets and looking for
any LISP data packet generated by the victim.
Once the attacker finds such a packet, it learns the nonce in the
LISP header.
The attacker generated a Map-Reply packet containing the nonce, the
EID prefix 0/0 and its own locator.
The attacker sends the Map-Reply which is processed by the victim's
router which installs the state.
From this moment, all the outgoing packets of the victim's site are
forwarded to the locator selected by the attacker.
The attacker can leave its position and move to its own locator, but
the attack is still active, since the state is still installed in the
victim's router.
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, AT 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
since it is contained in the initial LISP data packet as described
previously. 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
Bagnulo Expires January 9, 2008 [Page 12]
Internet-Draft Preliminary LISP Threat Analysis July 2007
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 LISP Map-Reply message with a higher priority to IPC. In any
case the result is that the flow will flood HC.(Note that it is
expected that AT can include additional locators associated to the
EID IPAT during the initial period where there is a direct
communication between AT and HA)
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.
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 black 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.
In addition to that, it is possible to use the Less-specific prefix
attack to perform a DoS attack. In this case, a larger number of
destinations are affected, since it affects a whole prefix.
Finally, it should be noted that the attacks do not affect the
traffic generated by a single machine, but to all the traffic routed
by the affected ITR i.e. to the traffic generated by all the hosts
behind the ITR.
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. LISP infrastructure is
likely to become a critical part of the network, since EIDs may not
Bagnulo Expires January 9, 2008 [Page 13]
Internet-Draft Preliminary LISP Threat Analysis July 2007
be reachable without the LISP service. This makes the LISP routers a
preferred target for attackers.
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 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)
Current LISP proposal includes rate-limiting techniques for
protecting against DoS attacks. Such technique can be useful to
prevent LISP routers from crashing under the attack. However, this
technique does not prevent the actual effect of the attack, which
that hosts served by the LISP router under attack will not be able to
communicate. This is so, because the LISP router rate limiting
techniques, will also affect the legitimate request from internal and
external hosts, making communication hard if not impossible
(depending on the strength of the actual attack)
4. Security considerations
This note outlines security issues of the LISP protocol.
5. Acknowledgments
Pekka Nikander and Dave Meyer reviewed this document and provided
comments. In addition, Dave Meyer wrote the text containing the
packet description of attacks described in sections 3.1.1.1 and
3.1.1.3. Dino Farinacci provided clarifying comments about how LISP
works.
6. Normative References
[1] Farinacci, D., Fuller, V., Oran, D., and D. Meyer, "Locator/ID
Separation Protocol (LISP)", draft-farinacci-lisp-01 (work in
progress), June 2007.
[2] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E.
Nordmark, "Mobile IP Version 6 Route Optimization Security
Design Background", RFC 4225, December 2005.
Bagnulo Expires January 9, 2008 [Page 14]
Internet-Draft Preliminary LISP Threat Analysis July 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 January 9, 2008 [Page 15]
Internet-Draft Preliminary LISP Threat Analysis July 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 January 9, 2008 [Page 16]
Html markup produced by rfcmarkup 1.128, available from
https://tools.ietf.org/tools/rfcmarkup/