Network Working Group D. Saucez
Internet-Draft Universite catholique de Louvain
Intended status: Standards Track L. Iannone
Expires: April 22, 2010 TU Berlin - Deutsche Telekom
Laboratories AG
O. Bonaventure
Universite catholique de Louvain
October 19, 2009
Notes on LISP Security Threats and Requirements
draft-saucez-lisp-security-00.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
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 April 22, 2010.
Copyright Notice
Saucez, et al. Expires April 22, 2010 [Page 1]
Internet-Draft LISP Security October 2009
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
The present document is a preliminary collection of notes about LISP
security threats and requirements. Its purpose is to start a
discussion on the subject among people that have shown interest in
working on the matter.
Saucez, et al. Expires April 22, 2010 [Page 2]
Internet-Draft LISP Security October 2009
Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4
4. Data-plane threats . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Security of the data stream . . . . . . . . . . . . . . . 5
4.2. LISP-encapsulated packet spoofing . . . . . . . . . . . . 5
4.3. Nonce . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.4. LISP-Cache threats . . . . . . . . . . . . . . . . . . . . 6
4.4.1. LISP-Cache poisoning . . . . . . . . . . . . . . . . . 6
4.4.2. LISP-Cache overflow . . . . . . . . . . . . . . . . . 7
4.5. LISP-Database threats . . . . . . . . . . . . . . . . . . 8
4.6. DoS threats . . . . . . . . . . . . . . . . . . . . . . . 8
4.6.1. Locator Status Bits . . . . . . . . . . . . . . . . . 8
4.6.2. Gleaning . . . . . . . . . . . . . . . . . . . . . . . 8
4.6.3. Rate Limitation . . . . . . . . . . . . . . . . . . . 9
4.6.4. Mapping System and Filtering . . . . . . . . . . . . . 9
4.7. Other Attacks . . . . . . . . . . . . . . . . . . . . . . 10
4.7.1. Time-shifted attacks . . . . . . . . . . . . . . . . . 10
4.7.2. Amplification attacks . . . . . . . . . . . . . . . . 10
5. Control-plane threats . . . . . . . . . . . . . . . . . . . . 10
5.1. Control-plane Requirements . . . . . . . . . . . . . . . . 11
5.2. LISP-Database coherence . . . . . . . . . . . . . . . . . 11
5.3. LISP Map Server . . . . . . . . . . . . . . . . . . . . . 12
6. Interaction between Data- and Control-plane . . . . . . . . . 12
6.1. Data-plane side effects on the control-plane . . . . . . . 12
6.2. Control-plane side effects on the data-plane . . . . . . . 12
6.3. Data-plane threats leveraging on the control-plane . . . . 12
6.4. Control-plane threats leveraging on the data-plane . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
10. Normative References . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Saucez, et al. Expires April 22, 2010 [Page 3]
Internet-Draft LISP Security October 2009
1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. Introduction
The Locator/ID Separation Protocol (LISP) is defined in
draft-ietf-lisp-05.txt [I-D.ietf-lisp]. The present document aims at
identifying threats in the current LISP specification and possibly
list a set of requirements or mechanism needed to improve its
security. A preliminary security analysis on LISP has been conducted
by M. Bagnulo in [I-D.bagnulo-lisp-threat].
This document is split in two main parts; one concerning the data-
plane and one concerning the control-Plane.
The LISP data-plane consists of LISP packet encapsulation,
decapsulation, and forwarding and includes the LISP-Cache and LISP-
Database data structures used to perform these operations. The
present document will try to analyze the possible threats of the
data-plane.
The LISP control-plane consists in the mapping distribution system,
which can be one of the mapping distribution protocols proposed so
far (e.g., [I-D.ietf-lisp-ms], [I-D.ietf-lisp-alt],
[I-D.meyer-lisp-cons], and [I-D.lear-lisp-nerd] ), and the set of
Map-Request and Map-Reply messages. The present document will not
analyze all possible threats of each specific mapping distribution
protocol. Rather, this document will try to find a common set of
requirements that every present and future mapping distribution
protocol should satisfy in order to reduce as much as possible
threats related to the LISP control-plane.
3. Definition of Terms
See [I-D.ietf-lisp]
4. Data-plane threats
This section contains some threats and attacks related to the LISP
data-plane. By LISP data-plane it is intended the operations of
encapsulation, decapsulation, and forwarding as well as the content
of the LISP-Cache and LISP-Database as specified in the original LISP
Saucez, et al. Expires April 22, 2010 [Page 4]
Internet-Draft LISP Security October 2009
document ([I-D.ietf-lisp]).
4.1. Security of the data stream
In some context it could be necessary to secure the data stream that
is LISP encapsulated. This can be achieved with two different
approaches:
o Securing messages. In this approach a field needs to be added to
the LISP header in order to secure the content.
o Securing the transport protocol. An example of this approach is
the use of IPSEC to secure the content of the original, non LISP-
encapsulated, packet.
What is the approach suitable in the LISP context?
4.2. LISP-encapsulated packet spoofing
Like any other type of packet in the Internet, LISP encapsulated
packets can also be spoofed. Generally the term "spoofed packet"
indicates a packet containing a source IP address which is not the
one of the actual originator of the packet. Since LISP uses
encapsulation, this translates in two types of spoofing:
o EID Spoofing: The originator of the packet puts in it a spoofed
EID. The packet will be normally encapsulated by the ITR of the
site.
o RLOC Spoofing: The originator of the packet generates directly a
LISP-encapsulated packet with a spoofed source RLOC.
Note that the two types of spoofing are not mutually exclusive,
rather all combinations are possible and can be used to perform
several kind of attacks.
The work done in the SAVI WG ([SAVI]) can be useful in mitigating
spoofing.
It is worth to notice that in the context of LISP, there is also the
possibility to spoof part of the content of the LISP-specific header
in order to perform some attacks. The various possibilities are
listed in the following sections, while describing the possible
attacks.
Saucez, et al. Expires April 22, 2010 [Page 5]
Internet-Draft LISP Security October 2009
4.3. Nonce
The "Nonce" gives some basic security support by acting as a "session
cookie", similar to what is used in L2TP
([I-D.ietf-l2tpext-l2tp-base]). The use of the Nonce to mitigate
some of the possible attacks is described in the following sections.
There should be an explicit discussion on the limits of the Nonce?
4.4. LISP-Cache threats
A key component of the overall LISP architecture is the LISP-Cache.
The LISP-Cache is the data structure that stores the bindings between
EID and RLOC (namely the "mappings") to be used later on. Attacks
against this data structure can happen either when the mappings are
first installed in the cache (see also Section 5) or by corrupting
(poisoning) the mappings already present in the cache.
4.4.1. LISP-Cache poisoning
The content of the LISP-Cache can be poisoned by spoofing LISP
encapsulated packets. Example of LISP-Cache poisoning are:
Fake mapping: The cache contains entirely fake mappings that do not
originate from an authoritative mapping server. This can be
achieved either through gleaning as described in Section 4.6.2
or by attacking the control-plane as described in Section 5.
EID Poisoning: The EID-Prefix in a specific mapping is not owned by
the originator of the entry. Similarly to the previous case,
this can be achieved either through gleaning as described in
Section 4.6.2 or by attacking the control-plane as described in
Section 5.
EID redirection/RLOC poisoning: The EID-Prefix in the mapping is not
bound to (located by) the set of RLOCs present in the mapping.
This can result in packets being redirected elsewhere,
eavesdropped, or even blackholed. Note that not necessarily
all RLOCs are fake/spoofed. The attack works also if only part
of the RLOCs, the highest priority ones, are compromised.
Again, this can be achieved either through the gleaning as
described in Section 4.6.2 or by attacking the control-plane as
described in Section 5.
Reachability poisoning: The reachability information stored in the
mapping could be poisoned, redirecting the packets to a subset
of the RLOCs (or even stopping it if locator status bits are
all set to 0). If reachability information is not verified
Saucez, et al. Expires April 22, 2010 [Page 6]
Internet-Draft LISP Security October 2009
through the control-plane this attack can be simply achieved by
sending a spoofed packet with swapped or all locator status
bits reset. The same result can be obtained by attacking the
control-plane as described in Section 5.
Traffic Engineering information poisoning: The LISP protocol defines
two attributes associated to each RLOC in order to perform
inbound Traffic Engineering: namely priority and weight. By
injecting fake TE attributes, the attacker is able to break
load balancing policies and concentrate all the traffic on a
single RLOC or put more load on a RLOC than what is expected,
creating congestion. Corrupting the TE attributes can be
achieved by attacking the control-plane as described in
Section 5.
Mapping TTL poisoning: The LISP protocol associates a Time-To-Live
to each mapping that, once expired, allows to delete a mapping
from the LISP-Cache (or forces a Map-Request/Map-Reply exchange
to refresh it if still needed). By injecting fake TTL values,
an attacker can either shrink the Cache (using very short TTL),
thus creating an excess of cache miss causing a DoS on the
mapping system, or it can increase the size of the cache by
putting very high TTL values, up to a cache overflow (see
Section 4.4.2). Corrupting the TTL can be achieved by
attacking the control-plane as described in Section 5.
If the above listed attacks succeed, the attacker has the means of
controlling the traffic.
4.4.2. LISP-Cache overflow
Depending on how the LISP-cache is managed (e.g., LRU vs. LFU) and
depending on its size, an attacker can try to fill the cache with
fake mappings. Once the cache is full, some mappings will be
replaced by new fake ones, causing traffic disruption.
This can be achieved either through the gleaning as described in
Section 4.6.2 or by attacking the control-plane as described in
Section 5.
Another way to generate a LISP-Cache overflow is by injecting mapping
with a fake and very large TTL value. In this case the cache will
keep a large amount of mappings ending with a completely full cache.
This type of attack can also be performed through the control-plane.
Saucez, et al. Expires April 22, 2010 [Page 7]
Internet-Draft LISP Security October 2009
4.5. LISP-Database threats
The LISP-Database data structure is meant to contain the mappings
that are "owned" locally, i.e., the mappings that are used for
selecting the source RLOC when encapsulating, and binding the EID-
Prefix behind the xTR and the RLOCs present on the xTR.
The simplest way to fill the LISP-Database is by configuration on
each single xTR. This secure the data structure as much as the xTR
itself is robust to intrusions.
Nevertheless, part of the information contained in the mappings that
are in the LISP-Database are subject to change in time, e.g.,
reachability information, TE attributes, etc. The way mappings are
updated can open security breaches allowing attackers to poison or
corrupt the LISP-Database in a way similar to the LISP-Cache. These
attacks are more related to the control-plane and will be discussed
in Section 5.
4.6. DoS threats
This section tries to list all possible DoS attacks and suggests,
when possible, mechanisms that help in mitigating the threat.
4.6.1. Locator Status Bits
Locator Status Bits should be used only as a hint, meaning that upon
reception of a packet having Locator Status Bits different from what
is stored in the mapping present in the LISP-Cache, a Map-Request is
issued in order to have confirmation of the change. However, with
this behavior, an attacker can send a burst of packets with different
locato status bits in order to trigger a burst of Map-Request
packets, thus again attacking the control-plane. The echo nonce
machanisme is proposed, we still have to analyze it in details.
Several counter-measures can be introduced to mitigate its effects:
o Ignore Locator Status Bits if nonce does not change.
o Rate limitation can be used to reduce the number of issued Map-
Request packets.
4.6.2. Gleaning
Gleaning is used to install in the LISP-Cache a partial mapping
created by gleaning the source EID and source RLOC from the first
packet of a flow. The mapping is considered "partial" because it
just associate an EID (/32) to one single RLOC, not the EID-Prefix
the EID belongs to with the complete set of RLOCs. Gleaning can be
Saucez, et al. Expires April 22, 2010 [Page 8]
Internet-Draft LISP Security October 2009
used to perform several different attacks:
o LISP-Cache poisoning: an attacker can use gleaning to install fake
mappings in the LISP-Cache (by spoofing the EID). See LISP-Cache
poisoning in Section 4.4.1.
o LISP-Cache overflow: an attacker can use gleaning to install a
large number of mappings in the LISP-Cache until filling it up.
See LISP-Cache overflow in Section 4.4.2. Since the mapping
installed in the LISP-Cache is not for a EID-Prefix but for a full
EID, by sending a burst of packet for several different spoofed
EIDs, an attacker could end up filling the Cache.
o Map-Request burst: if for each mapping installed by a gleaning a
Map-Request is issued to retrieve the full mapping, an attacker
can send a burst of packets with different EIDs generating a burst
of Map-Request. Note that in this case, if Map-Request rate
limitation is done on a per-EID basis, the attacker can easily
bypass the rate limitation by putting different EIDs in the
packets causing the gleaning.
Possible counter-measure to mitigate this issue:
o The LISP-Cache poisoning and overflow issues can be solved by
filtering spoofed EIDs on the ITR (see Section 4.2).
o To reduce the Map-Request burst an approach is to send a Map-
Request only if a certain amount of packets has been sent using
the gleaned entry, as suggested in [Saucez09].
4.6.3. Rate Limitation
The Rate-Limitation policy, used to reduce the effects of some types
of DoS attacks can be itself used for a DoS attack. An attacker can
send some fake packets in order to generate a burst of Map-Request
packets that will be rate limited. When a legitimate packet
generates a legitimate Map-Request, this will be delayed or dropped
due to rate limitation, causing an increased latency.
o Any solution for this?
4.6.4. Mapping System and Filtering
The use of some form of filtering can help in avoid or at least
mitigate some types of attacks.
On ITRs, packets should be encapsulated only if the source EID is
effectively part of the EID-Prefix downstream the ITR. Further,
Saucez, et al. Expires April 22, 2010 [Page 9]
Internet-Draft LISP Security October 2009
still on ITRs, packets should be encapsulated only if a mapping
obtained from the mapping system is present in the LIP-Cache.
On ETRs, packets should be decapsulated only if the destination EID
is effectively part of the EID-Prefix downstream the ETR. Further,
still on ETRs, packets should be decapsulated only if a mapping for
the source EID is present in the LISP-Cache and has been obtained
through the mapping system (not gleaned).
Note that this filtering, since complete mappings need to be
installed in both ITRs and ETRs, can introduce a higher connection
setup latency and hence potentially more packets drops due to the
lack of mappings in the LISP-Cache.
4.7. Other Attacks
4.7.1. Time-shifted attacks
A time-shifted attack is an attack where the attacker is temporarily
on the path between two communicating hosts. While it is on-path,
the attacker sends specially crafted packets or modifies packets
exchanged by the communicating hosts in order to disturb the flow of
packets (e.g., by performing a man in the middle attack). An
important issue for time shifted attacks is the duration of the
attack once the attacker has left the path between the two
communicating hosts.
4.7.2. Amplification attacks
An amplification attack occurs when an attacker sends a small packet
with a spoofed source to a host or router that replies by sending a
longer packet to the spoofed source. To reduce the impact of such
attacks, protocol designers try to avoid sending a long response
after having received a small packet from a potentially spoofed
source.
5. Control-plane threats
As pointed out in the previous sections, a good share of attacks can
be avoided by securing the LISP control plane.
Here the focus is not to analyze the security threats of any specific
mapping distribution protocol. Rather, the focus is to find a common
set of requirements that existing or future mapping distribution
protocols have to fulfill in order provide a sufficient level of
security.
Saucez, et al. Expires April 22, 2010 [Page 10]
Internet-Draft LISP Security October 2009
The LISP Map Server protocol will instead be analyzed since it is not
related to any specific mapping distribution protocol.
Work and experience performed in the DNSSEC [RFC4033] and SIDR [SIDR]
can be useful here.
5.1. Control-plane Requirements
o Authenticate the origin of a message.
o Identify the origin of a message.
o Prove that the mapping is generated by the owner of the EID or a
third party allowed to generate such a mapping.
o Inject mappings in the mapping system only if the EID is allowed
to be in the mapping system.
o Prove that the RLOCs associate to a mapping belong to the xTRs
owning the mapping's EID.
o Low message overhead.
o Low traffic overhead.
o Low time overhead (avoid multiple RTTs).
o Other?
5.2. LISP-Database coherence
The mappings present on the LISP-Database of the different xTRs of a
site should always be coherent. An attacker should not be able to
install different mappings for different xTRs.
A simple approach is to have a central authority in the site that
pushes all the mappings in the xTRs. When a xTR decides to change
something it informs the central authority, which will push the
information to the other xTRs.
Each xTR is authoritative on the reachability of its locator. An xTR
is not allowed to send updates to the central entity only if it is
one of its RLOC.
The central authority knows the configuration which RLOC is owned by
which xTR.
All of this does not prevent from securing the exchanges between the
Saucez, et al. Expires April 22, 2010 [Page 11]
Internet-Draft LISP Security October 2009
xTRs and the central authority in order to avoid spoofing attacks.
5.3. LISP Map Server
The LISP Map Server is a fundamental building block of the whole LISP
architecture, providing an additional level of indirection allowing
to run mapping distribution protocols on machines different from
xTRs. From this point of view it can be considered a security
improvement since xTR are not directly involved in the mapping
distribution system.
Things to look closer:
o Threats concerning messages.
o DoS attacks.
o Threats concerning LISP Map Server with caching.
o Others?
6. Interaction between Data- and Control-plane
It is clear that attacks targeting the data-plane can have side-
effects on the control-plane and vice-versa. Furthermore, attacks to
the control-plane can be performed leveraging on the data-plane and
vice-versa.
An analysis of the possible threats has been performed in the
previous sections. Here we just characterize them following the
above mentioned classification.
6.1. Data-plane side effects on the control-plane
To be done.
6.2. Control-plane side effects on the data-plane
To be done.
6.3. Data-plane threats leveraging on the control-plane
To be done.
Saucez, et al. Expires April 22, 2010 [Page 12]
Internet-Draft LISP Security October 2009
6.4. Control-plane threats leveraging on the data-plane
To be done.
7. IANA Considerations
This document makes no request of the IANA.
8. Security Considerations
Security considerations are the core of this document and do not need
to be further discussed in this section.
9. Acknowledgments
This work has been partially supported by the INFSO-ICT-216372
TRILOGY Project (www.trilogy-project.org).
10. Normative References
[I-D.bagnulo-lisp-threat]
Bagnulo, M., "Preliminary LISP Threat Analysis",
draft-bagnulo-lisp-threat-01 (work in progress),
July 2007.
[I-D.ietf-l2tpext-l2tp-base]
Lau, J., "Layer Two Tunneling Protocol (Version 3)",
draft-ietf-l2tpext-l2tp-base-15 (work in progress),
December 2004.
[I-D.ietf-lisp]
Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
"Locator/ID Separation Protocol (LISP)",
draft-ietf-lisp-05 (work in progress), September 2009.
[I-D.ietf-lisp-alt]
Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "LISP
Alternative Topology (LISP+ALT)", draft-ietf-lisp-alt-01
(work in progress), May 2009.
[I-D.ietf-lisp-ms]
Fuller, V. and D. Farinacci, "LISP Map Server",
draft-ietf-lisp-ms-04 (work in progress), October 2009.
Saucez, et al. Expires April 22, 2010 [Page 13]
Internet-Draft LISP Security October 2009
[I-D.lear-lisp-nerd]
Lear, E., "NERD: A Not-so-novel EID to RLOC Database",
draft-lear-lisp-nerd-04 (work in progress), April 2008.
[I-D.meyer-lisp-cons]
Brim, S., "LISP-CONS: A Content distribution Overlay
Network Service for LISP", draft-meyer-lisp-cons-04 (work
in progress), April 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005.
[SAVI] IETF, "Source Address Validation Improvements Working
Group", <http://tools.ietf.org/wg/savi/>.
[SIDR] IETF, "Secure Inter-Domain Routing Working Group",
<http://tools.ietf.org/wg/sidr/>.
[Saucez09]
Saucez, D. and L. Iannone, "How to mitigate the effect of
scans on mapping systems", Submitted to the Trilogy
Summer School on Future Internet.
Authors' Addresses
Damien Saucez
Universite catholique de Louvain
Place St. Barbe 2
Louvain la Neuve
Belgium
Email: damien.saucez@uclouvain.be
Luigi Iannone
TU Berlin - Deutsche Telekom Laboratories AG
Ernst-Reuter Platz 7
Berlin
Germany
Email: luigi@net.t-labs.tu-berlin.de
Saucez, et al. Expires April 22, 2010 [Page 14]
Internet-Draft LISP Security October 2009
Olivier Bonaventure
Universite catholique de Louvain
Place St. Barbe 2
Louvain la Neuve
Belgium
Email: olivier.bonaventure@uclouvain.be
Saucez, et al. Expires April 22, 2010 [Page 15]