draft-ietf-lisp-threats-02.txt   draft-ietf-lisp-threats-03.txt 
Network Working Group D. Saucez Network Working Group D. Saucez
Internet-Draft INRIA Internet-Draft INRIA
Intended status: Informational L. Iannone Intended status: Informational L. Iannone
Expires: March 16, 2013 Telecom ParisTech Expires: April 19, 2013 Telecom ParisTech
O. Bonaventure O. Bonaventure
Universite catholique de Louvain Universite catholique de Louvain
September 12, 2012 October 16, 2012
LISP Threats Analysis LISP Threats Analysis
draft-ietf-lisp-threats-02.txt draft-ietf-lisp-threats-03.txt
Abstract Abstract
This document analyzes the threats against the security of the This document analyzes the threats against the security of the
Locator/Identifier Separation Protocol and proposes a set of Locator/Identifier Separation Protocol (LISP) and proposes a set of
recommendations to mitigate some of the identified security risks. recommendations to mitigate some of the identified security risks.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 16, 2013. This Internet-Draft will expire on April 19, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3
3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3 3. On-path Attackers . . . . . . . . . . . . . . . . . . . . . . 4
4. On-path Attackers . . . . . . . . . . . . . . . . . . . . . . 4 4. Off-Path Attackers: Reference Environment . . . . . . . . . . 4
5. Off-Path Attackers: Reference Environment . . . . . . . . . . 4 5. Data-Plane Threats . . . . . . . . . . . . . . . . . . . . . . 6
6. Data-Plane Threats . . . . . . . . . . . . . . . . . . . . . . 6 5.1. EID-to-RLOC Database Threats . . . . . . . . . . . . . . . 6
6.1. EID-to-RLOC Database Threats . . . . . . . . . . . . . . . 6 5.2. EID-to-RLOC Cache Threats . . . . . . . . . . . . . . . . 7
6.2. EID-to-RLOC Cache Threats . . . . . . . . . . . . . . . . 7 5.2.1. EID-to-RLOC Cache poisoning . . . . . . . . . . . . . 7
6.2.1. EID-to-RLOC Cache poisoning . . . . . . . . . . . . . 7 5.2.2. EID-to-RLOC Cache overflow . . . . . . . . . . . . . . 9
6.2.2. EID-to-RLOC Cache overflow . . . . . . . . . . . . . . 9 5.3. Attacks not leveraging on the LISP header . . . . . . . . 9
6.3. Attacks not leveraging on the LISP header . . . . . . . . 9 5.4. Attacks leveraging on the LISP header . . . . . . . . . . 10
6.4. Attacks leveraging on the LISP header . . . . . . . . . . 10 5.4.1. Attacks using the Locator Status Bits . . . . . . . . 10
6.4.1. Attacks using the Locator Status Bits . . . . . . . . 10 5.4.2. Attacks using the Map-Version bit . . . . . . . . . . 11
6.4.2. Attacks using the Map-Version bit . . . . . . . . . . 11 5.4.3. Attacks using the Nonce-Present and the Echo-Nonce
6.4.3. Attacks using the Nonce-Present and the Echo-Nonce
bits . . . . . . . . . . . . . . . . . . . . . . . . . 12 bits . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.4.4. Attacks using the ID Instance bits . . . . . . . . . . 13 5.4.4. Attacks using the ID Instance bits . . . . . . . . . . 13
7. Control Plane Threats . . . . . . . . . . . . . . . . . . . . 13 6. Control Plane Threats . . . . . . . . . . . . . . . . . . . . 13
7.1. Attacks with Map-Request messages . . . . . . . . . . . . 13 6.1. Attacks with Map-Request messages . . . . . . . . . . . . 13
7.2. Attacks with Map-Reply messages . . . . . . . . . . . . . 15 6.2. Attacks with Map-Reply messages . . . . . . . . . . . . . 15
7.3. Gleaning Attacks . . . . . . . . . . . . . . . . . . . . . 16 6.3. Gleaning Attacks . . . . . . . . . . . . . . . . . . . . . 16
8. Threats concerning Interworking . . . . . . . . . . . . . . . 17 7. Threats concerning Interworking . . . . . . . . . . . . . . . 17
9. Threats with Malicious xTRs . . . . . . . . . . . . . . . . . 18 8. Threats with Malicious xTRs . . . . . . . . . . . . . . . . . 18
10. Security of the Proposed Mapping Systems . . . . . . . . . . . 20 9. Security of the Proposed Mapping Systems . . . . . . . . . . . 21
10.1. LISP+ALT . . . . . . . . . . . . . . . . . . . . . . . . . 21 9.1. LISP+ALT . . . . . . . . . . . . . . . . . . . . . . . . . 21
10.2. LISP-DDT . . . . . . . . . . . . . . . . . . . . . . . . . 22 9.2. LISP-DDT . . . . . . . . . . . . . . . . . . . . . . . . . 22
11. Threats concerning LISP-MS . . . . . . . . . . . . . . . . . . 22 10. Threats concerning LISP-MS . . . . . . . . . . . . . . . . . . 23
11.1. Map Server . . . . . . . . . . . . . . . . . . . . . . . . 23 10.1. Map Server . . . . . . . . . . . . . . . . . . . . . . . . 23
11.2. Map-Resolver . . . . . . . . . . . . . . . . . . . . . . . 24 10.2. Map Resolver . . . . . . . . . . . . . . . . . . . . . . . 24
12. Suggested Recommendations . . . . . . . . . . . . . . . . . . 25 11. Suggested Recommendations . . . . . . . . . . . . . . . . . . 26
13. Document Status and Plans . . . . . . . . . . . . . . . . . . 27 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 13. Security Considerations . . . . . . . . . . . . . . . . . . . 28
15. Security Considerations . . . . . . . . . . . . . . . . . . . 28 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28
16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 15.1. Normative References . . . . . . . . . . . . . . . . . . . 28
17.1. Normative References . . . . . . . . . . . . . . . . . . . 28 15.2. Informative References . . . . . . . . . . . . . . . . . . 29
17.2. Informative References . . . . . . . . . . . . . . . . . . 29
Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 30 Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31
1. Requirements notation 1. Introduction
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 The Locator/ID Separation Protocol (LISP) is defined in
[I-D.ietf-lisp]. The present document aims at identifying threats in [I-D.ietf-lisp]. The present document aims at assessing the security
the current LISP specification. We also propose some recommendations level and identifying security threats in the LISP specification. As
on mechanisms that could improve the security of LISP against off- a result of the performed analysis, the document also proposes some
path attackers. This document builds upon [I-D.bagnulo-lisp-threat]. recommendations aiming at improving LISP's resiliency against off-
path attackers.
This document is split in two parts. The first discusses the LISP The document is composed of two main parts: the first discussing the
data-plane and the second the LISP control-plane. LISP data-plane; while the second discussing the LISP control-plane.
The LISP data-plane consists of LISP packet encapsulation, The LISP data-plane consists of LISP packet encapsulation,
decapsulation, and forwarding and includes the EID-to-RLOC Cache and decapsulation, and forwarding and includes the EID-to-RLOC Cache and
EID-to-RLOC Database data structures used to perform these EID-to-RLOC Database data structures used to perform these
operations. operations.
The LISP control-plane consists in the mapping distribution system, The LISP control-plane consists in the mapping distribution system,
which can be one of the mapping distribution systems proposed so far which can be one of the mapping distribution systems proposed so far
(e.g., [I-D.ietf-lisp], [I-D.ietf-lisp-alt], [I-D.ietf-lisp-ms], (e.g., [I-D.ietf-lisp], [I-D.fuller-lisp-ddt], [I-D.ietf-lisp-alt],
[I-D.meyer-lisp-cons], and [I-D.lear-lisp-nerd]), and the Map- [I-D.ietf-lisp-ms], [I-D.meyer-lisp-cons], and [I-D.lear-lisp-nerd]),
Request, Map-Reply, Map-Register messages. and the Map-Request, Map-Reply, Map-Register, and Map-Notification
messages.
This document does not consider all the possible uses of LISP as This document does not consider all the possible uses of LISP as
discussed in [I-D.ietf-lisp]. The document focuses on LISP unicast, discussed in [I-D.ietf-lisp]. The document focuses on LISP unicast,
including as well LISP Interworking [I-D.ietf-lisp-interworking], including as well LISP Interworking [I-D.ietf-lisp-interworking],
LISP-MS [I-D.ietf-lisp-ms], and briefly considers the ALT mapping LISP-MS [I-D.ietf-lisp-ms], LISP Map-Versioning
system described in [I-D.ietf-lisp-alt]. [I-D.ietf-lisp-map-versioning], and briefly considering the ALT
mapping system described in [I-D.ietf-lisp-alt] and the Delegated
Database Tree mapping system described in [I-D.fuller-lisp-ddt]. The
reading of these documents is a prerequisite for understanding the
present document.
Furthermore, here we assume a generic IP service and do not discuss Unless otherwise stated, the document assumes a generic IP service
the difference from a security viewpoint between using IPv4 or IPv6. and does not discuss the difference, from a security viewpoint,
between using IPv4 or IPv6.
3. Definition of Terms 2. Definition of Terms
The present document does not introduce any new term, compared to the The present document does not introduce any new term, compared to the
main LISP specification. For a complete list of terms please refer main LISP specification. For a complete list of terms please refer
to [I-D.ietf-lisp]. to [I-D.ietf-lisp].
4. On-path Attackers 3. On-path Attackers
On-path attackers are attackers that are able to capture and modify On-path attackers are attackers that are able to capture and modify
all the packets exchanged between an ITR and an ETR. To cope with all the packets exchanged between an Ingress Tunnel Router (ITR) and
such an attacker, cryptographic techniques such as those used by an Egress Tunnel Router (ETR). To cope with such an attacker,
IPSec are required. We do not consider that LISP has to cope with cryptographic techniques such as those used by IPSec ([RFC4301]) are
such attackers. required. We do not consider that LISP has to cope with such kind of
attackers.
Mobile IP has also considered time-shifted attacks from on-path Mobile IP has also considered time-shifted attacks from on-path
attackers. A time-shifted attack is an attack where the attacker is attackers. A time-shifted attack is an attack where the attacker is
temporarily on the path between two communicating hosts. While it is temporarily on the path between two communicating hosts. While it is
on-path, the attacker sends specially crafted packets or modifies on-path, the attacker sends specially crafted packets or modifies
packets exchanged by the communicating hosts in order to disturb the packets exchanged by the communicating hosts in order to disturb the
packet flow (e.g., by performing a man in the middle attack). An packet flow (e.g., by performing a man in the middle attack). An
important issue for time-shifted attacks is the duration of the important issue for time-shifted attacks is the duration of the
attack once the attacker has left the path between the two attack once the attacker has left the path between the two
communicating hosts. We do not consider time-shifted attacks in this communicating hosts. We do not consider time-shifted attacks in this
document. document.
5. Off-Path Attackers: Reference Environment 4. Off-Path Attackers: Reference Environment
Throughout this document we consider the reference environment shown Throughout this document we consider the reference environment shown
in the figure below. There are two hosts attached to LISP routers: in the figure below. There are two hosts attached to LISP routers:
HA and HB. HA is attached to the two LISP xTRs LR1 and LR2, which HA and HB. HA is attached to the two LISP xTRs LR1 and LR2, which in
are attached to two different ISPs. HB is attached to the two LISP turn are attached to two different ISPs. HB is attached to the two
xTRs LR3 and LR4. HA and HB are the EIDs of the two hosts. LR1, LISP xTRs LR3 and LR4. HA and HB are the EIDs of the two hosts.
LR2, LR3, and LR4 are the RLOCs of the xTRs. LR1, LR2, LR3, and LR4 are the RLOCs of the xTRs.
+-----+ +-----+
| HA | | HA |
+-----+ +-----+
| EID: HA | EID: HA
| |
----------------- -----------------
| | | |
+-----+ +-----+ +-----+ +-----+
| LR1 | | LR2 | | LR1 | | LR2 |
skipping to change at page 6, line 5 skipping to change at page 6, line 5
SA is an off-path attacker that is able to send spoofed packets, SA is an off-path attacker that is able to send spoofed packets,
i.e., packets with a different source IP address than its i.e., packets with a different source IP address than its
assigned IP address. SA stands for Spoofing Attacker. assigned IP address. SA stands for Spoofing Attacker.
NSA is an off-path attacker that is only able to send packets whose NSA is an off-path attacker that is only able to send packets whose
source address is its assigned IP address. NSA stands for Non source address is its assigned IP address. NSA stands for Non
Spoofing Attacker. Spoofing Attacker.
It should be noted that with LISP, packet spoofing is slightly It should be noted that with LISP, packet spoofing is slightly
different than in the current Internet. Generally the term "spoofed different than in the current Internet. Generally the term "spoofed
packet" indicates a packet containing a source IP address which is packet" indicates a packet containing a source IP address that is not
not the one of the actual originator of the packet. Since LISP uses the one of the actual originator of the packet. Since LISP uses
encapsulation, the spoofed address can be in the outer header as well encapsulation, the spoofed address can be in the outer header as well
as in the inner header, this translates in two types of spoofing: as in the inner header, this translates in two types of spoofing:
EID Spoofing: the originator of the packet puts in it a spoofed EID. EID Spoofing: the originator of the packet puts in it a spoofed EID.
The packet will be normally encapsulated by the ITR of the The packet will be normally encapsulated by the ITR of the site
site. (or a PITR if the source site is not LISP enabled).
RLOC Spoofing: the originator of the packet generates directly a RLOC Spoofing: the originator of the packet generates directly a
LISP-encapsulated packet with a spoofed source RLOC. LISP-encapsulated packet with a spoofed source RLOC.
Note that the two types of spoofing are not mutually exclusive, Note that the two types of spoofing are not mutually exclusive,
rather all combinations are possible and can be used to perform rather all combinations are possible and can be used to perform
different kind of attacks. different kind of attacks.
In our reference environment, both SA and NSA attackers are capable In the reference environment, both SA and NSA attackers are capable
of sending LISP encapsulated data packets and LISP control packets. of sending LISP encapsulated data packets and LISP control packets.
This means that SA is able to perform both RLOC and EID spoofing This means that SA is able to perform both RLOC and EID spoofing
while NSA can only perform EID spoofing. They may also send other while NSA can only perform EID spoofing. They may also send other
types of IP packets such as ICMP messages. We assume that both types of IP packets such as ICMP messages. We assume that both
attackers can query the LISP mapping system to obtain the mappings attackers can query the LISP mapping system (e.g., through a public
for both HA and HB. Map Resolver) to obtain the mappings for both HA and HB.
6. Data-Plane Threats 5. Data-Plane Threats
This section discusses threats and attacks related to the LISP data- This section discusses threats and attacks related to the LISP data-
plane. More precisely, we discuss the operations of encapsulation, plane. More precisely, we discuss the operations of encapsulation,
decapsulation, and forwarding as well as the content of the EID-to- decapsulation, and forwarding as well as the content of the EID-to-
RLOC Cache and EID-to-RLOC Database as specified in the original LISP RLOC Cache and EID-to-RLOC Database as specified in the original LISP
document ([I-D.ietf-lisp]). document ([I-D.ietf-lisp]).
We start considering the two main data structures of LISP, namely the We start considering the two main data structures of LISP, namely the
EID-to-RLOC Database and the EID-to-RLOC Cache. Then, we look at the EID-to-RLOC Database and the EID-to-RLOC Cache. Then, we look at the
data plane attacks that can be performed by a spoofing off-path data plane attacks that can be performed by a spoofing off-path
attacker (SA) and discuss how they can be mitigated by the LISP xTRs. attacker (SA) and discuss how they can be mitigated by LISP xTRs. In
In this analysis, we assume that the LR1 and LR2 (resp. LR3 and LR4) this analysis, we assume that the LR1 and LR2 (resp. LR3 and LR4)
xTRs maintain a EID-to-RLOC Cache that contains the required mapping xTRs maintain an EID-to-RLOC Cache that contains the required mapping
entries to allow HA and HB to exchange packets. entries to allow HA and HB to exchange packets.
6.1. EID-to-RLOC Database Threats 5.1. EID-to-RLOC Database Threats
The EID-to-RLOC Database on each xTR maintains the set of mappings The EID-to-RLOC Database on each xTR maintains the set of mappings
related to the EID-Prefixes that are "behind" the xTR. Where related to the EID-Prefixes that are "behind" the xTR. Where
"behind" means that at least one of the xTR's globally-visible IP "behind" means that at least one of the xTR's globally visible IP
addresses is a RLOC for those EID-Prefixes. addresses is a RLOC for those EID-Prefixes.
As described in [I-D.ietf-lisp], the EID-to-RLOC Database content is As described in [I-D.ietf-lisp], the EID-to-RLOC Database content is
determined by configuration. This means that the only way to attack determined by configuration. This means that the only way to attack
this data structure is by gaining privileged access to the xTR. As 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 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 protect routers and, hence, it is no further analyzed in this
document. document.
6.2. EID-to-RLOC Cache Threats 5.2. EID-to-RLOC Cache Threats
A key component of the overall LISP architecture is the EID-to-RLOC A key component of the overall LISP architecture is the EID-to-RLOC
Cache. The EID-to-RLOC Cache is the data structure that stores the Cache. The EID-to-RLOC Cache is the data structure that stores the
bindings between EID and RLOC (namely the "mappings") to be used bindings between EID and RLOC (namely the "mappings") to be used
later on. Attacks against this data structure can happen either when later on. Attacks against this data structure can happen either when
the mappings are first installed in the cache (see also Section 7) or the mappings are first installed in the cache (see also Section 6) or
by corrupting (poisoning) the mappings already present in the cache. by corrupting (poisoning) the mappings already present in the cache.
6.2.1. EID-to-RLOC Cache poisoning 5.2.1. EID-to-RLOC Cache poisoning
The content of the EID-to-RLOC Cache can be poisoned by spoofing LISP The content of the EID-to-RLOC Cache can be poisoned by spoofing LISP
encapsulated packets. Example of EID-to-RLOC Cache poisoning are: encapsulated packets. Examples of EID-to-RLOC Cache poisoning are:
Fake mapping: The cache contains entirely fake mappings that do not Fake mapping: The cache contains entirely fake mappings that do not
originate from an authoritative mapping server. This can be originate from an authoritative mapping server. This can be
achieved either through gleaning as described in Section 7.3 or achieved either through gleaning as described in Section 6.3 or
by attacking the control-plane as described in Section 7. by attacking the control-plane as described in Section 6.
EID Poisoning: The EID-Prefix in a specific mapping is not owned by EID Poisoning: The EID-Prefix in a specific mapping is not owned by
the originator of the entry. Similarly to the previous case, the originator of the entry. Similarly to the previous case,
this can be achieved either through gleaning as described in this can be achieved either through gleaning as described in
Section 7.3 or by attacking the control-plane as described in Section 6.3 or by attacking the control-plane as described in
Section 7. Section 6.
EID redirection/RLOC poisoning: The EID-Prefix in the mapping is not EID redirection/RLOC poisoning: The EID-Prefix in the mapping is not
bound to (located by) the set of RLOCs present in the mapping. bound to (located by) the set of RLOCs present in the mapping.
This can result in packets being redirected elsewhere, This can result in packets being redirected elsewhere,
eavesdropped, or even blackholed. Note that not necessarily eavesdropped, or even blackholed. Note that not necessarily
all RLOCs are fake/spoofed. The attack works also if only part all RLOCs are fake/spoofed. The attack works also if only part
of the RLOCs, the highest priority ones, is compromised. of the RLOCs, the highest priority ones, is compromised.
Again, this can be achieved either through the gleaning as Again, this can be achieved either through the gleaning as
described in Section 7.3 or by attacking the control-plane as described in Section 6.3 or by attacking the control-plane as
described in Section 7. described in Section 6.
Reachability poisoning: The reachability information stored in the Reachability poisoning: The reachability information stored in the
mapping could be poisoned, redirecting the packets to a subset mapping could be poisoned, redirecting the packets to a subset
of the RLOCs (or even stopping it if locator status bits are of the RLOCs (or even stopping it if locator status bits are
all set to 0). If reachability information is not verified all set to 0). If reachability information is not verified
through the control-plane this attack can be simply achieved by through the control-plane this attack can be simply achieved by
sending a spoofed packet with swapped or all locator status sending a spoofed packet with swapped or all locator status
bits reset. The same result can be obtained by attacking the bits reset. The same result can be obtained by attacking the
control-plane as described in Section 7. Depending on how the control-plane as described in Section 6. Depending on how the
RLOC reachability information is stored on the router, the RLOC reachability information is stored on the router, the
attack can impact only one mapping or all the mappings that attack can impact only one mapping or all the mappings that
share the same RLOC. share the same RLOC.
Traffic Engineering information poisoning: The LISP protocol defines Traffic Engineering information poisoning: The LISP protocol defines
two attributes associated to each RLOC in order to perform two attributes associated to each RLOC in order to perform
inbound Traffic Engineering (TE): namely priority and weight. inbound Traffic Engineering (TE), namely priority and weight.
By injecting fake TE attributes, the attacker is able to break By injecting fake TE attributes, the attacker is able to break
load balancing policies and concentrate all the traffic on a load balancing policies and concentrate all the traffic on a
single RLOC or put more load on a RLOC than what is expected, single RLOC or put more load on a RLOC than what is expected,
creating congestion. It is even possible to block the traffic creating congestion. It is even possible to block the traffic
if all the priorities are set to 255. Corrupting the TE if all the priorities are set to 255 (special value indicating
attributes can be achieved by attacking the control-plane as not to use the RLOC). Corrupting the TE attributes can be
described in Section 7. achieved by attacking the control-plane as described in
Section 6.
Mapping TTL poisoning: The LISP protocol associates a Time-To-Live Mapping TTL poisoning: The LISP protocol associates a Time-To-Live
to each mapping that, once expired, allows to delete a mapping to each mapping that, once expired, allows to delete a mapping
from the EID-to-RLOC Cache (or forces a Map-Request/Map-Reply from the EID-to-RLOC Cache (or forces a Map-Request/Map-Reply
exchange to refresh it if still needed). By injecting fake TTL exchange to refresh it if still needed). By injecting fake TTL
values, an attacker can either shrink the EID-to-RLOC Cache values, an attacker can either shrink the EID-to-RLOC Cache
(using very short TTL), thus creating an excess of cache miss (using very short TTL), thus creating an excess of cache miss
causing a DoS on the mapping system, or it can increase the 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 size of the cache by putting very high TTL values, up to a
cache overflow (see Section 6.2.2). Corrupting the TTL can be cache overflow (see Section 5.2.2). Corrupting the TTL can be
achieved by attacking the control-plane as described in achieved by attacking the control-plane as described in
Section 7. Long TTL can be use in fake mappings to increase an Section 6. Long TTL can be use in fake mappings to increase
attack duration. attack duration.
Instance ID poisoning: The LISP protocol allows to use a 24-bit Instance ID poisoning: The LISP protocol allows using a 24-bit
identifier to select the forwarding table to use on the identifier to select the forwarding table to use on the
decapsulating ETR to forward the decapsulated packet. By decapsulating ETR to forward the decapsulated packet. By
spoofing this attribute the attacker is able to redirect or spoofing this attribute the attacker is able to redirect or
blackhole inbound traffic. Corrupting the Instance ID blackhole inbound traffic. Corrupting the Instance ID
attribute can be achieved by attacking the control-plane as attribute can be achieved by attacking the control-plane as
described in Section 7. described in Section 6.
Map-Version poisoning: The LISP protocol allows to associate a Map-Version poisoning: The LISP protocol allows associating a
version number to mappings ([I-D.ietf-lisp-map-versioning]). version number to mappings ([I-D.ietf-lisp-map-versioning]).
The LISP header can transport source and destination map- The LISP header can transport source and destination map-
versions, describing which version of the mapping have been versions, describing which version of the mapping have been
used to select the source and the destination RLOCs of the LISP used to select the source and the destination RLOCs of the LISP
encapsulated packet. By spoofing this attribute the attacker encapsulated packet. By spoofing this attribute the attacker
is able to trigger Map-Request on the receiving ETR. is able to trigger Map-Request on the receiving ETR.
Corrupting the Map-Version attribute can be achieved either by Corrupting the Map-Version attribute can be achieved either by
attacking the control-plane as described in Section 7 or by attacking the control-plane as described in Section 6 or by
using spoofed packets as described in Section 6.4.2. using spoofed packets as described in Section 5.4.2.
If the above listed attacks succeed, the attacker has the means of If the above listed attacks succeed, the attacker has the means of
controlling the traffic. controlling the traffic.
6.2.2. EID-to-RLOC Cache overflow 5.2.2. EID-to-RLOC Cache overflow
Depending on how the EID-to-RLOC Cache is managed (e.g., LRU vs. LFU) Depending on how the EID-to-RLOC Cache is managed (e.g., Least
and depending on its size, an attacker can try to fill the cache with Recently Used - LRU vs. Least Frequently Used - LFU) and depending on
fake mappings. Once the cache is full, some mappings will be its size, an attacker can try to fill the cache with fake mappings.
replaced by new fake ones, causing traffic disruption. 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 This can be achieved either through gleaning as described in
Section 7.3 or by attacking the control-plane as described in Section 6.3 or by attacking the control-plane as described in
Section 7. Section 6.
Another way to generate a EID-to-RLOC Cache overflow is by injecting Another way to generate an EID-to-RLOC Cache overflow is by injecting
mapping with a fake and very large TTL value. In this case the cache 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 will keep a large amount of mappings ending with a completely full
cache. This type of attack can also be performed through the cache. This type of attack can also be performed through the
control-plane. control-plane.
6.3. Attacks not leveraging on the LISP header 5.3. Attacks not leveraging on the LISP header
We first consider an attacker that sends packets without exploiting We first consider an attacker that sends packets without exploiting
the LISP header, i.e., with the N, L, E, V, and I bits reset the LISP header, i.e., with the N, L, E, V, and I bits reset
([I-D.ietf-lisp]). ([I-D.ietf-lisp]).
To inject a packet in the HA-HB flow, a spoofing off-path attacker To inject a packet in the HA-HB flow, a spoofing off-path attacker
(SA) can send a LISP encapsulated packet whose source is set to LR1 (SA) can send a LISP encapsulated packet whose source is set to LR1
or LR2 and destination LR3 or LR4. The packet will reach HB as if or LR2 and destination LR3 or LR4. The packet will reach HB as if
the packet was sent by host HA. This is not different from today's the packet was sent by host HA. This is not different from today's
Internet where a spoofing off-path attacker may inject data packets Internet where a spoofing off-path attacker may inject data packets
skipping to change at page 10, line 5 skipping to change at page 10, line 6
The destination address of the encapsulated packet can be LR3 or LR4. The destination address of the encapsulated packet can be LR3 or LR4.
When the LISP ETR that serves HB receives the encapsulated packet, it 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 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 source address for LISP encapsulated packets containing a packet sent
by HA. This verification is only possible if the ETR already has a by HA. This verification is only possible if the ETR already has a
valid mapping for HA. Otherwise, and to avoid such data packet valid mapping for HA. Otherwise, and to avoid such data packet
injection attacks, the LISP ETR should reject the packet and possibly injection attacks, the LISP ETR should reject the packet and possibly
query the mapping system to obtain a mapping for the encapsulated query the mapping system to obtain a mapping for the encapsulated
source EID (HA). source EID (HA).
6.4. Attacks leveraging on the LISP header 5.4. Attacks leveraging on the LISP header
The latest LISP draft [I-D.ietf-lisp] defines several flags that The main LISP document [I-D.ietf-lisp] defines several flags that
modify the interpretation of the LISP header in data packets. In modify the interpretation of the LISP header in data packets. In
this section, we discuss how an off-path attacker could exploit this this section, we discuss how an off-path attacker could exploit this
LISP header. LISP header.
6.4.1. Attacks using the Locator Status Bits 5.4.1. Attacks using the Locator Status Bits
When the L bit is set to 1, it indicates that the second 32-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 longword of the LISP header contains the Locator Status Bits. In
this field, each bit position reflects the status of one of the RLOCs this field, each bit position reflects the status of one of the RLOCs
mapped to the source EID found in the encapsulated packet. In mapped to the source EID found in the encapsulated packet. In
particular, a packet with the L bit set and all Locator Status Bits 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 set to zero indicates that none of the locators of the encapsulated
source EID are reachable. The reaction of a LISP ETR that receives source EID are reachable. The reaction of a LISP ETR that receives
such a packet is not clearly described in [I-D.ietf-lisp]. such a packet is not clearly described in [I-D.ietf-lisp].
A spoofing off-path attacker (SA) can send a data packet with the L A spoofing off-path attacker (SA) can send a data packet with the L
bit set to 1, all Locator Status Bits set to zero, a spoofed source bit set to 1, all Locator Status Bits set to zero, a spoofed source
RLOC (e.g. LR1), destination LR3, and containing an encapsulated RLOC (e.g. LR1), destination LR3, and containing an encapsulated
packet whose source is HA. If LR3 blindly trust the Locator Status packet whose source is HA. If LR3 blindly trusts the Locator Status
Bits of the received packet it will set LR1 and LR2 as unreachable, Bits of the received packet it will set LR1 and LR2 as unreachable,
possibly disrupting ongoing communication. possibly disrupting ongoing communication.
Locator Status Bits can be blindly trusted only in secure Locator Status Bits can be blindly trusted only in secure
environments. In the general unsecured Internet environment, the environments. In the general unsecured Internet environment, the
safest practice for xTRs is to confirm the reachability change safest practice for xTRs is to confirm the reachability change
through the control plane (e.g., RLOC probing). In the above through the control plane (e.g., RLOC probing). In the above
example, LR3 should note that something has changed in the Locator example, LR3 should note that something has changed in the Locator
Status Bits and query the mapping system in order to confirm status Status Bits and query the mapping system (assuming it is trusted) in
of the RLOCs of the source EID. order to confirm status of the RLOCs of the source EID.
A similar attack could occur by setting only one Locator Status Bit A similar attack could occur by setting only one Locator Status Bit
to 1, e.g., the one that corresponds to the source RLOC of the to 1, e.g., the one that corresponds to the source RLOC of the
packet. packet.
If a non-spoofing off-path attacker (NSA) sends a data packet with If a non-spoofing off-path attacker (NSA) sends a data packet with
the L bit set to 1 and all Locator Status Bits set to zero, this the L bit set to 1 and all Locator Status Bits set to zero, this
packet will contain the source address of the attacker. Similarly as packet will contain the source address of the attacker. Similarly as
in Section 6.3, if the xTR accepts the packet without checking the in Section 5.3, if the xTR accepts the packet without checking the
EID-to-RLOC Cache for a mapping that binds the source EID and the EID-to-RLOC Cache for a mapping that binds the source EID and the
source RLOC of the received packet, then the same observation like source RLOC of the received packet, then the same observation like
for the the spoofing attacker (SA) apply. for the spoofing attacker (SA) apply with the difference that instead
of complete disruption, the traffic will flow through only one RLOC,
possibly resulting in a DoS attack.
Otherwise, if the xTR does make the check through the EID-to-RLOC Otherwise, if the xTR does make the check through the EID-to-RLOC
Cache, it should reject the packet because its source address is not Cache, it should reject the packet because its source address is not
one of the addresses listed as RLOCs for the source EID. one of the addresses listed as RLOCs for the source EID.
Nevertheless, in this case a Map-Request should be sent, which can be Nevertheless, in this case a Map-Request should be sent, which can be
used to perform Denial of Service attacks. Indeed an attacker can used to perform Denial of Service attacks. Indeed an attacker can
frequently change the Locator Status Bits in order to trigger a large frequently change the Locator Status Bits in order to trigger a large
amount of Map-Requests. Rate limitation, as described in amount of Map-Requests. Rate limitation, as described in
[I-D.ietf-lisp], does not allow to send high number of such a [I-D.ietf-lisp], does not allow sending high number of such a
request, resulting in the attacker saturating the rate with these request, resulting in the attacker saturating the rate with these
spoofed packets. spoofed packets.
6.4.2. Attacks using the Map-Version bit 5.4.2. Attacks using the Map-Version bit
The Map-Version bit is used to indicate whether the low-order 24 bits The Map-Version bit is used to indicate whether the low-order 24 bits
of the first 32 bits word of the LISP header contain an Source and of the first 32 bits longword of the LISP header contain a Source and
Destination Map-Version. When a LISP ETR receives a LISP Destination Map-Version. When a LISP ETR receives a LISP
encapsulated packet with the Map-Version bit set to 1, the following encapsulated packet with the Map-Version bit set to 1, the following
actions are taken: actions are taken:
o It compares the Destination Map-Version found in the header with o It compares the Destination Map-Version found in the header with
the current version of its own mapping, in the EID-to-RLOC the current version of its own mapping, in the EID-to-RLOC
Database, for the destination EID found in the encapsulated Database, for the destination EID found in the encapsulated
packet. If the received Destination Map-Version is smaller (i.e., packet. If the received Destination Map-Version is smaller (i.e.,
older) than the current version, the ETR should apply the SMR older) than the current version, the ETR should apply the SMR
procedure described in [I-D.ietf-lisp] and send a Map-Request with procedure described in [I-D.ietf-lisp] and send a Map-Request with
skipping to change at page 11, line 43 skipping to change at page 11, line 46
source version of the LISP encapsulated packet, the xTR should source version of the LISP encapsulated packet, the xTR should
send a Map-Request for the source EID. send a Map-Request for the source EID.
A spoofing off-path attacker (SA) could use the Map-Version bit to A spoofing off-path attacker (SA) could use the Map-Version bit to
force an ETR to send Map-Request messages. The attacker can retrieve force an ETR to send Map-Request messages. The attacker can retrieve
the current source and destination Map-Version for both HA and HB. the current source and destination Map-Version for both HA and HB.
Based on this information, it can send a spoofed packet with an older Based on this information, it can send a spoofed packet with an older
Source Map-Version or Destination Map-Version. If the size of the Source Map-Version or Destination Map-Version. If the size of the
Map-Request message is larger than the size of the smallest LISP- Map-Request message is larger than the size of the smallest LISP-
encapsulated packet that could trigger such a message, this could encapsulated packet that could trigger such a message, this could
lead to amplification attacks (see Section 7.1). Fortunately, lead to amplification attacks (see Section 6.1). However,
[I-D.ietf-lisp] recommends to rate limit the Map-Request messages [I-D.ietf-lisp] recommends to rate limit the Map-Request messages
that are sent by an xTR. This prevents the amplification attack, but that are sent by an xTR. This prevents the amplification attack, but
there is a risk of Denial of Service attack if an attacker sends there is a risk of Denial of Service attack if an attacker sends
packets with Source and Destination Map-Versions that frequently packets with Source and Destination Map-Versions that frequently
change. In this case, the ETR could consume all its rate by sending change. In this case, the ETR could consume its entire rate by
Map-Request messages in response to these spoofed packets. sending Map-Request messages in response to these spoofed packets.
A non-spoofing off-path attacker (NSA) cannot success in such an A non-spoofing off-path attacker (NSA) cannot success in such an
attack if the destination xTR rejects the LISP encapsulated packets attack if the destination xTR rejects the LISP encapsulated packets
that are not sent by one of the RLOCs mapped to the included source that are not sent by one of the RLOCs mapped to the included source
EID. If it is not the case, the attacker can be able to perform EID. If it is not the case, the attacker can be able to perform
attacks concerning the Destination Map Version number as for the attacks concerning the Destination Map Version number as for the
spoofing off-path attacker (SA). spoofing off-path attacker (SA).
6.4.3. Attacks using the Nonce-Present and the Echo-Nonce bits 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 The Nonce-Present and Echo-Nonce bits are used when verifying the
reachability of a remote ETR. Assume that LR3 wants to verify that 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 LR1 receives the packets that it sends. LR3 can set the Echo-Nonce
and the Nonce-Present bits in LISP data encapsulated packets and and the Nonce-Present bits in LISP data encapsulated packets and
include a random nonce in these packets. Upon reception of these 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 packets, LR1 will store the nonce sent by LR3 and echo it when it
returns LISP encapsulated data packets to LR3. returns LISP encapsulated data packets to LR3.
A spoofing off-path attacker (SA) could interfere with this A spoofing off-path attacker (SA) could interfere with this
skipping to change at page 13, line 8 skipping to change at page 13, line 10
the nonce that it returns to the remote ITR. If the remote ITR the nonce that it returns to the remote ITR. If the remote ITR
starts a nonce-reachability test, this test may fail because the ETR starts a nonce-reachability test, this test may fail because the ETR
has received a spoofed LISP data encapsulated packet with a different has received a spoofed LISP data encapsulated packet with a different
random nonce and never echoes the real nonce. In this case the ITR random nonce and never echoes the real nonce. In this case the ITR
will consider the ETR not reachable. The success of this test will 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 of course depend on the ratio between the amount of packets sent by
the legitimate ITR and the spoofing off-path attacker (SA). the legitimate ITR and the spoofing off-path attacker (SA).
Packets sent by a non-spoofing off-path attacker (NSA) can cause 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 similar problem if no check is done with the EID-to-RLOC Cache (see
Section 6.3 for the EID-to-RLOC Cache check). Otherwise, if the 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 check is performed the packets will be rejected by the ETR that
receives them and cannot cause problems. receives them and cannot cause problems.
6.4.4. Attacks using the ID Instance bits 5.4.4. Attacks using the ID Instance bits
LISP allows to carry in its header a 24-bits value called "Instance 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 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 been used for encapsulation, while on the ETR can be used to select
the forwarding table used for forwarding the decapsulated packet. the forwarding table used for forwarding the decapsulated packet.
Even if an off-path attacker could randomly guess a valid Instance ID Even if an off-path attacker could randomly guess a valid Instance ID
value, there is no LISP specific problem. Obviously the attacker value, there is no LISP specific problem. Obviously the attacker
could be now able to reach hosts that are only reachable through the could be now able to reach hosts that are only reachable through the
routing table identified by the attacked Instance ID, however, end- routing table identified by the attacked Instance ID, however, end-
system security is out of the scope of this document. Nevertheless, system security is out of the scope of this document. Nevertheless,
access lists can be configured to protect the network from Instance access lists can be configured to protect the network from Instance
ID based attacks. ID based attacks.
7. Control Plane Threats 6. Control Plane Threats
In this section, we discuss the different types of attacks that can In this section, we discuss the different types of attacks that can
occur when an off-path attacker sends control plane packets. We 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 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 analyze the particularities of a LISP mapping system. The LISP+ALT
and LISP-DDT mapping systems are discussed in Section 10. and LISP-DDT mapping systems are discussed in Section 9.
7.1. Attacks with Map-Request messages 6.1. Attacks with Map-Request messages
An off-path attacker could send Map-Request packets to a victim ETR. 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 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 as such it should not lead to security problems. However, the LISP
specification [I-D.ietf-lisp] contains several particularities that specification [I-D.ietf-lisp] contains several particularities that
could be exploited by an off-path attacker. could be exploited by an off-path attacker.
The first possible exploitation is the P bit. The P bit is used to The first possible exploitation is the P bit. The P bit is used to
probe the reachability of remote ETRs in the control plane. In our probe the reachability of remote ETRs in the control plane. In our
reference environment, LR3 could probe the reachability of LR1 by reference environment, LR3 could probe the reachability of LR1 by
skipping to change at page 14, line 30 skipping to change at page 14, line 32
Any ISP with a large number of potential RLOCs for a given EID-Prefix Any ISP with a large number of potential RLOCs for a given EID-Prefix
should carefully ponder the best trade-off between the number of should carefully ponder the best trade-off between the number of
RLOCs through which it wants that the EID is reachable and the RLOCs through which it wants that the EID is reachable and the
consequences that an amplification attack can produce. consequences that an amplification attack can produce.
It should be noted that the maximum rate of Map-Reply messages should It should be noted that the maximum rate of Map-Reply messages should
apply to all Map-Replies and also be associated to each destination apply to all Map-Replies and also be associated to each destination
that receives Map-Reply messages. Otherwise, a possible that receives Map-Reply messages. Otherwise, a possible
amplification attack could be launched by a spoofing off-path amplification attack could be launched by a spoofing off-path
attacker (SA) as follows. Consider an attacker SA and and EID-Prefix attacker (SA) as follows. Consider an attacker SA and EID-Prefix
p/P and a victim ITR. To amplify a Denial of Service attack against 192.0.2.0/24 and a victim ITR. To amplify a Denial of Service attack
the victim ITR, SA could send spoofed Map-Request messages whose against the victim ITR, SA could send spoofed Map-Request messages
source EID addresses are all the addresses inside p/P and source RLOC whose source EID addresses are all the addresses inside 192.0.2.0/24
address is the victim ITR. Upon reception of these Map-Request and source RLOC address is the victim ITR. Upon reception of these
messages, the ETR would send large Map-Reply messages for each of the Map-Request messages, the ETR would send large Map-Reply messages for
addresses inside p/P back to the victim ITR. each of the addresses inside p/P back to the victim ITR.
If a non-spoofing off-path attacker (NSA) sends a Map-Request with If a non-spoofing off-path attacker (NSA) sends a Map-Request with
the P bit set, it will receive a Map-Reply with the P bit set. This the P bit set, it will receive a Map-Reply with the P bit set. This
does not raise security issues besides the usual risk of overloading does not raise security issues besides the usual risk of overloading
a victim ETR by sending too many Map-Request messages. a victim ETR by sending too many Map-Request messages.
The Map-Request message may also contain the SMR bit. Upon reception The Map-Request message may also contain the SMR bit. Upon reception
of a Map-Request message with the SMR bit, an ETR must return to the 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 source of the Map-Request message a Map-Request message to retrieve
the corresponding mapping. This raises similar problems as the P bit the corresponding mapping. This raises similar problems as the P bit
skipping to change at page 15, line 14 skipping to change at page 15, line 15
provided in the Map-Request message. provided in the Map-Request message.
Furthermore, appending Map-Records to Map-Request messages represents Furthermore, appending Map-Records to Map-Request messages represents
a major security risk since an off-path attacker could generate a a major security risk since an off-path attacker could generate a
(spoofed or not) Map-Request message and include in the Map-Reply (spoofed or not) Map-Request message and include in the Map-Reply
portion of the message mapping for EID prefixes that it does not portion of the message mapping for EID prefixes that it does not
serve. This could lead to various types of redirection and denial of serve. This could lead to various types of redirection and denial of
service attacks. An xTR should not process the Map-Records service attacks. An xTR should not process the Map-Records
information that it receives in a Map-Request message. information that it receives in a Map-Request message.
7.2. Attacks with Map-Reply messages 6.2. Attacks with Map-Reply messages
In this section we analyze the attacks that could occur when an off- In this section we analyze the attacks that could occur when an off-
path attacker sends directly Map-Reply messages to ETRs without using path attacker sends directly Map-Reply messages to ETRs without using
one of the proposed LISP mapping systems. one of the proposed LISP mapping systems.
There are two different types of Map-Reply messages: There are two different types of Map-Reply messages:
Positive Map-Reply: This messages contain a Map-Record binding an Positive Map-Reply: These messages contain a Map-Record binding an
EID-Prefix to one or more RLOCs. EID-Prefix to one or more RLOCs.
Negative Map-Reply: This messages contain a Map-Record for an EID- Negative Map-Reply: These messages contain a Map-Record for an EID-
Prefix with an empty locator-set and specifying an action, Prefix with an empty locator-set and specifying an action,
which may be either Drop, Natively forward, or Send Map- which may be either Drop, Natively forward, or Send Map-
Request. Request.
Positive Map-Reply messages are used to map EID-Prefixes onto RLOCs. Positive Map-Reply messages are used to map EID-Prefixes onto RLOCs.
Negative Map-Reply messages are used to support PTR and interconnect Negative Map-Reply messages are used to support PTR and interconnect
the LISP Internet with the legacy Internet. the LISP Internet with the legacy Internet.
Most of the security of the Map-Reply messages depend on the 64 bits Most of the security of the Map-Reply messages depends on the 64 bits
nonce that is included in a Map-Request and returned in the Map- nonce that is included in a Map-Request and returned in the Map-
Reply. An ETR must never accept a Map-Reply message whose nonce does Reply. An ETR must never accept a Map-Reply message whose nonce does
not match one of the pending Map-Request messages. If an ETR does not match one of the pending Map-Request messages. If an ETR does
not accept Map-Reply messages with an invalid nonce, the risk of not accept Map-Reply messages with an invalid nonce, the risk of
attack is acceptable given the size of the nonce (64 bits). attack is acceptable given the size of the nonce (64 bits).
Note, however, that the nonce only confirms that the Map-Reply was Note, however, that the nonce only confirms that the Map-Reply was
sent by the ETR that received the Map-Request. It does not validate sent by the ETR that received the Map-Request. It does not validate
the content of the Map-Reply message. the content of the Map-Reply message.
In addition, an attacker can perform EID-to-RLOC Cache overflow In addition, an attacker can perform EID-to-RLOC Cache overflow
attack by de-aggregating (i.e., splitting an EID prefix into attack by de-aggregating (i.e., splitting an EID prefix into
artificially smaller EID prefixes) either positive or negative artificially smaller EID prefixes) either positive or negative
mappings. mappings.
An attacker can combine overclaiming and de-aggregation to succeed a 6.3. Gleaning Attacks
cache poisoning attack. For example, if the attacker EID prefix is
10.0.0.0/24, she cannot provide a mapping for 10.0.1.0/24. But, as a
Map-Reply can contain several mappings, it is possible to finally
control this prefix. To do so, the attacker sends a mapping with an
EID prefix that covers at the same time the requested EID and the
prefix she wants to control. For example, if the request is for
10.0.0.1, and the target prefix is 10.0.1.0/24, the Map-Reply can
contain the mapping 10.0.0.0/23 and a mapping for 10.0.1.0/24. The
reply is perfectly legitimate according to the requested EID and the
attack is a success.
7.3. Gleaning Attacks
A third type of attack involves the gleaning mechanism proposed in A third type of attack involves the gleaning mechanism proposed in
[I-D.ietf-lisp] and discussed in [Saucez09]. In order to reduce the [I-D.ietf-lisp] and discussed in [Saucez09]. In order to reduce the
time required to obtain a mapping, [I-D.ietf-lisp] allows an ITR to time required to obtain a mapping, [I-D.ietf-lisp] allows an ITR to
learn a mapping from the LISP data encapsulated packets and the Map- learn a mapping from the LISP data encapsulated packets and the Map-
Request packets that it receives. LISP data encapsulated packet Request packets that it receives. LISP data encapsulated packet
contains a source RLOC, destination RLOC, source EID and destination contains a source RLOC, destination RLOC, source EID and destination
EID. When an ITR receives a data encapsulated packet coming from a EID. When an ITR receives a data encapsulated packet coming from a
source EID for which it does not already know a mapping, it may source EID for which it does not already know a mapping, it may
insert the mapping between the source RLOC and the source EID in its insert the mapping between the source RLOC and the source EID in its
EID-to-RLOC Cache. Gleaning can also be used when an ITR receives a EID-to-RLOC Cache. Gleaning can also be used when an ITR receives a
Map-Request as the Map-Request also contains a source EID address and Map-Request as the Map-Request also contains a source EID address and
a source RLOC. Once a gleaned entry has been added to the EID-to- a source RLOC. Once a gleaned entry has been added to the EID-to-
RLOC cache, the LISP ITR sends a Map-Request to retrieve the mapping RLOC cache, the LISP ITR sends a Map-Request to retrieve the mapping
for the gleaned EID from the mapping system. [I-D.ietf-lisp] for the gleaned EID from the mapping system. [I-D.ietf-lisp]
recommends to store the gleaned entries for only a few seconds. recommends storing the gleaned entries for only a few seconds.
The first risk of gleaning is the ability to temporarily hijack an The first risk of gleaning is the ability to temporarily hijack an
identity. Consider an off-path attacker that wants to temporarily identity. Consider an off-path attacker that wants to temporarily
hijack host HA's identity and send packets to host HB with host HA's hijack host HA's identity and send packets to host HB with host HA's
identity. If the xTRs that serve host HB do not store a mapping for identity. If the xTRs that serve host HB do not store a mapping for
host HA, a non-spoofing off-path attacker (NSA) could send a LISP host HA, a non-spoofing off-path attacker (NSA) could send a LISP
encapsulated data packet to LR3 or LR4. The ETR will store the encapsulated data packet to LR3 or LR4. The ETR will store the
gleaned entry and use it to return the packets sent by host HB to the gleaned entry and use it to return the packets sent by host HB to the
attacker. In parallel, the ETR will send a Map-Request to retrieve attacker. In parallel, the ETR will send a Map-Request to retrieve
the mapping for HA. During a few seconds or until the reception of the mapping for HA. During a few seconds or until the reception of
the Map-Reply, host HB will exchange packets with the attacker that the Map-Reply, host HB will exchange packets with the attacker that
has hijacked HA's identity. Note that the attacker could in parallel has hijacked HA's identity. Note that the attacker could in parallel
send lots of Map-Requests or lots of LISP data encapsulated packets send lots of Map-Requests or lots of LISP data encapsulated packets
with random sources to force the xTR that is responsible for host HA with random sources to force the xTR that is responsible for host HA
to send lots of Map-Request messages in order to force it to exceed to send lots of Map-Request messages in order to force it to exceed
its rate limit for control plane messages. This could further delay its rate limit for control plane messages. This could further delay
the arrival of the Map-Reply message on the requesting ETR. the arrival of the Map-Reply message on the requesting ETR.
Gleaning also introduces the possibility of a man-in-the-middle Gleaning also introduces the possibility of a man-in-the-middle
attack. Consider an off-path attacker that knows that hosts HA and attack. Consider an off-path attacker that knows that hosts HA and
HB that reside in different sites will exchange information at time HB that resides in different sites will exchange information at time
t. An off-path attacker could use this knowledge to launch a man-in- t. An off-path attacker could use this knowledge to launch a man-in-
the-middle attack if the xTRs that serve the two hosts do not have the-middle attack if the xTRs that serve the two hosts do not have
mapping for the other EID. For this, the attacker sends to LR1 mapping for the other EID. For this, the attacker sends to LR1
(resp. LR3) a LISP data encapsulated packet whose source RLOC is its (resp. LR3) a LISP data encapsulated packet whose source RLOC is its
IP address and contains an IP packet whose source is set to HB (resp. IP address and contains an IP packet whose source is set to HB (resp.
HA). The attacker chooses a packet that will not trigger an answer, HA). The attacker chooses a packet that will not trigger an answer,
for example the last part of a fragmented packet. Upon reception of for example the last part of a fragmented packet. Upon reception of
these packets, LR1 and LR3 install gleaned entries that point to the these packets, LR1 and LR3 install gleaned entries that point to the
attacker. As explained above, the attacker could, at the same time, attacker. As explained above, the attacker could, at the same time,
send lots of packets to LR1 and LR3 to force them to exhaust their send lots of packets to LR1 and LR3 to force them to exhaust their
control plane rate limit. This will extend the duration of the control plane rate limit. This will extend the duration of the
gleaned entry. If host HA establishes a flow with host HB at that gleaned entry. If host HA establishes a flow with host HB at that
time, the packets that they exchange will first pass through the time, the packets that they exchange will first pass through the
attacker. attacker.
In both cases, the attack only lasts for a few seconds (unless the In both cases, the attack only lasts for a few seconds (unless the
attacker is able to exhaust the rate limitation). However it should attacker is able to exhaust the rate limitation). However it should
be noted that today a large amount of packets may be exchanged during be noted that today a large amount of packets might be exchanged
even a small fraction of time. during even a small fraction of time.
8. Threats concerning Interworking 7. Threats concerning Interworking
[I-D.ietf-lisp-interworking] defines two network elements to allow [I-D.ietf-lisp-interworking] defines two network elements to allow
LISP and non-LISP sites to communicate, namely the Proxy-ITR and the 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 Proxy-ETR. The Proxy-ITR encapsulates traffic from non-LISP sites in
order to forward it toward LISP sites, while the Proxy-ETR order to forward it toward LISP sites, while the Proxy-ETR
decapsulates traffic arriving from LISP sites in order to forward it decapsulates traffic arriving from LISP sites in order to forward it
toward non-LISP sites. For these elements some of the attack based toward non-LISP sites. For these elements some of the attack based
on the LISP specific header are not possible, for the simple reason on the LISP specific header are not possible, for the simple reason
that some of the fields cannot be used due to the unidirectional that some of the fields cannot be used due to the unidirectional
nature of the traffic. nature of the traffic.
skipping to change at page 18, line 23 skipping to change at page 18, line 13
static entries used to check if an encapsulated packet coming from a static entries used to check if an encapsulated packet coming from a
specific RLOC and having a specific source EID is actually allowed to specific RLOC and having a specific source EID is actually allowed to
transit through the Proxy-ETR. This is also important for services transit through the Proxy-ETR. This is also important for services
provider selling Proxy-ETR service to actually process only packets provider selling Proxy-ETR service to actually process only packets
arriving from its customers. However, in case of cache-miss no Map- arriving from its customers. However, in case of cache-miss no Map-
Request needs to be sent, rather the packet can be silently dropped 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 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 should be used for packets with an invalid source RLOC or a valid
source RLOC but an invalid EID. source RLOC but an invalid EID.
9. Threats with Malicious xTRs 8. Threats with Malicious xTRs
In this section, we discuss the threats that could be caused by In this section, we discuss the threats that could be caused by
malicious xTRs. We consider the reference environment below where malicious xTRs. We consider the reference environment below where
EL1 is a malicious or compromised xTR. This malicious xTR serves a EL1 is a malicious or compromised xTR. This malicious xTR serves a
set of hosts that includes HC. The other xTR and hosts in this set of hosts that includes HC. The other xTRs and hosts in this
network play the same role as in the reference environment described network play the same role as in the reference environment described
in Section 5. in Section 4.
+-----+ +-----+
| HA | | HA |
+-----+ +-----+
| EID: HA | EID: HA
| |
----------------- -----------------
| | | |
+-----+ +-----+ +-----+ +-----+
| LR1 | | LR2 | | LR1 | | LR2 |
skipping to change at page 20, line 5 skipping to change at page 20, line 5
let us consider the following scenario. Host HC and HB exchange let us consider the following scenario. Host HC and HB exchange
packets with host HA. As all these hosts reside in LISP sites, LR1 packets with host HA. As all these hosts reside in LISP sites, LR1
and LR2 store mappings for HB and HC. Thus, these xTRs may need to and LR2 store mappings for HB and HC. Thus, these xTRs may need to
exchange LISP control plane packets with EL1, e.g., to perform exchange LISP control plane packets with EL1, e.g., to perform
reachability tests or to refresh expired mappings (e.g., if HC's reachability tests or to refresh expired mappings (e.g., if HC's
mapping has a small TTL). mapping has a small TTL).
A first threat against the LISP control plane is when EL1 replies to A first threat against the LISP control plane is when EL1 replies to
a legitimate Map-Request message sent by LR1 or LR2 with a Map-Reply a legitimate Map-Request message sent by LR1 or LR2 with a Map-Reply
message that contains an EID-Prefix that is larger than the prefix message that contains an EID-Prefix that is larger than the prefix
owned by the site attached to EL1. This could allow EL1 to attract owned by the site attached to EL1. For instance if the prefix owned
packets destined to other EIDs than the EIDs that are attached to by EL1 is 192.0.2.0/25 but the Map-Reply contain a mapping for
EL1. This attack is called an "overclaiming" attack. 192.0.2.0/24. This could allow EL1 to attract packets destined to
[I-D.maino-lisp-sec] proposes a solution to protect LISP against other EIDs than the EIDs that are attached to EL1. This attack is
overclaiming attacks under the assumption that the mapping system can called an "overclaiming" attack.
be trusted.
Another possible attack is a Denial of Service attack by sending a Overclaiming attack can be combined with de-aggregation to succeed a
Negative Map-Reply message for a coarser prefix without any locator LISP Cache poisoning attack and prefix hijacking. For example, if
and with the Drop action. Such a Negative Map-Reply indicates that the EID prefix of the attacker is 192.0.2.0/25, it cannot provide a
the ETR that receives it should discard all packets. The current mapping for the EID prefix 192.0.2.128/25 (i.e., it cannot hijack the
LISP specification briefly discusses this problem [I-D.ietf-lisp], prefix). However, since a Map-Reply can contain several map records,
but the proposed solutions does not solve the problem. it is possible to hijack such a prefix by providing as well a mapping
for it. To this end, the attacker can send a Map-Reply with an EID
prefix that covers at the same time the requested EID and the
hijacked target prefix. Continuing the previous example, if the
requested mapping is for EID 192.0.2.1, and the target hijack prefix
is 192.0.2.128/25, the Map-Reply will contain a map record for
192.0.2.0/24 and a map record for 192.0.2.128/25. Such a reply is
considered legitimate according to the requested EID, while the map
record of the hijacked prefix may lead to traffic redirection/
disruption and ITR's Cache poisoning.
Another variant of the overclaiming attack is a Denial of Service
attack by sending a Negative Map-Reply message for a larger prefix
without any locator and with the Drop action. Such a Negative Map-
Reply indicates that the ETR that receives it should discard all
packets.
The current LISP specification briefly discusses the overclaiming
problem [I-D.ietf-lisp], but does not propose any specific solution
to solve the problem. Nevertheless, [I-D.ietf-lisp-sec] proposes a
solution to protect LISP against overclaiming attacks under the
assumption that the mapping system can be trusted.
Another concern with malicious xTRs is the possibility of Denial of Another concern with malicious xTRs is the possibility of Denial of
Service attacks. A first attack is the flooding attack that was Service attacks. A first attack is the flooding attack that was
described in [I-D.bagnulo-lisp-threat]. This attack allows a described in [I-D.bagnulo-lisp-threat]. This attack allows a
malicious xTR to redirect traffic to a victim. The malicious xTR malicious xTR to redirect traffic to a victim. The malicious xTR
first defines a mapping for HC with two RLOCs: its own RLOC (EL1) and first defines a mapping for HC with two RLOCs: its own RLOC (EL1) and
the RLOC of the victim (e.g., LR3). The victim's RLOC is set as the RLOC of the victim (e.g., LR3). The victim's RLOC is set as
unreachable in the mapping. HC starts a large download from host HA. unreachable in the mapping. HC starts a large download from host HA.
Once the download starts, the malicious xTR updates its Locator Once the download starts, the malicious xTR updates its Locator
Status Bits, changes the mapping's version number or sets the SMR bit Status Bits, changes the mapping's version number or sets the SMR bit
such that LR1 updates its EID-to-RLOC Cache to send all packets such that LR1 updates its EID-to-RLOC Cache to send all packets
destined to HC to the victim's RLOC. Instead of downloading from HA, destined to HC to the victim's RLOC. Instead of downloading from HA,
the attacker could also send packets that trigger a response (e.g., the attacker could also send packets that trigger a response (e.g.,
ICMP, TCP SYN, DNS request, ...) to HA. HA would then send its ICMP, TCP SYN, DNS request, ...) to HA. HA would then send its
response and its xTR would forward it to the victim's RLOC. response and its xTR would forward it to the victim's RLOC.
An important point to note about this flooding attack is that it An important point to note about this flooding attack is that it
reveals a potential problem in the LISP architecture. A LISP ITR reveals a limitation of the LISP architecture. A LISP ITR relies on
relies on the received mapping and possible reachability information the received mapping and possible reachability information to select
to select the RLOC of the ETR that it uses to reach a given EID or the RLOC of the ETR that it uses to reach a given EID or block of
block of EIDs. However, if the ITR made a mistake, e.g., due to EIDs. However, if the ITR made a mistake, e.g., due to
configuration, implementation or other types of errors and has chosen misconfiguration, wrong implementation, or other types of errors and
a RLOC that does not serve the destination EID, there is no easy way has chosen a RLOC that does not serve the destination EID, there is
for the LISP ETR to inform the ITR of its mistake. A possible no easy way for the LISP ETR to inform the ITR of its mistake. A
solution could be to force a ETR to perform a reachability test with possible solution is to enforce an ETR to perform a reachability test
the selected ITR as soon as it selects it. This will be analyzed in with the selected ITR as soon as there is LISP encapsulated traffic
the next version of this document. between the two.
10. Security of the Proposed Mapping Systems Note that the attacks discussed in this section are for documentation
10.1. LISP+ALT 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.
9. Security of the Proposed Mapping Systems
9.1. LISP+ALT
One of the assumptions in [I-D.ietf-lisp] is that the mapping system One of the assumptions in [I-D.ietf-lisp] is that the mapping system
is more secure than sending Map-Request and Map-Reply messages is more secure than sending Map-Request and Map-Reply messages
directly. We analyze this assumption in this section by analyzing directly. We analyze this assumption in this section by analyzing
the security of the ALT mapping system. the security of the ALT mapping system.
The ALT mapping system is basically a manually configured overlay of The ALT mapping system is basically a manually configured overlay of
GRE tunnels between ALT routers. BGP sessions are established GRE tunnels between ALT routers. BGP sessions are established
between ALT routers that are connected through such a tunnel. An ALT between ALT routers that are connected through such tunnels. An ALT
router advertises the EID prefixes that it serves over its BGP router advertises the EID prefixes that it serves over its BGP
sessions with neighboring ALT routers and the EID-Prefixes that it sessions with neighboring ALT routers and the EID-Prefixes that it
has learned from neighboring ALT routers. has learned from neighboring ALT routers.
The ALT mapping system is in fact a discovery system that allows any The ALT mapping system is in fact a discovery system that allows any
ALT router to discover the ALT router that is responsible for a given ALT router to discover the ALT router that is responsible for a given
EID-Prefix. To obtain a mapping from the ALT system, an ITR sends a EID-Prefix. To obtain a mapping from the ALT system, an ITR sends a
packet containing a Map-Request on the overlay. This Map-Request is packet containing a Map-Request on the overlay. This Map-Request is
sent inside a packet whose destination is the requested EID. The sent inside a packet whose destination is the requested EID. The
Map-Request is routed on the overlay until it reaches the ALT router Map-Request is routed on the overlay until it reaches the ALT router
skipping to change at page 21, line 38 skipping to change at page 22, line 15
The security of the ALT mapping system depends on many factors, The security of the ALT mapping system depends on many factors,
including: including:
o The security of the intermediate ALT routers. o The security of the intermediate ALT routers.
o The validity of the BGP advertisements sent on the ALT overlay. o The validity of the BGP advertisements sent on the ALT overlay.
Unfortunately, experience with BGP on the global Internet has shown Unfortunately, experience with BGP on the global Internet has shown
that BGP is subject to various types of misconfiguration problems and that BGP is subject to various types of misconfiguration problems and
security attacks. The SIDR working group is developing a more secure security attacks. The SIDR working group is developing a more secure
inter-domain routing architecture to solve this problem inter-domain routing architecture to solve this problem ([RFC6480]).
([I-D.ietf-sidr-arch]).
The security of the intermediate ALT routers is another concern. A The security of the intermediate ALT routers is another concern. A
malicious intermediate ALT router could manipulate the received BGP malicious intermediate ALT router could manipulate the received BGP
advertisements and also answer to received Map-Requests without advertisements and also answer to received Map-Requests without
forwarding them to their final destination on the overlay. This forwarding them to their final destination on the overlay. This
could lead to various types of redirection attacks. Note that in could lead to various types of redirection attacks. Note that in
contrast with a regular IP router that could also manipulate in contrast with a regular IP router that could also manipulate in
transit packets, when a malicious or compromised ALT router replies transit packets, when a malicious or compromised ALT router replies
to a Map-Request, it can redirect legitimate traffic for a long to a Map-Request, it can redirect legitimate traffic for a long
period of time by sending an invalid Map-Reply message. Thus, the period of time by sending an invalid Map-Reply message. Thus, the
impact of a malicious ALT router could be much more severe than a impact of a malicious ALT router could be much more severe than a
malicious router in today's Internet. malicious router in today's Internet.
10.2. LISP-DDT 9.2. LISP-DDT
The LISP Delegated Database Tree (LISP-DDT) mapping system is The LISP Delegated Database Tree (LISP-DDT) mapping system is
proposed as an alternative for LISP+ALT [I-D.fuller-lisp-ddt]. LISP- proposed as an alternative for LISP+ALT [I-D.fuller-lisp-ddt]. LISP-
DDT is a hierarchical distributed database for EID-to-RLOC mappings. DDT is a hierarchical distributed database for EID-to-RLOC mappings.
Each DDT node is configured with an EID prefix it owns, as well as Each DDT node is configured with an EID prefix it is authoritative
the RLOC addresses and EID prefixes of the LISP-DDT nodes that own a for, as well as the RLOC addresses and EID prefixes of the LISP-DDT
more specific EID prefix than the one it owns. In LISP-DDT, mappings nodes that are authoritative for more specific EID prefix. In LISP-
are retrieved iteratively. A MR that needs to locate a mapping DDT, mappings are retrieved iteratively. A Map Resolver that needs
traverses the tree of DDT nodes contacting them one after another to locate a mapping traverses the tree of DDT nodes contacting them
until the leaf of the DDT tree that owns the longest matching EID one after another until the leaf of the DDT tree that is
prefix for the mapping's EID is reached. The MR traverses the authoritative for the longest matching EID prefix for the mapping's
hierarchy of LISP-DDT nodes by sending Map-Requests, with the LISP- EID is reached. The Map Resolver traverses the hierarchy of LISP-DDT
DDT-originated bit set, to LISP-DDT nodes. The MR first contacts the nodes by sending Map-Requests, with the LISP-DDT-originated bit set,
root of the hierarchy. When a LISP-DDT node receives a Map-Request, to LISP-DDT nodes. The Map Resolver first contacts the root of the
it replies the MR with a Map-Referral that contains the list of the hierarchy. When a LISP-DDT node receives a Map-Request, it replies
locators of its childrens that own a prefix that covers the EID in to the Map Resolver with a Map-Referral that contains the list of the
the Map-Request. The MR then contacts one of these childrens that locators of its children that are authoritative of a prefix that
will return, at its turn, a Map-Referral. This procedure is covers the EID in the Map-Request. The Map Resolver then contacts
iteratively executed until a Map-Referral marked with the done flag one of these children that will return, at its turn, a Map-Referral.
is received. The locators that appear in a referral with the done This procedure is iteratively executed until a Map-Referral marked
flag are those of the authoritative ETRs for the EID in the Map- with the done flag is received. The locators that appear in a
Request. At that moment, the MR falls back to its normal behavior referral with the done flag are those of the authoritative ETRs for
and sends a Map-Request to the ETR in order for the ITR to obtain the the EID in the Map-Request. At that moment, the Map Resolver falls
mapping. It is worth noticing that the MR can cache the referrals to back to its normal behavior and sends a Map-Request to the ETR in
avoid traversing all the whole hierarchy for every mapping order for the ITR to obtain the mapping. It is worth to mention that
retrievals. the Map Resolver can cache the referrals to avoid traversing all the
whole hierarchy for all mapping retrievals.
The operation in LISP-DDT is different from ALT and thus it does not The operation in LISP-DDT is different from ALT and thus it does not
present the same threats as LISP+ALT. However, threats exist for present the same threats as LISP+ALT. As a first difference, LISP-
LISP-DDT as well. First, a DoS attack can be performed on the MR by DDT natively includes security specification providing data origin
asking her to retrieve a large amount of mappings at the same time. authentication, data integrity protection and secure EID prefix
Indeed, the iterative operation of the MR implies that it has to delegation. Hence, these aspects are no further explored in this
maintain state about the ITR that requested the mapping, this in document.
order to send the final Map-Request to the ETR on behalf of the ITR.
An attacker might leverage on this to fill the MR memory and then However, threats exist for LISP-DDT as well. For instance, a DoS
cause a DoS on the MR. attack can 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
hierarchy.
If an attacker manages to compromise a LISP-DDT node it can send fake If an attacker manages to compromise a LISP-DDT node it can send fake
referrals to the MR and then control the mappings delivered to the referrals to the Map Resolver and then control the mappings delivered
ITRs. Furthermore, the effects of such an attack can be longer than to the ITRs. Furthermore, the effects of such an attack can be
the attack itself if the MR caches the referrals. longer than the attack itself if the Map Resolver caches the
referrals.
11. Threats concerning LISP-MS 10. Threats concerning LISP-MS
LISP-MS ([I-D.ietf-lisp-ms] specifies two network elements, namely LISP-MS ([I-D.ietf-lisp-ms] specifies two network elements, namely
the Map Server and the Map-Resolver, that are meant to be used by 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 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 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- change anything since they deal only with Map Servers and Map
Resolvers. This includes the security aspects, since no change in Resolvers. This includes the security aspects, since no change in
the local security policies is needed. the local security policies is needed.
11.1. Map Server 10.1. Map Server
Map Server is used to dispatch Map-Request coming from the mapping Map Server is used to dispatch Map-Request coming from the mapping
system to ETRs that are authoritative for the EID in the request. To system to ETRs that are authoritative for the EID in the request. To
this end it is necessary that ETRs register their mappings to the Map this end it is necessary that ETRs register their mappings to the Map
Server. This allows the Map Server to know toward which ETR to Server. This allows the Map Server to know toward which ETR to
forward Map-Requests and also to announce the EID-prefix of the forward Map-Requests and also to announce the EID-prefixes of the
mapping in the mapping system. registered mappings in the mapping system.
LISP uses a shared key approach in order to protect the Map Server LISP uses a shared key approach in order to protect the Map Server
and grant registration rights only to ETRs that have a valid key. and grant registration rights only to ETRs that have a valid key.
Shared key must be used to protect both the registration message and Shared key must be used to protect both the registration message and
the Map-Notify message when used. The mechanism used to share the the Map-Notify message when used. The mechanism used to share the
key between a MS and an ETRs must be secured to avoid that a key between a Map Server and an ETRs must be secured to avoid that a
malicious nodes catch the key and uses it to send forged Map-Register malicious nodes catch the key and uses it to send forged Map-Register
message to the MS. A forged Map-Register message can be use to message to the Map Server. A forged Map-Register message can be use
attract Map-Request and thus provide invalid Map-Replies or the to attract Map-Request and thus provide invalid Map-Replies or the
redirect Map-Requests to a target to mount a DoS attack. redirect Map-Requests to a target to mount a DoS attack.
More subtle attacks can be carried out only in the case of malicious More subtle attacks can be carried out only in the case of malicious
ETRs. A malicious ETR can register an invalid RLOC to divert Map- ETRs. A malicious ETR can register an invalid RLOC to divert Map-
Requests to a target ETR and succeed a DoS attack on it. To avoid Requests to a target ETR and succeed a DoS attack on it. To avoid
this kind of attack, the Map Server must check that the registered this kind of attack, the Map Server must check that the registered
RLOCs belongs to ETRs authoritative for the registered EID prefix. RLOCs belong to ETRs authoritative for the registered EID prefix.
Such check can be done by sending and explicit Map-Request for the Such check can be done by sending and explicit Map-Request for the
EID to the ETRs in the mapping and check that replies with a Map- EID to the ETRs in the mapping and check that replies with a Map-
Reply. If the ETRs return a valid Map-Reply, the RLOC belongs to an Reply. If the ETRs return a valid Map-Reply, the RLOC belongs to an
authoritative ETR. Note that this does not protect against malicious authoritative ETR. Note that this does not protect against malicious
ETRs that create forged Map-Replies. Stronger techniques for RLOC ETRs that create forged Map-Replies. Stronger techniques for RLOC
check are presented in [I-D.saucez-lisp-mapping-security]. check are presented in [I-D.saucez-lisp-mapping-security].
Similarly to the previous case, a malicious ETR can register an Similarly to the previous case, a malicious ETR can register an
invalid EID-prefix to attract Map-Requests or to redirect them to a 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 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 Server must check that the prefixes registered by an ETR belong to
that ETR. One method could be to manually configure EID-prefix that ETR. One method could be to manually configure EID-prefix
ranges that can be announced by ETRs. ranges that can be announced by ETRs.
[I-D.saucez-lisp-mapping-security] present alternative techniques to [I-D.saucez-lisp-mapping-security] present alternative techniques to
verify the prefix claimed by an ETR. verify the prefix claimed by an ETR.
11.2. Map-Resolver 10.2. Map Resolver
Map-Resolvers receive Map-Requests, typically from ITRs, and use the 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 mapping system to find a mapping for the EID in the Map-Request. It
can work in two modes: can work in two modes:
Non-Caching Mode: The resolver just forwards the Map-Request to the Non-Caching Mode: The resolver just forwards the Map-Request to the
mapping system, which will take care of delivering the request mapping system, which will take care of delivering the request
to an authoritative ETR. The latter will send back a Map-Reply to an authoritative ETR. The latter will send back a Map-Reply
directly to the ITR that has originally issued the request. directly to the ITR that has originally issued the request.
Caching Mode: The resolver will generate a new Map-Request and send Caching Mode: The resolver will generate a new Map-Request and send
it to the mapping system. In this way it will receive the it to the mapping system. In this way it will receive the
corresponding reply, store a local copy in a cache, and send corresponding reply, store a local copy in a cache, and send
back a reply to the original requester. Since all requested back a reply to the original requester. Since all requested
mappings are locally cached, before actually making a request mappings are locally cached, before actually making a request
to the mapping system it performs a lookup in the local cache to the mapping system it performs a lookup in the local cache
and in case of an hit, it send back a reply without querying and in case of an hit, it send back a reply without querying
the mapping system. the mapping system.
In its basic mode, i.e., non-caching mode, the Map-Resolver does not In its basic mode, i.e., non-caching mode, the Map Resolver does not
keep state, hence, the only direct form of attack is a DoS attack, keep state, hence, the only direct form of attack is a DoS attack,
where an attacker (or a group of attackers) can try to exhaust where an attacker (or a group of attackers) can try to exhaust
computational power by flooding the resolver with requests. Common computational power by flooding the resolver with requests. Common
filtering techniques and BCP against DoS attacks can be applied in filtering techniques and BCP against DoS attacks can be applied in
this case. this case.
Nonetheless, resolvers can be used by attackers as relay for DoS Nonetheless, attackers can use resolvers as relay for DoS attacks
attacks against xTRs. An off-path spoofing attacker can generate a against xTRs. An off-path spoofing attacker can generate a high load
high load of requests to a set of resolvers, hence distributing the of requests to a set of resolvers, hence distributing the load in
load in order to avoid to be blocked. All this requests can use a order to avoid to be blocked. All this requests can use a specific
specific EID that makes all the requests to be forwarded to a EID that makes all the requests to be forwarded to a specific ETR,
specific ETR, which, as a result, will be victim of a DDoS attack. which, as a result, will be victim of a DDoS attack. Similarly, the
Similarly, the attacker can use a spoofed source address making all attacker can use a spoofed source address making all the replies to
the replies to converge to one single ITR, which, as a result, will converge to one single ITR, which, as a result, will be victim of a
be victim of a DDoS attack. Such scenarios are not specific to LISP, DDoS attack. Such scenarios are not specific to LISP, but rather a
but rather a common problem of every query infrastructure, hence the common problem of every query infrastructure, hence the same BCP can
same BCP can be applied in order to limit the attacks. be applied in order to limit the attacks.
When functioning in caching-mode, the resolver will use the same type When functioning in caching-mode, the resolver will use the same type
of cache than ITRs. Due to its similarity with the ITRs' cache the of cache than ITRs. Due to its similarity with the ITRs' cache the
analysis provided in Section 6.2 holds also in this case. However, analysis provided in Section 5.2 holds also in this case. However,
an important difference exists: this cache is not used for packet an important difference exists: this cache is not used for packet
encapsulation but only for quick replies when new requests arrive. encapsulation but only for quick replies when new requests arrive.
Therefore, as the caching-mode is only an optimization, the attacks Therefore, as the caching-mode is only an optimization, the attacks
that tends to fill the MR cache have a less severe impact on the that aim at filling the Map Resolver cache have a less severe impact
traffic. on the traffic.
When Map Resolvers are used as front-end of the LIS-DDT mapping
system they may be exposed to another variant of DoS. Indeed, the
iterative operation of the Map Resolver on the DDT hierarchy implies
that it has to maintain state about the ITR that requested the
mapping, this in order to send the final Map-Request to the ETR on
behalf of the ITR. An attacker might leverage on this to fill the
Map Resolver memory and then cause a DoS.
The question may arise on whether a Kaminsky-like attack is possible The question may arise on whether a Kaminsky-like attack is possible
for an off-path attacker against ITRs sending requests to a certain for an off-path attacker against ITRs sending requests to a certain
resolver. The 64-bits nonce present in every message has been resolver. The 64-bits nonce present in every message has been
introduced in the LISP specification to avoid such kind of attack. introduced in the LISP specification to avoid such kind of attack.
There has been discussion within the LISP Working Group on the There has been discussion within the LISP Working Group on the
optimal size of the nonce, and it seems that 64-bits provides optimal size of the nonce, and it seems that 64-bits provides
sufficient protection. sufficient protection.
A possible way to limit the above-described attacks is to introduce A possible way to limit the above-described attacks is to introduce
strong identification in the Map-Request/Map-Reply by using the strong identification in the Map-Request/Map-Reply by using the
Encapsulated Control Message with authentication enabled. Encapsulated Control Message with authentication enabled.
12. Suggested Recommendations 11. Suggested Recommendations
To mitigate the impact of attacks against LISP, the following To mitigate the impact of attacks against LISP, the following
recommendations should be followed. recommendations should be followed.
First, the use of some form of filtering can help in avoid or at First, the use of some form of filtering can help in avoid or at
least mitigate some types of attacks. least mitigate some types of attacks.
o On ETRs, packets should be decapsulated only if the destination o On ETRs, packets should be decapsulated only if the destination
EID is effectively part of the EID-Prefix downstream the ETR. EID is effectively part of the EID-Prefix downstream the ETR.
Further, still on ETRs, packets should be decapsulated only if a Further, still on ETRs, packets should be decapsulated only if a
mapping for the source EID is present in the EID-to-RLOC Cache and mapping for the source EID is present in the EID-to-RLOC Cache and
has been obtained through the mapping system (not gleaned). has been obtained through the mapping system (not gleaned).
o On ITRs, packets should be encapsulated only if the source EID is o On ITRs, packets should be encapsulated only if the source EID is
effectively part of the EID-Prefix downstream the ITR. Further, effectively part of the EID-Prefix downstream the ITR. Further,
still on ITRs, packets should be encapsulated only if a mapping still on ITRs, packets should be encapsulated only if a mapping
obtained from the mapping system is present in the EID-to-RLOC obtained from the mapping system is present in the EID-to-RLOC
Cache (no Data-Probing). Cache (no Data-Probing).
Note that this filtering, since complete mappings need to be Note that this filtering, since complete mappings need to be
installed in both ITRs and ETRs, can introduce a higher connection installed in both ITRs and ETRs, can introduce higher connection
setup latency and hence potentially more packets drops due to the setup latency and hence potentially more packets drops due to the
lack of mappings in the EID-to-RLOC Cache. lack of mappings in the EID-to-RLOC Cache.
While the gleaning mechanism allows to start encapsulating packets to While the gleaning mechanism allows starting encapsulating packets to
a certain EID in parallel with the Map-Request to obtain a mapping a certain EID in parallel with the Map-Request to obtain a mapping
when a new flow is established, it creates important security risks when a new flow is established, it creates important security risks
since it allows attackers to perform identity hijacks. Although the since it allows attackers to perform identity hijacks. Although the
duration of these identity hijacks is limited (except the case of duration of these identity hijacks is limited (except the case of
rate limitation exhaustion), their impact can be severe. A first rate limitation exhaustion), their impact can be severe. A first
option would be to disable gleaning until the security concerns are option would be to disable gleaning until the security concerns are
solved. A second option would be to strictly limit the number of solved. A second option would be to strictly limit the number of
packets that can be forwarded via a gleaned entry. Overall the packets that can be forwarded via a gleaned entry. Overall the
benefits of gleaning, i.e., avoiding the loss of the first packet of benefits of gleaning, i.e., avoiding the loss of the first packet of
a flow, seems very small compared to the associated security risks. a flow, seems very small compared to the associated security risks.
Furthermore, measurements performed in data centers show that today's Furthermore, measurements performed in data centers show that today's
Internet often operate with packet loss ratio of 1 or 2 percentage Internet often operate with packet loss ratio of 1 or 2 percentage
([Chu]). These packet loss ratio are probably already orders of ([Chu]). These packet loss ratios are probably already orders of
magnitude larger than the improvement provided by the gleaning magnitude larger than the improvement provided by the gleaning
mechanism. mechanism.
With the increasing deployment of spoofing prevention techniques such With the increasing deployment of spoofing prevention techniques such
as [RFC3704] or SAVI [SAVI], it can be expected that attackers will as [RFC3704] or SAVI [SAVI], it can be expected that attackers will
become less capable of sending packets with a spoofed source address. become less capable of sending packets with a spoofed source address.
To prevent packet injection attacks from non-spoofing attackers To prevent packet injection attacks from non-spoofing attackers
(NSA), ETRs should always verify that the source RLOC of each (NSA), ETRs should always verify that the source RLOC of each
received LISP data encapsulated packet corresponds to one of the received LISP data encapsulated packet corresponds to one of the
RLOCs listed in the mappings for the source EID found in the inner RLOCs listed in the mappings for the source EID found in the inner
packet. An alternative could be to use existing IPSec techniques packet. An alternative could be to use existing IPSec techniques
[RFC4301] and when necessary including perhaps [RFC5386] to establish [RFC4301] and when necessary including perhaps [RFC5386] to establish
an authenticated tunnel between the ITR and the ETR. an authenticated tunnel between the ITR and the ETR.
[I-D.ietf-lisp] recommends to rate limit the control messages that [I-D.ietf-lisp] recommends to rate limit the control messages that
are sent by a xTR. This limit is important to deal with denial of are sent by an xTR. This limit is important to deal with denial of
service attacks. However, a strict limit, e.g., implemented with a service attacks. However, a strict limit, e.g., implemented with a
token bucket, on all the Map-Request and Map-Reply messages sent by a token bucket, on all the Map-Request and Map-Reply messages sent by
xTR is not sufficient. A xTR should distinguish between different an xTR is not sufficient. An xTR should distinguish between
types of control plane packets: different types of control plane packets:
1. The Map-Request messages that it sends to refresh expired mapping 1. The Map-Request messages that it sends to refresh expired mapping
information. information.
2. The Map-Request messages that it sends to obtain mapping 2. The Map-Request messages that it sends to obtain mapping
information because one of the served hosts tried to contact an information because one of the served hosts tried to contact an
external EID. external EID.
3. The Map-Request messages that it sends as reachability probes. 3. The Map-Request messages that it sends as reachability probes.
skipping to change at page 27, line 5 skipping to change at page 27, line 40
These control plane messages are used for different purposes. Fixing These control plane messages are used for different purposes. Fixing
a global rate limit for all control plane messages increases the risk a global rate limit for all control plane messages increases the risk
of Denial of Service attacks if a single type of control plane of Denial of Service attacks if a single type of control plane
message can exceed the configured limit. This risk could be message can exceed the configured limit. This risk could be
mitigated by either specifying a rate for each of the five types of mitigated by either specifying a rate for each of the five types of
control plane messages. Another option could be to define a maximum control plane messages. Another option could be to define a maximum
rate for all control plane messages, and prioritize the control plane rate for all control plane messages, and prioritize the control plane
messages according to the list above (with the highest priority for messages according to the list above (with the highest priority for
message type 1). message type 1).
In [I-D.ietf-lisp], there is no mechanism that allows a xTR to verify In [I-D.ietf-lisp], there is no mechanism that allows an xTR to
the validity of the content a Map-Reply message that it receives. verify the validity of the content a Map-Reply message that it
Besides the attacks discussed earlier in the document, a time-shifted receives. Besides the attacks discussed earlier in the document, a
attack where an attacker is able to modify the content of a Map-Reply time-shifted attack where an attacker is able to modify the content
message but then needs to move off-path could also create redirection of a Map-Reply message but then needs to move off-path could also
attacks. The nonce only allows a xTR to verify that a Map-Reply create redirection attacks. The nonce only allows an xTR to verify
responds to a previously sent Map-Request message. The LISP Working that a Map-Reply responds to a previously sent Map-Request message.
Group should explore solutions that allow to verify the validity and In order to allow verifying the validity and integrity of bindings
integrity of bindings between EID-Prefixes and their RLOCS (e.g., between EID-Prefixes and their RLOCS solutions proposed in
[I-D.saucez-lisp-mapping-security] and [I-D.maino-lisp-sec]). Having [I-D.saucez-lisp-mapping-security] and [I-D.ietf-lisp-sec] should be
such kind of mechanism would allow ITRs to ignore non-verified deployed. Having such kind of mechanisms would allow ITRs to ignore
mappings, thus increasing security. non-verified mappings, thus increasing security.
LISP Working Group should consider developing secure mechanisms to
allow an ETR to indicate to an ITR that it does not serve a
particular EID or block of EIDs in order to mitigate the flooding
attacks.
Finally, there is also the risk of Denial of Service attack against Finally, there is also the risk of Denial of Service attack against
the EID-to-RLOC Cache. We have discussed these attacks when the EID-to-RLOC Cache. We have discussed these attacks when
considering external attackers with, e.g., the gleaning mechanism and considering external attackers with, e.g., the gleaning mechanism and
in Section 6.2. If an ITR has a limited EID-to-RLOC Cache, a in Section 5.2. If an ITR has a limited EID-to-RLOC Cache, a
malicious or compromised host residing in the site that it serves malicious or compromised host residing in the site that it serves
could generate packets to random destinations to force the ITR to could generate packets to random destinations to force the ITR to
issue a large number of Map-Requests whose answers could fill its issue a large number of Map-Requests whose answers could fill its
cache. Faced with such misbehaving hosts, LISP ITR should be able to cache. Faced with such misbehaving hosts, LISP ITR should be able to
limit the percent of Map-Requests that it sends for a given source limit the percent of Map-Requests that it sends for a given source
EID. EID.
13. Document Status and Plans In order to mitigate flooding attacks it would be worth consider
developing secure mechanisms to allow an ETR to indicate to an ITR
In this document, we have analyzed some of the security threats that that it does not serve a particular EID or block of EIDs.
affect the Locator/Identifier Separation Protocol (LISP). We have
focused our analysis on unicast traffic and considered both the LISP
data and control planes, and provided some recommendations to improve
the security of LISP.
Revisions of this document will document the security threats of
other parts of the LISP architecture, including but not limited to:
o LISP Multicast ([I-D.ietf-lisp-multicast]).
14. IANA Considerations 12. IANA Considerations
This document makes no request to IANA. This document makes no request to IANA.
15. Security Considerations 13. Security Considerations
Security considerations are the core of this document and do not need Security considerations are the core of this document and do not need
to be further discussed in this section. to be further discussed in this section.
16. Acknowledgments 14. Acknowledgments
The flooding attack and the reference environment were first This document builds upon the draft of Marcelo Bagnulo
described in Marcelo Bagnulo's draft [I-D.bagnulo-lisp-threat]. ([I-D.bagnulo-lisp-threat]), where the flooding attack and the
reference environment were first described.
We would like to thank Jeff Wheeler for his comments. We would like to thank Jeff Wheeler for his comments.
This work has been partially supported by the INFSO-ICT-216372 This work has been partially supported by the INFSO-ICT-216372
TRILOGY Project (www.trilogy-project.org). TRILOGY Project (www.trilogy-project.org).
17. References 15. References
17.1. Normative References 15.1. Normative References
[I-D.fuller-lisp-ddt]
Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP
Delegated Database Tree", draft-fuller-lisp-ddt-04 (work
in progress), September 2012.
[I-D.ietf-lisp] [I-D.ietf-lisp]
Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
"Locator/ID Separation Protocol (LISP)", "Locator/ID Separation Protocol (LISP)",
draft-ietf-lisp-23 (work in progress), May 2012. draft-ietf-lisp-23 (work in progress), May 2012.
[I-D.ietf-lisp-alt] [I-D.ietf-lisp-alt]
Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "LISP Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "LISP
Alternative Topology (LISP+ALT)", draft-ietf-lisp-alt-10 Alternative Topology (LISP+ALT)", draft-ietf-lisp-alt-10
(work in progress), December 2011. (work in progress), December 2011.
skipping to change at page 28, line 49 skipping to change at page 29, line 30
[I-D.ietf-lisp-map-versioning] [I-D.ietf-lisp-map-versioning]
Iannone, L., Saucez, D., and O. Bonaventure, "LISP Map- Iannone, L., Saucez, D., and O. Bonaventure, "LISP Map-
Versioning", draft-ietf-lisp-map-versioning-09 (work in Versioning", draft-ietf-lisp-map-versioning-09 (work in
progress), March 2012. progress), March 2012.
[I-D.ietf-lisp-ms] [I-D.ietf-lisp-ms]
Fuller, V. and D. Farinacci, "LISP Map Server Interface", Fuller, V. and D. Farinacci, "LISP Map Server Interface",
draft-ietf-lisp-ms-16 (work in progress), March 2012. draft-ietf-lisp-ms-16 (work in progress), March 2012.
[I-D.ietf-lisp-multicast] 15.2. Informative References
Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas,
"LISP for Multicast Environments",
draft-ietf-lisp-multicast-14 (work in progress),
February 2012.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
17.2. Informative References
[Chu] Jerry Chu, H., "Tuning TCP Parameters for the 21st [Chu] Jerry Chu, H., "Tuning TCP Parameters for the 21st
Century", 75th IETF, Stockholm, July 2009, Century", 75th IETF, Stockholm, July 2009,
<http://tools.ietf.org/wg/savi/>. <http://tools.ietf.org/wg/savi/>.
[I-D.bagnulo-lisp-threat] [I-D.bagnulo-lisp-threat]
Bagnulo, M., "Preliminary LISP Threat Analysis", Bagnulo, M., "Preliminary LISP Threat Analysis",
draft-bagnulo-lisp-threat-01 (work in progress), draft-bagnulo-lisp-threat-01 (work in progress),
July 2007. July 2007.
[I-D.fuller-lisp-ddt] [I-D.ietf-lisp-sec]
Lewis, D., Farinacci, D., and V. Fuller, "LISP Delegated Maino, F., Ermagan, V., Cabellos-Aparicio, A., Saucez, D.,
Database Tree", draft-fuller-lisp-ddt-00 (work in and O. Bonaventure, "LISP-Security (LISP-SEC)",
progress), November 2011. draft-ietf-lisp-sec-04 (work in progress), October 2012.
[I-D.ietf-sidr-arch]
Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", draft-ietf-sidr-arch-13 (work in
progress), May 2011.
[I-D.ietf-tcpm-tcp-security] [I-D.ietf-tcpm-tcp-security]
Gont, F., "Survey of Security Hardening Methods for Gont, F., "Survey of Security Hardening Methods for
Transmission Control Protocol (TCP) Implementations", Transmission Control Protocol (TCP) Implementations",
draft-ietf-tcpm-tcp-security-03 (work in progress), draft-ietf-tcpm-tcp-security-03 (work in progress),
March 2012. March 2012.
[I-D.lear-lisp-nerd] [I-D.lear-lisp-nerd]
Lear, E., "NERD: A Not-so-novel EID to RLOC Database", Lear, E., "NERD: A Not-so-novel EID to RLOC Database",
draft-lear-lisp-nerd-09 (work in progress), April 2012. draft-lear-lisp-nerd-09 (work in progress), April 2012.
[I-D.maino-lisp-sec]
Maino, F., Ermagan, V., Cabellos-Aparicio, A., Saucez, D.,
and O. Bonaventure, "LISP-Security (LISP-SEC)",
draft-maino-lisp-sec-00 (work in progress), March 2011.
[I-D.meyer-lisp-cons] [I-D.meyer-lisp-cons]
Brim, S., "LISP-CONS: A Content distribution Overlay Brim, S., "LISP-CONS: A Content distribution Overlay
Network Service for LISP", draft-meyer-lisp-cons-04 (work Network Service for LISP", draft-meyer-lisp-cons-04 (work
in progress), April 2008. in progress), April 2008.
[I-D.saucez-lisp-mapping-security] [I-D.saucez-lisp-mapping-security]
Saucez, D. and O. Bonaventure, "Securing LISP Mapping Saucez, D. and O. Bonaventure, "Securing LISP Mapping
replies", draft-saucez-lisp-mapping-security-00 (work in replies", draft-saucez-lisp-mapping-security-00 (work in
progress), February 2011. progress), February 2011.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004. Networks", BCP 84, RFC 3704, March 2004.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[RFC5386] Williams, N. and M. Richardson, "Better-Than-Nothing [RFC5386] Williams, N. and M. Richardson, "Better-Than-Nothing
Security: An Unauthenticated Mode of IPsec", RFC 5386, Security: An Unauthenticated Mode of IPsec", RFC 5386,
November 2008. 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 [SAVI] IETF, "Source Address Validation Improvements Working
Group", <http://tools.ietf.org/wg/savi/>. Group", <http://tools.ietf.org/wg/savi/>.
[Saucez09] [Saucez09]
Saucez, D. and L. Iannone, "How to mitigate the effect of Saucez, D. and L. Iannone, "How to mitigate the effect of
scans on mapping systems", Submitted to the Trilogy scans on mapping systems", Submitted to the Trilogy
Summer School on Future Internet. Summer School on Future Internet.
Appendix A. Document Change Log Appendix A. Document Change Log
o Version 03 Posted October 2012.
* Dropped Reference to RFC 2119 notation because it is not
actually used in the document.
* Deleted future plans section.
* Updated References
* Deleted/Modified sentences referring to the early status of the
LISP WG and documents at the time of writing early versions of
the document.
* Further editorial polishing.
* Fixed all ID nits.
o Version 02 Posted September 2012. o Version 02 Posted September 2012.
* Added a new attack that combines overclaiming and de- * Added a new attack that combines overclaiming and de-
aggregation (see Section 7.2). aggregation (see Section 6.2).
* Editorial polishing. * Editorial polishing.
o Version 01 Posted February 2012. o Version 01 Posted February 2012.
* Added discussion on LISP-DDT in Section 10.2. * Added discussion on LISP-DDT in Section 9.2.
o Version 00 Posted July 2011. o Version 00 Posted July 2011.
* Added discussion on LISP-MS in Section 11. * Added discussion on LISP-MS in Section 10.
* Added discussion on Instance ID in Section 6.4. * Added discussion on Instance ID in Section 5.4.
* Editorial polishing of the whole document. * Editorial polishing of the whole document.
* Added "Change Log" appendix to keep track of main changes. * Added "Change Log" appendix to keep track of main changes.
* Renamed "draft-saucez-lisp-security-03.txt. * Renamed "draft-saucez-lisp-security-03.txt.
Authors' Addresses Authors' Addresses
Damien Saucez Damien Saucez
 End of changes. 127 change blocks. 
331 lines changed or deleted 355 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/