--- 1/draft-ietf-lisp-threats-04.txt 2013-08-29 14:14:23.196207076 -0700
+++ 2/draft-ietf-lisp-threats-05.txt 2013-08-29 14:14:23.268208895 -0700
@@ -1,49 +1,49 @@
Network Working Group D. Saucez
Internet-Draft INRIA
Intended status: Informational L. Iannone
-Expires: August 29, 2013 Telecom ParisTech
+Expires: March 2, 2014 Telecom ParisTech
O. Bonaventure
Universite catholique de Louvain
- February 25, 2013
+ August 29, 2013
LISP Threats Analysis
- draft-ietf-lisp-threats-04.txt
+ draft-ietf-lisp-threats-05.txt
Abstract
- This document analyzes the potential threats against the security of
- the Locator/Identifier Separation Protocol (LISP) if deployed in the
- Internet. This document proposes a set of recommendations to
- mitigate the identified security risks and keep a security level
- equivalent to what is observed in the Internet today (i.e., without
- LISP). By following the recommendations of this draft a LISP
- deployment can achieve a security level that is comparable to the
- existing Internet architecture.
+ This document discusses potential security concerns with the Locator/
+ Identifier Separation Protocol (LISP) if deployed in the Internet and
+ proposes a set of recommendations to mitigate the identified threats
+ and to reach a level of security equivalent to what is observed in
+ the Internet today (i.e., without LISP). By following the
+ recommendations of this draft a LISP deployment can achieve a
+ security level that is comparable to the existing Internet
+ architecture.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
- This Internet-Draft will expire on August 29, 2013.
+ This Internet-Draft will expire on March 2, 2014.
Copyright Notice
Copyright (c) 2013 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
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
@@ -51,62 +51,62 @@
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4
3. On-path Attackers . . . . . . . . . . . . . . . . . . . . . . 4
- 4. Off-Path Attackers: Reference Environment . . . . . . . . . . 5
+ 4. Off-Path Attackers: Reference Environment . . . . . . . . . . 4
5. Data-Plane Threats . . . . . . . . . . . . . . . . . . . . . . 6
- 5.1. EID-to-RLOC Database Threats . . . . . . . . . . . . . . . 7
+ 5.1. EID-to-RLOC Database Threats . . . . . . . . . . . . . . . 6
5.2. EID-to-RLOC Cache Threats . . . . . . . . . . . . . . . . 7
5.2.1. EID-to-RLOC Cache poisoning . . . . . . . . . . . . . 7
5.2.2. EID-to-RLOC Cache overflow . . . . . . . . . . . . . . 9
- 5.3. Attacks not leveraging on the LISP header . . . . . . . . 10
+ 5.3. Attacks not leveraging on the LISP header . . . . . . . . 9
5.4. Attacks leveraging on the LISP header . . . . . . . . . . 10
5.4.1. Attacks using the Locator Status Bits . . . . . . . . 10
- 5.4.2. Attacks using the Map-Version bit . . . . . . . . . . 12
+ 5.4.2. Attacks using the Map-Version bit . . . . . . . . . . 11
5.4.3. Attacks using the Nonce-Present and the Echo-Nonce
- bits . . . . . . . . . . . . . . . . . . . . . . . . . 13
+ bits . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.4.4. Attacks using the Instance ID bits . . . . . . . . . . 14
6. Control Plane Threats . . . . . . . . . . . . . . . . . . . . 14
6.1. Attacks with Map-Request messages . . . . . . . . . . . . 14
6.2. Attacks with Map-Reply messages . . . . . . . . . . . . . 16
6.3. Gleaning Attacks . . . . . . . . . . . . . . . . . . . . . 17
7. Threats concerning Interworking . . . . . . . . . . . . . . . 18
8. Threats with Malicious xTRs . . . . . . . . . . . . . . . . . 19
- 9. Security of the Proposed Mapping Systems . . . . . . . . . . . 23
- 9.1. LISP+ALT . . . . . . . . . . . . . . . . . . . . . . . . . 23
+ 9. Security of the Proposed Mapping Systems . . . . . . . . . . . 22
+ 9.1. LISP+ALT . . . . . . . . . . . . . . . . . . . . . . . . . 22
9.2. LISP-DDT . . . . . . . . . . . . . . . . . . . . . . . . . 24
10. Threats concerning LISP-MS . . . . . . . . . . . . . . . . . . 25
10.1. Map Server . . . . . . . . . . . . . . . . . . . . . . . . 25
10.2. Map Resolver . . . . . . . . . . . . . . . . . . . . . . . 26
- 11. Security Recommendations . . . . . . . . . . . . . . . . . . . 28
+ 11. Security Recommendations . . . . . . . . . . . . . . . . . . . 27
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
13. Security Considerations . . . . . . . . . . . . . . . . . . . 30
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30
- 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
- 15.1. Normative References . . . . . . . . . . . . . . . . . . . 31
+ 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
+ 15.1. Normative References . . . . . . . . . . . . . . . . . . . 30
15.2. Informative References . . . . . . . . . . . . . . . . . . 31
Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 32
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
1. Introduction
The Locator/ID Separation Protocol (LISP) is defined in [RFC6830].
The present document assesses the security level and identifies
security threats in the LISP specification if LISP is deployed in the
Internet (i.e., a public non-trustable environment). As a result of
- the performed analysis, the document determines the severity of the
+ the performed analysis, the document discusses the severity of the
threats and proposes recommendations to reach the same level of
security in LISP than in Internet today (e.g., without LISP).
The document is composed of three main parts: the first discussing
the LISP data-plane; while the second discussing the LISP control-
plane. The final part summarizes the recommendations to prevent the
identified threats.
The LISP data-plane consists of LISP packet encapsulation,
decapsulation, and forwarding and includes the EID-to-RLOC Cache and
@@ -127,48 +127,29 @@
mapping system described in [I-D.ietf-lisp-ddt]. The reading of
these documents is a prerequisite for understanding the present
document.
Unless otherwise stated, the document assumes a generic IP service
and does not discuss the difference, from a security viewpoint,
between using IPv4 or IPv6.
This document has identified several threats on LISP in the case of
public deployments. However, most of the threats can be prevented
- with careful deployment and configuration. Moreover, several threats
- are introduced by optimization techniques that can be deactivated in
- public deployments of LISP without alteration of its functioning as
- these techniques are designed for LISP deployments in private
- trustable environments. Finally, this document has not identified
- any threats that would require a change in the LISP protocol or
- architecture.
+ with careful deployment and configuration. A general recommendation
+ is to deactivate every feature that is not necessary in the
+ deployment of interest and carefully verify the validity of the
+ information obtained from third parties. Finally, this document has
+ not identified any threats that would require a change in the LISP
+ protocol or architecture.
2. Definition of Terms
- Severity level: this document specifies the severity level of every
- identified threat. We identified four severity levels for the
- threats.
-
- Level 0: the threat is not introduced by LISP and is equivalent to
- what is encountered without LISP.
-
- Level 1: the threat is introduced by LISP but can be neutralized by
- configuration or deployment techniques, i.e., LISP protocol and
- architecture does not need to be reconsidered for public
- deployment.
-
- Level 2: the threat is introduced by LISP but can be avoided by
- deactivating the feature in public deployment.
-
- Level 3: the threat is introduced by LISP and cannot be avoided
- without changing the LISP specification or architecture.
-
The present document does not introduce any other new term, compared
to the main LISP specification. For a complete list of terms please
refer to [RFC6830].
3. On-path Attackers
On-path attackers are attackers that are able to capture and modify
all the packets exchanged between an Ingress Tunnel Router (ITR) and
an Egress Tunnel Router (ETR). To cope with such an attacker,
cryptographic techniques such as those used by IPSec ([RFC4301]) are
@@ -293,33 +274,31 @@
"behind" means that at least one of the xTR's globally visible IP
addresses is a RLOC for those EID-Prefixes.
As described in [RFC6830], the EID-to-RLOC Database content is
determined by configuration. This means that the only way to attack
this data structure is by gaining privileged access to the xTR. As
such, it is out of the scope of LISP to propose any mechanism to
protect routers and, hence, it is no further analyzed in this
document.
- Severity level 0.
-
5.2. EID-to-RLOC Cache Threats
The EID-to-RLOC Cache (also called the Map-Cache) is the data
structure that stores a copy of the mappings retrieved from a remote
ETR's mapping database via the LISP control plane. Attacks against
this data structure could happen either when the mappings are first
installed in the cache (see also Section 6) or by corrupting
(poisoning) the mappings already present in the cache.
- Severity level 2. The severity level of EID-to-RLOC Cache Threats
- depends on the attack vector as described below.
+ The severity level of EID-to-RLOC Cache Threats depends on the attack
+ vector as described below.
5.2.1. EID-to-RLOC Cache poisoning
The content of the EID-to-RLOC Cache could be poisoned by spoofing
LISP encapsulated packets. Examples of EID-to-RLOC Cache poisoning
are:
Fake mapping: The cache contains entirely fake mappings that do not
originate from an authoritative mapping server. This could be
achieved either through gleaning as described in Section 6.3 or
@@ -445,33 +424,33 @@
The destination address of the encapsulated packet could be LR3 or
LR4. When the LISP ETR that serves HB receives the encapsulated
packet, it can consult its EID-to-RLOC Cache and verify that NSA is
not a valid source address for LISP encapsulated packets containing a
packet sent by HA. This verification is only possible if the ETR
already has a valid mapping for HA. Otherwise, and to avoid such
data packet injection attacks, the LISP ETR should reject the packet
and possibly query the mapping system to obtain a mapping for the
encapsulated source EID (HA).
- Severity level 1: use well known anti-spoofing techniques and
- configure ETRs to verify the that RLOCs and EIDs are consistent with
- the entries in the EID-to-RLOC Cache.
+ The risk can be reduced by using well known anti-spoofing techniques
+ and configuring ETRs to verify the that RLOCs and EIDs are consistent
+ with the entries in the EID-to-RLOC Cache.
5.4. Attacks leveraging on the LISP header
The main LISP document [RFC6830] defines several flags that modify
the interpretation of the LISP header in data packets. In this
section, we discuss how an off-path attacker could exploit this LISP
header.
- Severity level 2. The severity level of attacks leveraging on the
- LISP header depends on the attack vector as described below.
+ The severity level of attacks leveraging on the LISP header depends
+ on the attack vector as described below.
5.4.1. Attacks using the Locator Status Bits
When the L bit is set to 1, it indicates that the second 32-bits
longword of the LISP header contains the Locator Status Bits. In
this field, each bit position reflects the status of one of the RLOCs
mapped to the source EID found in the encapsulated packet. In
particular, a packet with the L bit set and all Locator Status Bits
set to zero indicates that none of the locators of the encapsulated
source EID are reachable. The reaction of a LISP ETR that receives
@@ -511,23 +490,23 @@
one of the addresses listed as RLOCs for the source EID.
Nevertheless, in this case a Map-Request should be sent, which could
be used to perform Denial of Service attacks. Indeed an attacker
could frequently change the Locator Status Bits in order to trigger a
large amount of Map-Requests. Rate limitation, as described in
[RFC6830], if implemented in a very simple way a single bucket for
all triggered control plane messages, does not allow sending high
number of such a request, resulting in the attacker saturating the
rate with these spoofed packets.
- Severity level 2: to avoid any risk, Locator Status Bits should be
- deactivated in public deployments of LISP. Deactivating LSB does not
- reduce LISP functionality.
+ Assuming the correct deployment of anti-spoofing techniques, every
+ reachability change discovered with LSB SHOULD be verified (e.g.,
+ using routing information base, or low frequency probing).
5.4.2. Attacks using the Map-Version bit
The optional Map-Version bit is used to indicate whether the low-
order 24 bits of the first 32 bits longword of the LISP header
contain a Source and Destination Map-Version. When a LISP ETR
receives a LISP encapsulated packet with the Map-Version bit set to
1, the following actions are taken:
o It compares the Destination Map-Version found in the header with
@@ -561,23 +540,22 @@
policy, the ETR might consume its entire rate by sending Map-Request
messages in response to these spoofed packets.
A non-spoofing off-path attacker (NSA) could not success in such an
attack if the destination xTR rejects the LISP encapsulated packets
that are not sent by one of the RLOCs mapped to the included source
EID. If it is not the case, the attacker could be able to perform
attacks concerning the Destination Map Version number as for the
spoofing off-path attacker (SA).
- Severity level 1: the correct deployment of anti-spoofing and rate
- limitation techniques prevents the attacks leveraging on the Map-
- Version.
+ The correct deployment of anti-spoofing and rate limitation
+ techniques prevents the attacks leveraging on the Map-Version.
5.4.3. Attacks using the Nonce-Present and the Echo-Nonce bits
The Nonce-Present and Echo-Nonce bits are used when verifying the
reachability of a remote ETR. Assume that LR3 wants to verify that
LR1 receives the packets that it sends. LR3 can set the Echo-Nonce
and the Nonce-Present bits in LISP data encapsulated packets and
include a random nonce in these packets. Upon reception of these
packets, LR1 will store the nonce sent by LR3 and echo it when it
returns LISP encapsulated data packets to LR3.
@@ -616,54 +594,52 @@
will consider the ETR not reachable. The success of this test will
of course depend on the ratio between the amount of packets sent by
the legitimate ITR and the spoofing off-path attacker (SA).
Packets sent by a non-spoofing off-path attacker (NSA) can cause
similar problem if no check is done with the EID-to-RLOC Cache (see
Section 5.3 for the EID-to-RLOC Cache check). Otherwise, if the
check is performed the packets will be rejected by the ETR that
receives them and cannot cause problems.
- Severity level 2: to avoid any problem, echo nonce should be
- deactivated. Deactivating echo-nonce does not reduce LISP
- functionality as it is an optimization for symmetric data flow path
- and because other techniques exist to test the reachability of a
- RLOC.
+ Assuming the correct deployment of anti-spoofing techniques, every
+ reachability change discovered with echo-nonce SHOULD be verified
+ (e.g., using routing information base, or low frequency probing).
5.4.4. Attacks using the Instance ID bits
LISP allows to carry in its header a 24-bits value called "Instance
ID" and used on the ITR to indicate which private Instance ID has
been used for encapsulation, while on the ETR can be used to select
the forwarding table used for forwarding the decapsulated packet.
Even if an off-path attacker could randomly guess a valid Instance ID
value, there is no LISP specific problem. Obviously the attacker
could be now able to reach hosts that are only reachable through the
routing table identified by the attacked Instance ID, however, end-
system security is out of the scope of this document. Nevertheless,
access lists can be configured to protect the network from Instance
ID based attacks.
- Severity level 1: the correct deployment of access control lists and
- firewalls prevent the attacks leveraging on the Instance ID.
+ The correct deployment of access control lists and firewalls prevent
+ the attacks leveraging on the Instance ID.
6. Control Plane Threats
In this section, we discuss the different types of attacks that could
occur when an off-path attacker sends control plane packets. We
focus on the packets that are sent directly to the ETR and do not
analyze the particularities of a LISP mapping system. The LISP+ALT
and LISP-DDT mapping systems are discussed in Section 9.
- Severity level 2. The severity level of attacks on the LISP control-
- plane depends on the attack vector as described below.
+ The severity of attacks on the LISP control-plane depends on the
+ attack vector as described below.
6.1. Attacks with Map-Request messages
An off-path attacker could send Map-Request packets to a victim ETR.
In theory, a Map-Request packet is only used to solicit an answer and
as such it should not lead to security problems. However, the LISP
specification [RFC6830] contains several particularities that could
be exploited by an off-path attacker.
The first possible exploitation is the P bit. The P bit is used to
@@ -716,38 +693,33 @@
of a Map-Request message with the SMR bit, an ETR must return to the
source of the Map-Request message a Map-Request message to retrieve
the corresponding mapping. This raises similar problems as the P bit
discussed above except that as the Map-Request messages are smaller
than Map-Reply messages, the risk of amplification attacks is
reduced. This is not true anymore if the ETR append to the Map-
Request messages its own Map-Records. This mechanism is meant to
reduce the delay in mapping distribution since mapping information is
provided in the Map-Request message.
- Severity level 1: the correct deployment of anti-spoofing and rate
- limitation techniques prevents the attacks leveraging the Map-Request
- message.
+ The correct deployment of anti-spoofing and rate limitation
+ techniques prevents the attacks leveraging the Map-Request message.
Furthermore, appending Map-Records to Map-Request messages represents
a major security risk since an off-path attacker could generate a
(spoofed or not) Map-Request message and include in the Map-Reply
portion of the message mapping for EID prefixes that it does not
serve. This could lead to various types of redirection and denial of
- service attacks. An xTR should not process the Map-Records
- information that it receives in a Map-Request message. As it is a
- performance optimization, we recommend to deactivate this
- functionality in public LISP deployments.
+ service attacks.
- Severity level 2: to avoid any risk, appending Map-Records to Map-
- Request messages should be deactivated in public deployments of LISP.
- Deactivating appending Map-Records to Map-Request messages does not
- reduce LISP functionality.
+ A mappings learned from a Map-Request message appending Map-Records
+ SHOULD be verified, particularly if it overrides mappings previously
+ installed in the EID-to-RLOC cache of the ITR.
6.2. Attacks with Map-Reply messages
In this section we analyze the attacks that could occur when an off-
path attacker sends directly Map-Reply messages to ETRs without using
one of the proposed LISP mapping systems.
There are two different types of Map-Reply messages:
Positive Map-Reply: These messages contain a Map-Record binding an
@@ -772,22 +744,22 @@
The nonce only confirms that the map-reply received was sent in
response to a map-request sent, it does not validate the contents of
that map-reply.
In addition, an attacker could perform EID-to-RLOC Cache overflow
attack by de-aggregating (i.e., splitting an EID prefix into
artificially smaller EID prefixes) either positive or negative
mappings.
- Severity level 1: the correct deployment of anti-spoofing techniques
- prevents attacks leveraging the Map-Reply message.
+ The correct deployment of anti-spoofing techniques prevents attacks
+ leveraging the Map-Reply message.
6.3. Gleaning Attacks
A third type of attack involves the gleaning mechanism proposed in
[RFC6830] and discussed in [Saucez09]. In order to reduce the time
required to obtain a mapping, [RFC6830] allows an ITR to learn a
mapping from the LISP data encapsulated packets and the Map-Request
packets that it receives. LISP data encapsulated packet contains a
source RLOC, destination RLOC, source EID and destination EID. When
an ITR receives a data encapsulated packet coming from a source EID
@@ -833,23 +806,23 @@
control plane rate limit. This will extend the duration of the
gleaned entry. If host HA establishes a flow with host HB at that
time, the packets that they exchange will first pass through the
attacker.
In both cases, the attack only lasts for a few seconds (unless the
attacker is able to exhaust the rate limitation). However it should
be noted that today a large amount of packets might be exchanged
during even a small fraction of time.
- Severity level 2: to avoid any risk, gleaning should be deactivated
- in public deployments of LISP. Deactivating gleaning does not reduce
- LISP functionality.
+ To limit the risk of attacks leveraging gleaning, the scope of a
+ gleaned mapping should be limited to the flow that triggered the
+ gleaned mapping as proposed in [Saucez09].
7. Threats concerning Interworking
[RFC6832] defines two network elements to allow LISP and non-LISP
sites to communicate, namely the Proxy-ITR and the Proxy-ETR. The
Proxy-ITR encapsulates traffic from non-LISP sites in order to
forward it toward LISP sites, while the Proxy-ETR decapsulates
traffic arriving from LISP sites in order to forward it toward non-
LISP sites. For these elements some of the attack based on the LISP
specific header are not possible, for the simple reason that some of
@@ -889,22 +862,22 @@
Request needs to be sent, rather the packet can be silently dropped
since it is not originating from a valid site. The same drop policy
should be used for packets with an invalid source RLOC or a valid
source RLOC but an invalid EID.
As it is the case without LISP, the addition of public proxies offers
opportunities to attackers to commit attacks. LISP interworking does
not open new threats compared to other interworking techniques based
on public proxies.
- Severity level 0: the careful configuration of PETR and PITR combined
- with the deployment of anti-spoofing techniques mitigates the attacks
+ The careful configuration of PETR and PITR combined with the
+ deployment of anti-spoofing techniques mitigates the attacks
leveraging interworking and provides the same level of severity as
interworking techniques in the Internet.
8. Threats with Malicious xTRs
In this section, we discuss the threats that could be caused by
malicious xTRs. We consider the reference environment below where
EL1 is a malicious or compromised xTR. This malicious xTR serves a
set of hosts that includes HC. The other xTRs and hosts in this
network play the same role as in the reference environment described
@@ -1035,33 +1008,33 @@
between the two. We recommend to never use reachability information
without verifying them first.
Note that the attacks discussed in this section are for documentation
purpose only. Malicious xTRs are either somehow directly deployed by
attackers or the result of attackers gaining privileged access to
existing xTRs. As such, it is out of the scope of LISP to propose
any mechanism to protect routers or to avoid their deployments with
malicious intentions.
- Severity level 2: the correct deployment of anti-spoofing and rate
- limiting techniques combined with LISP-Sec and Map-Register
- authentication prevents threats caused by malicious xTRs, as long as
- mappings are always retrieved via a trustable mapping system. In
- addition reachability information should never been used without
- being verified first.
+ The correct deployment of anti-spoofing and rate limiting techniques
+ combined with LISP-Sec and Map-Register authentication prevents
+ threats caused by malicious xTRs, as long as mappings are always
+ retrieved via a trustable mapping system. In addition reachability
+ information SHOULD be verified before usage.
9. Security of the Proposed Mapping Systems
9.1. LISP+ALT
One of the assumptions in [RFC6830] is that the mapping system is
more secure than sending Map-Request and Map-Reply messages directly.
+
We analyze this assumption in this section by analyzing the security
of the ALT mapping system.
The ALT mapping system is basically a manually configured overlay of
GRE tunnels between ALT routers. BGP sessions are established
between ALT routers that are connected through such tunnels. An ALT
router advertises the EID prefixes that it serves over its BGP
sessions with neighboring ALT routers and the EID-Prefixes that it
has learned from neighboring ALT routers.
@@ -1094,25 +1067,24 @@
forwarding them to their final destination on the overlay. This
could lead to various types of redirection attacks. Note that in
contrast with a regular IP router that could also manipulate in
transit packets, when a malicious or compromised ALT router replies
to a Map-Request, it can redirect legitimate traffic for a long
period of time by sending an invalid Map-Reply message. Thus, the
impact of a malicious ALT router could be more severe than a
malicious router in today's Internet. BGP is also weak in case of a
router involved in the BGP topology is compromised.
- Severity level 1: configuring correctly the Map Servers, Map
- Revolvers, and ALT routers with filters corresponding to their
- customer cones provides the same security level as in BGP. If more
- security is necessary, cryptography must be used to validate the
- mappings themselves.
+ Configuring correctly the Map Servers, Map Revolvers, and ALT routers
+ with filters corresponding to their customer cones provides the same
+ security level as in BGP. If more security is necessary,
+ cryptography must be used to validate the mappings themselves.
9.2. LISP-DDT
The LISP Delegated Database Tree (LISP-DDT) mapping system is
proposed as an alternative for LISP+ALT [I-D.ietf-lisp-ddt]. LISP-
DDT is a hierarchical distributed database for EID-to-RLOC mappings.
Each DDT node is configured with an EID prefix it is authoritative
for, as well as the RLOC addresses and EID prefixes of the LISP-DDT
nodes that are authoritative for more specific EID prefix. In LISP-
DDT, mappings are retrieved iterative. A Map Resolver that needs to
@@ -1139,32 +1111,32 @@
The operation in LISP-DDT is different from ALT and thus it does not
present the same threats as LISP+ALT. As a first difference, LISP-
DDT natively includes security specification providing data origin
authentication, data integrity protection and secure EID prefix
delegation. Hence, these aspects are no further explored in this
document.
However, threats exist for LISP-DDT as well. For instance, a DoS
attack could be performed on the mapping infrastructure by asking to
retrieve a large amount of mappings at the same time, hence, the
- importance of carefully dimensioning the topology of the DDT
+ importance of carefully provisioning the topology of the DDT
hierarchy.
If an attacker manages to compromise a LISP-DDT node it could send
fake referrals to the Map Resolver and then control the mappings
delivered to the ITRs. Furthermore, the effects of such an attack
could be longer than the attack itself if the Map Resolver caches the
referrals.
- Severity level 1: the correct deployment of anti-spoofing and rate
- limiting techniques combined with embedded security features of LISP-
- DDT prevent attacks leveraging LISP-DDT.
+ The correct deployment of anti-spoofing and rate limiting techniques
+ combined with embedded security features of LISP-DDT prevent attacks
+ leveraging LISP-DDT.
10. Threats concerning LISP-MS
LISP-MS ([RFC6833] specifies two network elements, namely the Map
Server and the Map Resolver, that are meant to be used by xTRs to
access the mapping system. The advantage is clearly the fact that
even if the mapping system changes in time xTRs do not need to change
anything since they deal only with Map Servers and Map Resolvers.
This includes the security aspects, since no change in the local
security policies is needed.
@@ -1202,23 +1174,23 @@
Similarly to the previous case, a malicious ETR could register an
invalid EID-prefix to attract Map-Requests or to redirect them to a
target to mount a DoS attack. To avoid this kind of attack, the Map
Server must check that the prefixes registered by an ETR belong to
that ETR. One method could be to manually configure EID-prefix
ranges that can be announced by ETRs.
[I-D.saucez-lisp-mapping-security] present alternative techniques to
verify the prefix claimed by an ETR.
- Severity level 1: the correct deployment of anti-spoofing and rate
- limiting techniques combined with usage of Map-Register
- authentication prevents attacks leveraging the Map Server.
+ The correct deployment of anti-spoofing and rate limiting techniques
+ combined with usage of Map-Register authentication prevents attacks
+ leveraging the Map Server.
10.2. Map Resolver
Map Resolvers receive Map-Requests, typically from ITRs, and use the
mapping system to find a mapping for the EID in the Map-Request. It
can work in two modes:
Non-Caching Mode: The resolver just forwards the Map-Request to the
mapping system, which will take care of delivering the request
to an authoritative ETR. The latter will send back a Map-Reply
@@ -1279,23 +1251,23 @@
introduced in the LISP specification to avoid such kind of attack.
There has been discussion within the LISP Working Group on the
optimal size of the nonce, and it seems that 64-bits provides
sufficient protection.
A possible way to limit the above-described attacks is to introduce
strong identification in the Map-Request/Map-Reply by using the
Encapsulated Control Message with authentication enabled
[I-D.ietf-lisp-sec].
- Severity level 1: the correct deployment of anti-spoofing and rate
- limiting techniques combined with LISP-Sec and Map-Register
- authentication prevent attacks leveraging Map Resolver.
+ The correct deployment of anti-spoofing and rate limiting techniques
+ combined with LISP-Sec and Map-Register authentication prevent
+ attacks leveraging Map Resolver.
11. Security Recommendations
Different deployments of LISP may have different security
requirements. The recommendations in this document aim at mitigating
threats in in public deployments of LISP.
To mitigate the impact of attacks against LISP in public deployments,
the following recommendations should be followed.
@@ -1414,27 +1387,28 @@
Security considerations are the core of this document and do not need
to be further discussed in this section.
14. Acknowledgments
This document builds upon the draft of Marcelo Bagnulo
([I-D.bagnulo-lisp-threat]), where the flooding attack and the
reference environment were first described.
- The authors would like to thank Vina Ermagan, Darrel Lewis, and Jeff
- Wheeler for their comments.
+ The authors would like to thank Florin Coras, Vina Ermagan, Darrel
+ Lewis, and Jeff Wheeler for their comments.
This work has been partially supported by the INFSO-ICT-216372
TRILOGY Project (www.trilogy-project.org).
15. References
+
15.1. Normative References
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
Locator/ID Separation Protocol (LISP)", RFC 6830,
January 2013.
[RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
"Interworking between Locator/ID Separation Protocol
(LISP) and Non-LISP Sites", RFC 6832, January 2013.
@@ -1459,22 +1433,22 @@
Century", 75th IETF, Stockholm, July 2009,
.
[I-D.bagnulo-lisp-threat]
Bagnulo, M., "Preliminary LISP Threat Analysis",
draft-bagnulo-lisp-threat-01 (work in progress),
July 2007.
[I-D.ietf-lisp-ddt]
Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP
- Delegated Database Tree", draft-ietf-lisp-ddt-00 (work in
- progress), October 2012.
+ Delegated Database Tree", draft-ietf-lisp-ddt-01 (work in
+ progress), March 2013.
[I-D.ietf-lisp-sec]
Maino, F., Ermagan, V., Cabellos-Aparicio, A., Saucez, D.,
and O. Bonaventure, "LISP-Security (LISP-SEC)",
draft-ietf-lisp-sec-04 (work in progress), October 2012.
[I-D.ietf-tcpm-tcp-security]
Gont, F., "Survey of Security Hardening Methods for
Transmission Control Protocol (TCP) Implementations",
draft-ietf-tcpm-tcp-security-03 (work in progress),
@@ -1497,39 +1471,44 @@
Internet Protocol", RFC 4301, December 2005.
[RFC5386] Williams, N. and M. Richardson, "Better-Than-Nothing
Security: An Unauthenticated Mode of IPsec", RFC 5386,
November 2008.
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", RFC 6480, February 2012.
[SAVI] IETF, "Source Address Validation Improvements Working
- Group", .
+ Group", 2013, .
[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.
+ Summer School on Future Internet, 2009.
Appendix A. Document Change Log
+ o Version 05 Posted August 2013.
+
+ * Removal of severity levels to become a short recommendation to
+ reduce the risk of the discussed threat.
+
o Version 04 Posted February 2013.
* Clear statement that the document compares threats of public
LISP deployments with threats in the current Internet
architecture.
* Addition of a severity level discussion at the end of each
section.
- * Addressed comments from D. Lewis' review.
+ * Addressed comments from V. Ermagan and D. Lewis' reviews.
* Updated References.
* Further editorial polishing.
o Version 03 Posted October 2012.
* Dropped Reference to RFC 2119 notation because it is not
actually used in the document.