draft-ietf-lisp-threats-01.txt   draft-ietf-lisp-threats-02.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: September 2, 2012 Telekom Innovation Laboratories Expires: March 16, 2013 Telecom ParisTech
O. Bonaventure O. Bonaventure
Universite catholique de Louvain Universite catholique de Louvain
March 1, 2012 September 12, 2012
LISP Threats Analysis LISP Threats Analysis
draft-ietf-lisp-threats-01.txt draft-ietf-lisp-threats-02.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 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
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 September 2, 2012. This Internet-Draft will expire on March 16, 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
skipping to change at page 2, line 46 skipping to change at page 2, line 46
11.2. Map-Resolver . . . . . . . . . . . . . . . . . . . . . . . 24 11.2. Map-Resolver . . . . . . . . . . . . . . . . . . . . . . . 24
12. Suggested Recommendations . . . . . . . . . . . . . . . . . . 25 12. Suggested Recommendations . . . . . . . . . . . . . . . . . . 25
13. Document Status and Plans . . . . . . . . . . . . . . . . . . 27 13. Document Status and Plans . . . . . . . . . . . . . . . . . . 27
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
15. Security Considerations . . . . . . . . . . . . . . . . . . . 28 15. Security Considerations . . . . . . . . . . . . . . . . . . . 28
16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
17.1. Normative References . . . . . . . . . . . . . . . . . . . 28 17.1. Normative References . . . . . . . . . . . . . . . . . . . 28
17.2. Informative References . . . . . . . . . . . . . . . . . . 29 17.2. Informative References . . . . . . . . . . . . . . . . . . 29
Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 30 Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31
1. Requirements notation 1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Introduction 2. Introduction
The Locator/ID Separation Protocol (LISP) is defined in The Locator/ID Separation Protocol (LISP) is defined in
skipping to change at page 13, line 15 skipping to change at page 13, line 15
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 6.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 6.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 AFI has been used ID" and used on the ITR to indicate which private Instance ID has
for encapsulation, while on the ETR can be used to select the been used for encapsulation, while on the ETR can be used to select
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 7. Control Plane Threats
skipping to change at page 14, line 17 skipping to change at page 14, line 17
Considering only IPv6 addresses, a Map-Request can be as small as 40 Considering only IPv6 addresses, a Map-Request can be as small as 40
bytes, considering one single ITR address and no Mapping Protocol bytes, considering one single ITR address and no Mapping Protocol
Data. The Map-Reply instead has a size of O(12 + (R * (28 + N * Data. The Map-Reply instead has a size of O(12 + (R * (28 + N *
24))) bytes, where N is the maximum number of RLOCs in a mapping and 24))) bytes, where N is the maximum number of RLOCs in a mapping and
R the maximum number of records in a Map-Reply. Since up to 255 R the maximum number of records in a Map-Reply. Since up to 255
RLOCs can be associated to an EID-Prefix and 255 records can be RLOCs can be associated to an EID-Prefix and 255 records can be
stored in a Map-Reply, the maximum size of a Map-Reply is thus above stored in a Map-Reply, the maximum size of a Map-Reply is thus above
1 MB showing a size factor of up to 39,193 between the message sent 1 MB showing a size factor of up to 39,193 between the message sent
by the attacker and the message sent by the ETR. These numbers are by the attacker and the message sent by the ETR. These numbers are
however theoretical values not considering transport layer however theoretical values not considering transport layer
limitations and it is more likely that the reply will contain only on limitations and it is more likely that the reply will contain only
record with at most a dozen of locators, giving an amplification one record with at most a dozen of locators, giving an amplification
factor around 8. factor around 8.
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
skipping to change at page 16, line 5 skipping to change at page 15, line 50
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
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 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 a 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 cache, the a source RLOC. Once a gleaned entry has been added to the EID-to-
LISP ITR sends a Map-Request to retrieve the mapping for the gleaned RLOC cache, the LISP ITR sends a Map-Request to retrieve the mapping
EID from the mapping system. [I-D.ietf-lisp] recommends to store the for the gleaned EID from the mapping system. [I-D.ietf-lisp]
gleaned entries for only a few seconds. recommends to store 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
skipping to change at page 17, line 31 skipping to change at page 17, line 41
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.
The Proxy-ITR has functionalities similar to the ITR, however, its The Proxy-ITR has functionalities similar to the ITR, however, its
main purpose is to encapsulate packets arriving from the DFZ in order main purpose is to encapsulate packets arriving from the DFZ in order
to reach LISP sites. This means that it is no bound to any to reach LISP sites. This means that it is no bound to any
particular EID-Prefix, hence no mapping exists and no mapping can be particular EID-Prefix, hence no mapping exists and no mapping can be
configured in the EID-to-RLOC Database. This means that the Proxy- configured in the EID-to-RLOC Database. This means that the Proxy-
ITR element itself is not able, to check whether or not the arriving ITR element itself is not able to check whether or not the arriving
traffic has the right to be encapsulated or not. To limit such an traffic has the right to be encapsulated or not. To limit such an
issue it is recommended to use the current practice based on issue it is recommended to use the current practice based on
firewalls and ACLs on the machine running the Proxy-ITR service. On firewalls and ACLs on the machine running the Proxy-ITR service. On
the other side, the Proxy-ITR is meant to encapsulate only packets the other side, the Proxy-ITR is meant to encapsulate only packets
that are destined to one of the LISP sites it is serving. This is that are destined to one of the LISP sites it is serving. This is
the case for instance for a service provider selling Proxy-ITR the case for instance for a service provider selling Proxy-ITR
services. For this purpose a static EID-to-RLOC Cache can be services. For this purpose a static EID-to-RLOC Cache can be
configured in order to encapsulate only valid packets. In case of a configured in order to encapsulate only valid packets. In case of a
cache-miss no Map-Request needs to be sent and the packet can be cache-miss no Map-Request needs to be sent and the packet can be
silently dropped. silently dropped.
skipping to change at page 28, line 27 skipping to change at page 28, line 27
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 17. References
17.1. Normative References 17.1. Normative References
[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-22 (work in progress), February 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.
[I-D.ietf-lisp-interworking] [I-D.ietf-lisp-interworking]
Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
"Interworking LISP with IPv4 and IPv6", "Interworking LISP with IPv4 and IPv6",
draft-ietf-lisp-interworking-05 (work in progress), draft-ietf-lisp-interworking-06 (work in progress),
February 2012. March 2012.
[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-08 (work in Versioning", draft-ietf-lisp-map-versioning-09 (work in
progress), February 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-15 (work in progress), January 2012. draft-ietf-lisp-ms-16 (work in progress), March 2012.
[I-D.ietf-lisp-multicast] [I-D.ietf-lisp-multicast]
Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas,
"LISP for Multicast Environments", "LISP for Multicast Environments",
draft-ietf-lisp-multicast-14 (work in progress), draft-ietf-lisp-multicast-14 (work in progress),
February 2012. February 2012.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
skipping to change at page 29, line 33 skipping to change at page 29, line 33
Lewis, D., Farinacci, D., and V. Fuller, "LISP Delegated Lewis, D., Farinacci, D., and V. Fuller, "LISP Delegated
Database Tree", draft-fuller-lisp-ddt-00 (work in Database Tree", draft-fuller-lisp-ddt-00 (work in
progress), November 2011. progress), November 2011.
[I-D.ietf-sidr-arch] [I-D.ietf-sidr-arch]
Lepinski, M. and S. Kent, "An Infrastructure to Support Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", draft-ietf-sidr-arch-13 (work in Secure Internet Routing", draft-ietf-sidr-arch-13 (work in
progress), May 2011. progress), May 2011.
[I-D.ietf-tcpm-tcp-security] [I-D.ietf-tcpm-tcp-security]
Gont, F., "Security Assessment of the Transmission Control Gont, F., "Survey of Security Hardening Methods for
Protocol (TCP)", draft-ietf-tcpm-tcp-security-02 (work in Transmission Control Protocol (TCP) Implementations",
progress), January 2011. draft-ietf-tcpm-tcp-security-03 (work in progress),
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-08 (work in progress), March 2010. draft-lear-lisp-nerd-09 (work in progress), April 2012.
[I-D.maino-lisp-sec] [I-D.maino-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-maino-lisp-sec-00 (work in progress), March 2011. 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.
skipping to change at page 30, line 28 skipping to change at page 30, line 30
[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 02 Posted September 2012.
* Added a new attack that combines overclaiming and de-
aggregation (see Section 7.2).
* 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 10.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 11.
* Added discussion on Instance ID in Section 6.4. * Added discussion on Instance ID in Section 6.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
INRIA INRIA
2004 route des Luciolles BP 93 2004 route des Lucioles BP 93
06902 Sophia Antipolis Cedex 06902 Sophia Antipolis Cedex
France France
Email: damien.saucez@inria.fr Email: damien.saucez@inria.fr
Luigi Iannone Luigi Iannone
Telekom Innovation Laboratories Telecom ParisTech
Ernst-Reuter Platz 7 23, Avenue d'Italie, CS 51327
Berlin 75214 PARIS Cedex 13
Germany France
Email: luigi@net.t-labs.tu-berlin.de Email: luigi.iannone@telecom-paristech.fr
Olivier Bonaventure Olivier Bonaventure
Universite catholique de Louvain Universite catholique de Louvain
Place St. Barbe 2 Place St. Barbe 2
Louvain la Neuve Louvain la Neuve
Belgium Belgium
Email: olivier.bonaventure@uclouvain.be Email: olivier.bonaventure@uclouvain.be
 End of changes. 21 change blocks. 
32 lines changed or deleted 52 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/