draft-ietf-lisp-threats-04.txt   draft-ietf-lisp-threats-05.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: August 29, 2013 Telecom ParisTech Expires: March 2, 2014 Telecom ParisTech
O. Bonaventure O. Bonaventure
Universite catholique de Louvain Universite catholique de Louvain
February 25, 2013 August 29, 2013
LISP Threats Analysis LISP Threats Analysis
draft-ietf-lisp-threats-04.txt draft-ietf-lisp-threats-05.txt
Abstract Abstract
This document analyzes the potential threats against the security of This document discusses potential security concerns with the Locator/
the Locator/Identifier Separation Protocol (LISP) if deployed in the Identifier Separation Protocol (LISP) if deployed in the Internet and
Internet. This document proposes a set of recommendations to proposes a set of recommendations to mitigate the identified threats
mitigate the identified security risks and keep a security level and to reach a level of security equivalent to what is observed in
equivalent to what is observed in the Internet today (i.e., without the Internet today (i.e., without LISP). By following the
LISP). By following the recommendations of this draft a LISP recommendations of this draft a LISP deployment can achieve a
deployment can achieve a security level that is comparable to the security level that is comparable to the existing Internet
existing Internet architecture. architecture.
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 August 29, 2013. This Internet-Draft will expire on March 2, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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
skipping to change at page 2, line 16 skipping to change at page 2, line 16
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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4
3. On-path Attackers . . . . . . . . . . . . . . . . . . . . . . 4 3. On-path Attackers . . . . . . . . . . . . . . . . . . . . . . 4
4. Off-Path Attackers: Reference Environment . . . . . . . . . . 5 4. Off-Path Attackers: Reference Environment . . . . . . . . . . 4
5. Data-Plane Threats . . . . . . . . . . . . . . . . . . . . . . 6 5. Data-Plane Threats . . . . . . . . . . . . . . . . . . . . . . 6
5.1. EID-to-RLOC Database Threats . . . . . . . . . . . . . . . 7 5.1. EID-to-RLOC Database Threats . . . . . . . . . . . . . . . 6
5.2. EID-to-RLOC Cache Threats . . . . . . . . . . . . . . . . 7 5.2. EID-to-RLOC Cache Threats . . . . . . . . . . . . . . . . 7
5.2.1. EID-to-RLOC Cache poisoning . . . . . . . . . . . . . 7 5.2.1. EID-to-RLOC Cache poisoning . . . . . . . . . . . . . 7
5.2.2. EID-to-RLOC Cache overflow . . . . . . . . . . . . . . 9 5.2.2. EID-to-RLOC Cache overflow . . . . . . . . . . . . . . 9
5.3. Attacks not leveraging on the LISP header . . . . . . . . 10 5.3. Attacks not leveraging on the LISP header . . . . . . . . 9
5.4. Attacks leveraging on the LISP header . . . . . . . . . . 10 5.4. Attacks leveraging on the LISP header . . . . . . . . . . 10
5.4.1. Attacks using the Locator Status Bits . . . . . . . . 10 5.4.1. Attacks using the Locator Status Bits . . . . . . . . 10
5.4.2. Attacks using the Map-Version bit . . . . . . . . . . 12 5.4.2. Attacks using the Map-Version bit . . . . . . . . . . 11
5.4.3. Attacks using the Nonce-Present and the Echo-Nonce 5.4.3. Attacks using the Nonce-Present and the Echo-Nonce
bits . . . . . . . . . . . . . . . . . . . . . . . . . 13 bits . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.4.4. Attacks using the Instance ID bits . . . . . . . . . . 14 5.4.4. Attacks using the Instance ID bits . . . . . . . . . . 14
6. Control Plane Threats . . . . . . . . . . . . . . . . . . . . 14 6. Control Plane Threats . . . . . . . . . . . . . . . . . . . . 14
6.1. Attacks with Map-Request messages . . . . . . . . . . . . 14 6.1. Attacks with Map-Request messages . . . . . . . . . . . . 14
6.2. Attacks with Map-Reply messages . . . . . . . . . . . . . 16 6.2. Attacks with Map-Reply messages . . . . . . . . . . . . . 16
6.3. Gleaning Attacks . . . . . . . . . . . . . . . . . . . . . 17 6.3. Gleaning Attacks . . . . . . . . . . . . . . . . . . . . . 17
7. Threats concerning Interworking . . . . . . . . . . . . . . . 18 7. Threats concerning Interworking . . . . . . . . . . . . . . . 18
8. Threats with Malicious xTRs . . . . . . . . . . . . . . . . . 19 8. Threats with Malicious xTRs . . . . . . . . . . . . . . . . . 19
9. Security of the Proposed Mapping Systems . . . . . . . . . . . 23 9. Security of the Proposed Mapping Systems . . . . . . . . . . . 22
9.1. LISP+ALT . . . . . . . . . . . . . . . . . . . . . . . . . 23 9.1. LISP+ALT . . . . . . . . . . . . . . . . . . . . . . . . . 22
9.2. LISP-DDT . . . . . . . . . . . . . . . . . . . . . . . . . 24 9.2. LISP-DDT . . . . . . . . . . . . . . . . . . . . . . . . . 24
10. Threats concerning LISP-MS . . . . . . . . . . . . . . . . . . 25 10. Threats concerning LISP-MS . . . . . . . . . . . . . . . . . . 25
10.1. Map Server . . . . . . . . . . . . . . . . . . . . . . . . 25 10.1. Map Server . . . . . . . . . . . . . . . . . . . . . . . . 25
10.2. Map Resolver . . . . . . . . . . . . . . . . . . . . . . . 26 10.2. Map Resolver . . . . . . . . . . . . . . . . . . . . . . . 26
11. Security Recommendations . . . . . . . . . . . . . . . . . . . 28 11. Security Recommendations . . . . . . . . . . . . . . . . . . . 27
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
13. Security Considerations . . . . . . . . . . . . . . . . . . . 30 13. Security Considerations . . . . . . . . . . . . . . . . . . . 30
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
15.1. Normative References . . . . . . . . . . . . . . . . . . . 31 15.1. Normative References . . . . . . . . . . . . . . . . . . . 30
15.2. Informative References . . . . . . . . . . . . . . . . . . 31 15.2. Informative References . . . . . . . . . . . . . . . . . . 31
Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 32 Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
1. Introduction 1. Introduction
The Locator/ID Separation Protocol (LISP) is defined in [RFC6830]. The Locator/ID Separation Protocol (LISP) is defined in [RFC6830].
The present document assesses the security level and identifies The present document assesses the security level and identifies
security threats in the LISP specification if LISP is deployed in the security threats in the LISP specification if LISP is deployed in the
Internet (i.e., a public non-trustable environment). As a result of Internet (i.e., a public non-trustable environment). As a result of
the performed analysis, the document determines the severity of the the performed analysis, the document discusses the severity of the
threats and proposes recommendations to reach the same level of threats and proposes recommendations to reach the same level of
security in LISP than in Internet today (e.g., without LISP). security in LISP than in Internet today (e.g., without LISP).
The document is composed of three main parts: the first discussing The document is composed of three main parts: the first discussing
the LISP data-plane; while the second discussing the LISP control- the LISP data-plane; while the second discussing the LISP control-
plane. The final part summarizes the recommendations to prevent the plane. The final part summarizes the recommendations to prevent the
identified threats. identified threats.
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
skipping to change at page 3, line 46 skipping to change at page 3, line 46
mapping system described in [I-D.ietf-lisp-ddt]. The reading of mapping system described in [I-D.ietf-lisp-ddt]. The reading of
these documents is a prerequisite for understanding the present these documents is a prerequisite for understanding the present
document. document.
Unless otherwise stated, the document assumes a generic IP service Unless otherwise stated, the document assumes a generic IP service
and does not discuss the difference, from a security viewpoint, and does not discuss the difference, from a security viewpoint,
between using IPv4 or IPv6. between using IPv4 or IPv6.
This document has identified several threats on LISP in the case of This document has identified several threats on LISP in the case of
public deployments. However, most of the threats can be prevented public deployments. However, most of the threats can be prevented
with careful deployment and configuration. Moreover, several threats with careful deployment and configuration. A general recommendation
are introduced by optimization techniques that can be deactivated in is to deactivate every feature that is not necessary in the
public deployments of LISP without alteration of its functioning as deployment of interest and carefully verify the validity of the
these techniques are designed for LISP deployments in private information obtained from third parties. Finally, this document has
trustable environments. Finally, this document has not identified not identified any threats that would require a change in the LISP
any threats that would require a change in the LISP protocol or protocol or architecture.
architecture.
2. Definition of Terms 2. Definition of Terms
Severity level: this document specifies the severity level of every
identified threat. We identified four severity levels for the
threats.
Level 0: the threat is not introduced by LISP and is equivalent to
what is encountered without LISP.
Level 1: the threat is introduced by LISP but can be neutralized by
configuration or deployment techniques, i.e., LISP protocol and
architecture does not need to be reconsidered for public
deployment.
Level 2: the threat is introduced by LISP but can be avoided by
deactivating the feature in public deployment.
Level 3: the threat is introduced by LISP and cannot be avoided
without changing the LISP specification or architecture.
The present document does not introduce any other new term, compared The present document does not introduce any other new term, compared
to the main LISP specification. For a complete list of terms please to the main LISP specification. For a complete list of terms please
refer to [RFC6830]. refer to [RFC6830].
3. 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 Ingress Tunnel Router (ITR) and all the packets exchanged between an Ingress Tunnel Router (ITR) and
an Egress Tunnel Router (ETR). To cope with such an attacker, an Egress Tunnel Router (ETR). To cope with such an attacker,
cryptographic techniques such as those used by IPSec ([RFC4301]) are cryptographic techniques such as those used by IPSec ([RFC4301]) are
skipping to change at page 7, line 22 skipping to change at page 7, line 13
"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 [RFC6830], the EID-to-RLOC Database content is As described in [RFC6830], 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.
Severity level 0.
5.2. EID-to-RLOC Cache Threats 5.2. EID-to-RLOC Cache Threats
The EID-to-RLOC Cache (also called the Map-Cache) is the data The EID-to-RLOC Cache (also called the Map-Cache) is the data
structure that stores a copy of the mappings retrieved from a remote structure that stores a copy of the mappings retrieved from a remote
ETR's mapping database via the LISP control plane. Attacks against ETR's mapping database via the LISP control plane. Attacks against
this data structure could happen either when the mappings are first this data structure could happen either when the mappings are first
installed in the cache (see also Section 6) or by corrupting installed in the cache (see also Section 6) or by corrupting
(poisoning) the mappings already present in the cache. (poisoning) the mappings already present in the cache.
Severity level 2. The severity level of EID-to-RLOC Cache Threats The severity level of EID-to-RLOC Cache Threats depends on the attack
depends on the attack vector as described below. vector as described below.
5.2.1. EID-to-RLOC Cache poisoning 5.2.1. EID-to-RLOC Cache poisoning
The content of the EID-to-RLOC Cache could be poisoned by spoofing The content of the EID-to-RLOC Cache could be poisoned by spoofing
LISP encapsulated packets. Examples of EID-to-RLOC Cache poisoning LISP encapsulated packets. Examples of EID-to-RLOC Cache poisoning
are: 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 could be originate from an authoritative mapping server. This could be
achieved either through gleaning as described in Section 6.3 or achieved either through gleaning as described in Section 6.3 or
skipping to change at page 10, line 32 skipping to change at page 10, line 21
The destination address of the encapsulated packet could be LR3 or The destination address of the encapsulated packet could be LR3 or
LR4. When the LISP ETR that serves HB receives the encapsulated LR4. When the LISP ETR that serves HB receives the encapsulated
packet, it can consult its EID-to-RLOC Cache and verify that NSA is packet, it can consult its EID-to-RLOC Cache and verify that NSA is
not a valid source address for LISP encapsulated packets containing a not a valid source address for LISP encapsulated packets containing a
packet sent by HA. This verification is only possible if the ETR packet sent by HA. This verification is only possible if the ETR
already has a valid mapping for HA. Otherwise, and to avoid such already has a valid mapping for HA. Otherwise, and to avoid such
data packet injection attacks, the LISP ETR should reject the packet data packet injection attacks, the LISP ETR should reject the packet
and possibly query the mapping system to obtain a mapping for the and possibly query the mapping system to obtain a mapping for the
encapsulated source EID (HA). encapsulated source EID (HA).
Severity level 1: use well known anti-spoofing techniques and The risk can be reduced by using well known anti-spoofing techniques
configure ETRs to verify the that RLOCs and EIDs are consistent with and configuring ETRs to verify the that RLOCs and EIDs are consistent
the entries in the EID-to-RLOC Cache. with the entries in the EID-to-RLOC Cache.
5.4. Attacks leveraging on the LISP header 5.4. Attacks leveraging on the LISP header
The main LISP document [RFC6830] defines several flags that modify The main LISP document [RFC6830] defines several flags that modify
the interpretation of the LISP header in data packets. In this the interpretation of the LISP header in data packets. In this
section, we discuss how an off-path attacker could exploit this LISP section, we discuss how an off-path attacker could exploit this LISP
header. header.
Severity level 2. The severity level of attacks leveraging on the The severity level of attacks leveraging on the LISP header depends
LISP header depends on the attack vector as described below. on the attack vector as described below.
5.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
skipping to change at page 11, line 49 skipping to change at page 11, line 39
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 could Nevertheless, in this case a Map-Request should be sent, which could
be used to perform Denial of Service attacks. Indeed an attacker be used to perform Denial of Service attacks. Indeed an attacker
could frequently change the Locator Status Bits in order to trigger a could frequently change the Locator Status Bits in order to trigger a
large amount of Map-Requests. Rate limitation, as described in large amount of Map-Requests. Rate limitation, as described in
[RFC6830], if implemented in a very simple way a single bucket for [RFC6830], if implemented in a very simple way a single bucket for
all triggered control plane messages, does not allow sending high all triggered control plane messages, does not allow sending high
number of such a request, resulting in the attacker saturating the number of such a request, resulting in the attacker saturating the
rate with these spoofed packets. rate with these spoofed packets.
Severity level 2: to avoid any risk, Locator Status Bits should be Assuming the correct deployment of anti-spoofing techniques, every
deactivated in public deployments of LISP. Deactivating LSB does not reachability change discovered with LSB SHOULD be verified (e.g.,
reduce LISP functionality. using routing information base, or low frequency probing).
5.4.2. Attacks using the Map-Version bit 5.4.2. Attacks using the Map-Version bit
The optional Map-Version bit is used to indicate whether the low- The optional Map-Version bit is used to indicate whether the low-
order 24 bits of the first 32 bits longword of the LISP header order 24 bits of the first 32 bits longword of the LISP header
contain a Source and Destination Map-Version. When a LISP ETR contain a Source and Destination Map-Version. When a LISP ETR
receives a LISP encapsulated packet with the Map-Version bit set to receives a LISP encapsulated packet with the Map-Version bit set to
1, the following actions are taken: 1, the following 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
skipping to change at page 12, line 51 skipping to change at page 12, line 43
policy, the ETR might consume its entire rate by sending Map-Request policy, the ETR might consume its entire rate by sending Map-Request
messages in response to these spoofed packets. messages in response to these spoofed packets.
A non-spoofing off-path attacker (NSA) could not success in such an A non-spoofing off-path attacker (NSA) could not 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 could be able to perform EID. If it is not the case, the attacker could 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).
Severity level 1: the correct deployment of anti-spoofing and rate The correct deployment of anti-spoofing and rate limitation
limitation techniques prevents the attacks leveraging on the Map- techniques prevents the attacks leveraging on the Map-Version.
Version.
5.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.
skipping to change at page 14, line 9 skipping to change at page 13, line 48
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 5.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.
Severity level 2: to avoid any problem, echo nonce should be Assuming the correct deployment of anti-spoofing techniques, every
deactivated. Deactivating echo-nonce does not reduce LISP reachability change discovered with echo-nonce SHOULD be verified
functionality as it is an optimization for symmetric data flow path (e.g., using routing information base, or low frequency probing).
and because other techniques exist to test the reachability of a
RLOC.
5.4.4. Attacks using the Instance ID bits 5.4.4. Attacks using the Instance ID 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.
Severity level 1: the correct deployment of access control lists and The correct deployment of access control lists and firewalls prevent
firewalls prevent the attacks leveraging on the Instance ID. the attacks leveraging on the Instance ID.
6. Control Plane Threats 6. Control Plane Threats
In this section, we discuss the different types of attacks that could In this section, we discuss the different types of attacks that could
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 9. and LISP-DDT mapping systems are discussed in Section 9.
Severity level 2. The severity level of attacks on the LISP control- The severity of attacks on the LISP control-plane depends on the
plane depends on the attack vector as described below. attack vector as described below.
6.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 [RFC6830] contains several particularities that could specification [RFC6830] contains several particularities that could
be exploited by an off-path attacker. 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
skipping to change at page 16, line 13 skipping to change at page 15, line 52
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
discussed above except that as the Map-Request messages are smaller discussed above except that as the Map-Request messages are smaller
than Map-Reply messages, the risk of amplification attacks is than Map-Reply messages, the risk of amplification attacks is
reduced. This is not true anymore if the ETR append to the Map- reduced. This is not true anymore if the ETR append to the Map-
Request messages its own Map-Records. This mechanism is meant to Request messages its own Map-Records. This mechanism is meant to
reduce the delay in mapping distribution since mapping information is reduce the delay in mapping distribution since mapping information is
provided in the Map-Request message. provided in the Map-Request message.
Severity level 1: the correct deployment of anti-spoofing and rate The correct deployment of anti-spoofing and rate limitation
limitation techniques prevents the attacks leveraging the Map-Request techniques prevents the attacks leveraging the Map-Request message.
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.
information that it receives in a Map-Request message. As it is a
performance optimization, we recommend to deactivate this
functionality in public LISP deployments.
Severity level 2: to avoid any risk, appending Map-Records to Map- A mappings learned from a Map-Request message appending Map-Records
Request messages should be deactivated in public deployments of LISP. SHOULD be verified, particularly if it overrides mappings previously
Deactivating appending Map-Records to Map-Request messages does not installed in the EID-to-RLOC cache of the ITR.
reduce LISP functionality.
6.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: These messages contain a Map-Record binding an Positive Map-Reply: These messages contain a Map-Record binding an
skipping to change at page 17, line 21 skipping to change at page 17, line 6
The nonce only confirms that the map-reply received was sent in The nonce only confirms that the map-reply received was sent in
response to a map-request sent, it does not validate the contents of response to a map-request sent, it does not validate the contents of
that map-reply. that map-reply.
In addition, an attacker could perform EID-to-RLOC Cache overflow In addition, an attacker could 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.
Severity level 1: the correct deployment of anti-spoofing techniques The correct deployment of anti-spoofing techniques prevents attacks
prevents attacks leveraging the Map-Reply message. leveraging the Map-Reply message.
6.3. Gleaning Attacks 6.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
[RFC6830] and discussed in [Saucez09]. In order to reduce the time [RFC6830] and discussed in [Saucez09]. In order to reduce the time
required to obtain a mapping, [RFC6830] allows an ITR to learn a required to obtain a mapping, [RFC6830] allows an ITR to learn a
mapping from the LISP data encapsulated packets and the Map-Request mapping from the LISP data encapsulated packets and the Map-Request
packets that it receives. LISP data encapsulated packet contains a packets that it receives. LISP data encapsulated packet contains a
source RLOC, destination RLOC, source EID and destination EID. When source RLOC, destination RLOC, source EID and destination EID. When
an ITR receives a data encapsulated packet coming from a source EID an ITR receives a data encapsulated packet coming from a source EID
skipping to change at page 18, line 33 skipping to change at page 18, line 20
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 might be exchanged be noted that today a large amount of packets might be exchanged
during even a small fraction of time. during even a small fraction of time.
Severity level 2: to avoid any risk, gleaning should be deactivated To limit the risk of attacks leveraging gleaning, the scope of a
in public deployments of LISP. Deactivating gleaning does not reduce gleaned mapping should be limited to the flow that triggered the
LISP functionality. gleaned mapping as proposed in [Saucez09].
7. Threats concerning Interworking 7. Threats concerning Interworking
[RFC6832] defines two network elements to allow LISP and non-LISP [RFC6832] defines two network elements to allow LISP and non-LISP
sites to communicate, namely the Proxy-ITR and the Proxy-ETR. The sites to communicate, namely the Proxy-ITR and the Proxy-ETR. The
Proxy-ITR encapsulates traffic from non-LISP sites in order to Proxy-ITR encapsulates traffic from non-LISP sites in order to
forward it toward LISP sites, while the Proxy-ETR decapsulates forward it toward LISP sites, while the Proxy-ETR decapsulates
traffic arriving from LISP sites in order to forward it toward non- traffic arriving from LISP sites in order to forward it toward non-
LISP sites. For these elements some of the attack based on the LISP LISP sites. For these elements some of the attack based on the LISP
specific header are not possible, for the simple reason that some of specific header are not possible, for the simple reason that some of
skipping to change at page 19, line 42 skipping to change at page 19, line 28
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.
As it is the case without LISP, the addition of public proxies offers As it is the case without LISP, the addition of public proxies offers
opportunities to attackers to commit attacks. LISP interworking does opportunities to attackers to commit attacks. LISP interworking does
not open new threats compared to other interworking techniques based not open new threats compared to other interworking techniques based
on public proxies. on public proxies.
Severity level 0: the careful configuration of PETR and PITR combined The careful configuration of PETR and PITR combined with the
with the deployment of anti-spoofing techniques mitigates the attacks deployment of anti-spoofing techniques mitigates the attacks
leveraging interworking and provides the same level of severity as leveraging interworking and provides the same level of severity as
interworking techniques in the Internet. interworking techniques in the Internet.
8. 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 xTRs 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
skipping to change at page 22, line 45 skipping to change at page 22, line 40
between the two. We recommend to never use reachability information between the two. We recommend to never use reachability information
without verifying them first. without verifying them first.
Note that the attacks discussed in this section are for documentation Note that the attacks discussed in this section are for documentation
purpose only. Malicious xTRs are either somehow directly deployed by purpose only. Malicious xTRs are either somehow directly deployed by
attackers or the result of attackers gaining privileged access to attackers or the result of attackers gaining privileged access to
existing xTRs. As such, it is out of the scope of LISP to propose 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 any mechanism to protect routers or to avoid their deployments with
malicious intentions. malicious intentions.
Severity level 2: the correct deployment of anti-spoofing and rate The correct deployment of anti-spoofing and rate limiting techniques
limiting techniques combined with LISP-Sec and Map-Register combined with LISP-Sec and Map-Register authentication prevents
authentication prevents threats caused by malicious xTRs, as long as threats caused by malicious xTRs, as long as mappings are always
mappings are always retrieved via a trustable mapping system. In retrieved via a trustable mapping system. In addition reachability
addition reachability information should never been used without information SHOULD be verified before usage.
being verified first.
9. Security of the Proposed Mapping Systems 9. Security of the Proposed Mapping Systems
9.1. LISP+ALT 9.1. LISP+ALT
One of the assumptions in [RFC6830] is that the mapping system is One of the assumptions in [RFC6830] is that the mapping system is
more secure than sending Map-Request and Map-Reply messages directly. more secure than sending Map-Request and Map-Reply messages directly.
We analyze this assumption in this section by analyzing the security We analyze this assumption in this section by analyzing the security
of the ALT mapping system. 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 tunnels. 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.
skipping to change at page 24, line 8 skipping to change at page 23, line 51
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 more severe than a impact of a malicious ALT router could be more severe than a
malicious router in today's Internet. BGP is also weak in case of a malicious router in today's Internet. BGP is also weak in case of a
router involved in the BGP topology is compromised. router involved in the BGP topology is compromised.
Severity level 1: configuring correctly the Map Servers, Map Configuring correctly the Map Servers, Map Revolvers, and ALT routers
Revolvers, and ALT routers with filters corresponding to their with filters corresponding to their customer cones provides the same
customer cones provides the same security level as in BGP. If more security level as in BGP. If more security is necessary,
security is necessary, cryptography must be used to validate the cryptography must be used to validate the mappings themselves.
mappings themselves.
9.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.ietf-lisp-ddt]. LISP- proposed as an alternative for LISP+ALT [I-D.ietf-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 is authoritative Each DDT node is configured with an EID prefix it is authoritative
for, as well as the RLOC addresses and EID prefixes of the LISP-DDT for, as well as the RLOC addresses and EID prefixes of the LISP-DDT
nodes that are authoritative for more specific EID prefix. In LISP- nodes that are authoritative for more specific EID prefix. In LISP-
DDT, mappings are retrieved iterative. A Map Resolver that needs to DDT, mappings are retrieved iterative. A Map Resolver that needs to
skipping to change at page 25, line 5 skipping to change at page 24, line 46
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. As a first difference, LISP- present the same threats as LISP+ALT. As a first difference, LISP-
DDT natively includes security specification providing data origin DDT natively includes security specification providing data origin
authentication, data integrity protection and secure EID prefix authentication, data integrity protection and secure EID prefix
delegation. Hence, these aspects are no further explored in this delegation. Hence, these aspects are no further explored in this
document. document.
However, threats exist for LISP-DDT as well. For instance, a DoS However, threats exist for LISP-DDT as well. For instance, a DoS
attack could be performed on the mapping infrastructure by asking to attack could be performed on the mapping infrastructure by asking to
retrieve a large amount of mappings at the same time, hence, the retrieve a large amount of mappings at the same time, hence, the
importance of carefully dimensioning the topology of the DDT importance of carefully provisioning the topology of the DDT
hierarchy. hierarchy.
If an attacker manages to compromise a LISP-DDT node it could send If an attacker manages to compromise a LISP-DDT node it could send
fake referrals to the Map Resolver and then control the mappings fake referrals to the Map Resolver and then control the mappings
delivered to the ITRs. Furthermore, the effects of such an attack delivered to the ITRs. Furthermore, the effects of such an attack
could be longer than the attack itself if the Map Resolver caches the could be longer than the attack itself if the Map Resolver caches the
referrals. referrals.
Severity level 1: the correct deployment of anti-spoofing and rate The correct deployment of anti-spoofing and rate limiting techniques
limiting techniques combined with embedded security features of LISP- combined with embedded security features of LISP-DDT prevent attacks
DDT prevent attacks leveraging LISP-DDT. leveraging LISP-DDT.
10. Threats concerning LISP-MS 10. Threats concerning LISP-MS
LISP-MS ([RFC6833] specifies two network elements, namely the Map LISP-MS ([RFC6833] specifies two network elements, namely the Map
Server and the Map Resolver, that are meant to be used by xTRs to Server and the Map Resolver, that are meant to be used by xTRs to
access the mapping system. The advantage is clearly the fact that access the mapping system. The advantage is clearly the fact that
even if the mapping system changes in time xTRs do not need to change even if the mapping system changes in time xTRs do not need to change
anything since they deal only with Map Servers and Map Resolvers. anything since they deal only with Map Servers and Map Resolvers.
This includes the security aspects, since no change in the local This includes the security aspects, since no change in the local
security policies is needed. security policies is needed.
skipping to change at page 26, line 21 skipping to change at page 26, line 14
Similarly to the previous case, a malicious ETR could register an Similarly to the previous case, a malicious ETR could 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.
Severity level 1: the correct deployment of anti-spoofing and rate The correct deployment of anti-spoofing and rate limiting techniques
limiting techniques combined with usage of Map-Register combined with usage of Map-Register authentication prevents attacks
authentication prevents attacks leveraging the Map Server. leveraging the Map Server.
10.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
skipping to change at page 27, line 51 skipping to change at page 27, line 42
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
[I-D.ietf-lisp-sec]. [I-D.ietf-lisp-sec].
Severity level 1: the correct deployment of anti-spoofing and rate The correct deployment of anti-spoofing and rate limiting techniques
limiting techniques combined with LISP-Sec and Map-Register combined with LISP-Sec and Map-Register authentication prevent
authentication prevent attacks leveraging Map Resolver. attacks leveraging Map Resolver.
11. Security Recommendations 11. Security Recommendations
Different deployments of LISP may have different security Different deployments of LISP may have different security
requirements. The recommendations in this document aim at mitigating requirements. The recommendations in this document aim at mitigating
threats in in public deployments of LISP. threats in in public deployments of LISP.
To mitigate the impact of attacks against LISP in public deployments, To mitigate the impact of attacks against LISP in public deployments,
the following recommendations should be followed. the following recommendations should be followed.
skipping to change at page 30, line 41 skipping to change at page 30, line 33
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.
14. Acknowledgments 14. Acknowledgments
This document builds upon the draft of Marcelo Bagnulo This document builds upon the draft of Marcelo Bagnulo
([I-D.bagnulo-lisp-threat]), where the flooding attack and the ([I-D.bagnulo-lisp-threat]), where the flooding attack and the
reference environment were first described. reference environment were first described.
The authors would like to thank Vina Ermagan, Darrel Lewis, and Jeff The authors would like to thank Florin Coras, Vina Ermagan, Darrel
Wheeler for their comments. Lewis, and Jeff Wheeler for their 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).
15. References 15. References
15.1. Normative References 15.1. Normative References
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
Locator/ID Separation Protocol (LISP)", RFC 6830, Locator/ID Separation Protocol (LISP)", RFC 6830,
January 2013. January 2013.
[RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
"Interworking between Locator/ID Separation Protocol "Interworking between Locator/ID Separation Protocol
(LISP) and Non-LISP Sites", RFC 6832, January 2013. (LISP) and Non-LISP Sites", RFC 6832, January 2013.
skipping to change at page 31, line 42 skipping to change at page 31, line 35
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.ietf-lisp-ddt] [I-D.ietf-lisp-ddt]
Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP
Delegated Database Tree", draft-ietf-lisp-ddt-00 (work in Delegated Database Tree", draft-ietf-lisp-ddt-01 (work in
progress), October 2012. progress), March 2013.
[I-D.ietf-lisp-sec] [I-D.ietf-lisp-sec]
Maino, F., Ermagan, V., Cabellos-Aparicio, A., Saucez, D., Maino, F., Ermagan, V., Cabellos-Aparicio, A., Saucez, D.,
and O. Bonaventure, "LISP-Security (LISP-SEC)", and O. Bonaventure, "LISP-Security (LISP-SEC)",
draft-ietf-lisp-sec-04 (work in progress), October 2012. draft-ietf-lisp-sec-04 (work in progress), October 2012.
[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),
skipping to change at page 32, line 32 skipping to change at page 32, line 25
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 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", RFC 6480, February 2012. 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", 2013, <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, 2009.
Appendix A. Document Change Log Appendix A. Document Change Log
o Version 05 Posted August 2013.
* Removal of severity levels to become a short recommendation to
reduce the risk of the discussed threat.
o Version 04 Posted February 2013. o Version 04 Posted February 2013.
* Clear statement that the document compares threats of public * Clear statement that the document compares threats of public
LISP deployments with threats in the current Internet LISP deployments with threats in the current Internet
architecture. architecture.
* Addition of a severity level discussion at the end of each * Addition of a severity level discussion at the end of each
section. section.
* Addressed comments from D. Lewis' review. * Addressed comments from V. Ermagan and D. Lewis' reviews.
* Updated References. * Updated References.
* Further editorial polishing. * Further editorial polishing.
o Version 03 Posted October 2012. o Version 03 Posted October 2012.
* Dropped Reference to RFC 2119 notation because it is not * Dropped Reference to RFC 2119 notation because it is not
actually used in the document. actually used in the document.
 End of changes. 46 change blocks. 
119 lines changed or deleted 95 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/