--- 1/draft-ietf-lisp-threats-10.txt 2014-12-30 02:14:53.935930693 -0800 +++ 2/draft-ietf-lisp-threats-11.txt 2014-12-30 02:14:53.975931672 -0800 @@ -1,114 +1,114 @@ Network Working Group D. Saucez Internet-Draft INRIA Intended status: Informational L. Iannone -Expires: January 5, 2015 Telecom ParisTech +Expires: July 3, 2015 Telecom ParisTech O. Bonaventure Universite catholique de Louvain - July 4, 2014 + December 30, 2014 LISP Threats Analysis - draft-ietf-lisp-threats-10.txt + draft-ietf-lisp-threats-11.txt Abstract This document proposes a threat analysis of the Locator/Identifier Separation Protocol (LISP). -Status of this Memo +Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on January 5, 2015. + This Internet-Draft will expire on July 3, 2015. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Threat model . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2.1. Attacker modes of operation . . . . . . . . . . . . . . . 4 - 2.1.1. On-path attackers vs. Off-path attackers . . . . . . . 4 - 2.1.2. Internal attackers vs. External attackers . . . . . . 4 - 2.1.3. Live attackers vs. Time-shifted attackers . . . . . . 4 - 2.1.4. Control-plane attackers vs. Data-plane attackers . . . 5 - 2.1.5. Cross mode attackers . . . . . . . . . . . . . . . . . 5 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Threat model . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2.1. Attacker's Operation Modes . . . . . . . . . . . . . . . 3 + 2.1.1. On-path vs. Off-path Attackers . . . . . . . . . . . 4 + 2.1.2. Internal vs. External Attackers . . . . . . . . . . . 4 + 2.1.3. Live vs. Time-shifted attackers . . . . . . . . . . . 4 + 2.1.4. Control-plane vs. Data-plane attackers . . . . . . . 4 + 2.1.5. Cross mode attackers . . . . . . . . . . . . . . . . 5 2.2. Threat categories . . . . . . . . . . . . . . . . . . . . 5 2.2.1. Replay attack . . . . . . . . . . . . . . . . . . . . 5 2.2.2. Packet manipulation . . . . . . . . . . . . . . . . . 5 - 2.2.3. Packet interception and suppression . . . . . . . . . 6 - 2.2.4. Spoofing . . . . . . . . . . . . . . . . . . . . . . . 6 - 2.2.5. Rogue attack . . . . . . . . . . . . . . . . . . . . . 6 - 2.2.6. Denial of Service (DoS) attack . . . . . . . . . . . . 7 - 2.2.7. Performance attack . . . . . . . . . . . . . . . . . . 7 - 2.2.8. Intrusion attack . . . . . . . . . . . . . . . . . . . 7 - 2.2.9. Amplification attack . . . . . . . . . . . . . . . . . 7 - 2.2.10. Multi-category attacks . . . . . . . . . . . . . . . . 7 - 3. Attack vectors . . . . . . . . . . . . . . . . . . . . . . . . 7 - 3.1. Gleaning . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 2.2.3. Packet interception and suppression . . . . . . . . . 5 + 2.2.4. Spoofing . . . . . . . . . . . . . . . . . . . . . . 5 + 2.2.5. Rogue attack . . . . . . . . . . . . . . . . . . . . 6 + 2.2.6. Denial of Service (DoS) attack . . . . . . . . . . . 6 + 2.2.7. Performance attack . . . . . . . . . . . . . . . . . 7 + 2.2.8. Intrusion attack . . . . . . . . . . . . . . . . . . 7 + 2.2.9. Amplification attack . . . . . . . . . . . . . . . . 7 + 2.2.10. Multi-category attacks . . . . . . . . . . . . . . . 7 + 3. Attack vectors . . . . . . . . . . . . . . . . . . . . . . . 7 + 3.1. Gleaning . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Locator Status Bits . . . . . . . . . . . . . . . . . . . 9 3.3. Map-Version . . . . . . . . . . . . . . . . . . . . . . . 9 - 3.4. Echo-Nonce algorithm . . . . . . . . . . . . . . . . . . . 10 + 3.4. Echo-Nonce . . . . . . . . . . . . . . . . . . . . . . . 10 3.5. Instance ID . . . . . . . . . . . . . . . . . . . . . . . 11 - 3.6. Interworking . . . . . . . . . . . . . . . . . . . . . . . 11 - 3.7. Map-Request messages . . . . . . . . . . . . . . . . . . . 12 - 3.8. Map-Reply messages . . . . . . . . . . . . . . . . . . . . 13 + 3.6. Interworking . . . . . . . . . . . . . . . . . . . . . . 11 + 3.7. Map-Request messages . . . . . . . . . . . . . . . . . . 12 + 3.8. Map-Reply messages . . . . . . . . . . . . . . . . . . . 12 3.9. Map-Register messages . . . . . . . . . . . . . . . . . . 14 3.10. Map-Notify messages . . . . . . . . . . . . . . . . . . . 14 4. Note on Privacy . . . . . . . . . . . . . . . . . . . . . . . 14 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 - 8.1. Normative References . . . . . . . . . . . . . . . . . . . 16 - 8.2. Informative References . . . . . . . . . . . . . . . . . . 16 - Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 17 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 + 8.1. Normative References . . . . . . . . . . . . . . . . . . 16 + 8.2. Informative References . . . . . . . . . . . . . . . . . 16 + Appendix A. Document Change Log . . . . . . . . . . . . . . . . 17 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 1. Introduction The Locator/ID Separation Protocol (LISP) is specified in [RFC6830]. The present document assess the potential security threats identified in the LISP specifications if LISP is deployed in the Internet (i.e., a public non-trustable environment). The document is composed of three main parts: the first defines the general threat model that attackers can follow to mount attacks. The second describing the techniques based on the LISP protocol and architecture that attackers can use to construct attacks. The third - discussing general solutions to protect the LISP protocol and - architecture from attacks. + discussing mitigation techniques and general solutions to protect the + LISP protocol and architecture from attacks. This document does not consider all the possible uses of LISP as discussed in [RFC6830] and [RFC7215]. The document focuses on LISP unicast, including as well LISP Interworking [RFC6832], LISP-MS [RFC6833], and LISP Map-Versioning [RFC6834]. The reading of these documents is a prerequisite for understanding the present document. This document assumes a generic IP service and does not discuss the difference, from a security viewpoint, between using IPv4 or IPv6. @@ -132,78 +132,78 @@ an attack, even though they are not directly targeted by the attack. The target of an attack can be selected specifically, i.e., a particular entity, or arbitrarily, i.e., any entity. Finally, an attacker can aim at attacking one or several targets with a single attack. Section 2.1 specifies the different modes of operation that attackers can follow to mount attacks and Section 2.2 specifies the different categories of attacks that attackers can build. -2.1. Attacker modes of operation +2.1. Attacker's Operation Modes Attackers can be classified according to the following four modes of - operation, i.e., the temporal and spacial locality of the attacker. + operation, i.e., the temporal and spacial diversity of the attacker. -2.1.1. On-path attackers vs. Off-path attackers +2.1.1. On-path vs. Off-path Attackers On-path attackers, also known as Men-in-the-Middle, are able to intercept and modify packets between legitimate communicating entities. On-path attackers are located either directly on the normal communication path (either by gaining access to a node on the path or by placing themselves directly on the path) or outside the - location path but manage to deviate or gain a copy of packets sent + location path but manage to deviate (or gain a copy of) packets sent between the communication entities. On-path attackers hence mount their attacks by modifying packets initially sent legitimately between communication entities. An attacker is called off-path attacker if it does not have access to packets exchanged during the communication or if there is no communication. To succeed their attacks, off-path attackers must hence generate packets and inject them in the network. -2.1.2. Internal attackers vs. External attackers +2.1.2. Internal vs. External Attackers An internal attacker launches its attack from a node located within a legitimate LISP site. Such an attacker is either a legitimate node of the site or it exploits a vulnerability to gain access to a legitimate node in the site. Because of their location, internal attackers are trusted by the site they are in. On the contrary, an external attacker launches its attacks from the outside of a legitimate LISP site. -2.1.3. Live attackers vs. Time-shifted attackers +2.1.3. Live vs. Time-shifted attackers A live attacker mounts attacks for which it must remain connected as long as the attack is mounted. In other words, the attacker must remain active for the whole duration of the attack. Consequently, the attack ends as soon as the attacker (or the used attack vector) is neutralized. On the contrary, a time-shifted attacker mounts attacks that remain active after it disconnects from the Internet. -2.1.4. Control-plane attackers vs. Data-plane attackers +2.1.4. Control-plane vs. Data-plane attackers A control-plane attacker mounts its attack by using control-plane functionalities, typically the mapping system. A data-plane attacker mounts its attack by using data-plane functionalities. - As there is no strict delimitation between the control-plane and the - data-plane, an attacker can operate in the control-plane (resp. data- - plane) to mount attacks targeting the data-plane (resp. control- - plane) or keep the attacked and targeted planes at the same layer - (i.e., from control-plane to control-plane or from data-plane to - data-plane). + As there is no complete isolation between the control-plane and the + data-plane, an attacker can operate in the control-plane (resp. + data-plane) to mount attacks targeting the data-plane (resp. + control-plane) or keep the attacked and targeted planes at the same + layer (i.e., from control-plane to control-plane or from data-plane + to data-plane). 2.1.5. Cross mode attackers The attacker modes of operation are not mutually exclusive and hence attackers can combine them to mount attacks. For example, an attacker can launch an attack using the control-plane directly from within a LISP site to which it got temporary access (i.e., internal + control-plane attacker) to create a vulnerability on its target and later on (i.e., time-shifted + external attacker) @@ -218,22 +218,22 @@ A replay attack happens when an attacker retransmits at a later time, and without modifying it, a packet (or a sequence of packets) that has already been transmitted. 2.2.2. Packet manipulation A packet manipulation attack happens when an attacker receives a packet, modifies the packet (i.e., changes some information contained in the packet) and finally transmits the packet to its final - destination that can be the initial destination of the packet or - another one. + destination that can be the initial destination of the packet or a + different one. 2.2.3. Packet interception and suppression In a packet interception and suppression attack, the attacker captures the packet and drops it before it can reach its final destination. 2.2.4. Spoofing With a spoofing attack, the attacker injects packets in the network @@ -247,35 +247,37 @@ originator of the packet. Hence, since LISP uses encapsulation, the spoofed address could be in the outer header as well as in the inner header, this translates in two types of spoofing. Inner address spoofing: the attacker uses encapsulation and uses a spoofed source address in the inner packet. In case of data- plane LISP encapsulation, that corresponds to spoof the source EID address of the encapsulated packet. Outer address spoofing: the attacker does not use encapsulation and - spoofs the source address of the packet. + spoofs the source address of the packet. In case of data-plane + LISP encapsulation, that corresponds to spoof the source RLOC + address of the encapsulated packet. Note that the two types of spoofing are not mutually exclusive, rather all combinations are possible and could be used to perform - different kind of attacks. For example, an attacker not in a LISP + different kind of attacks. For example, an attacker outside a LISP site can generate a packet with a forged source IP address (i.e., outer address spoofing) and forward it to a LISP destination. The packet is then eventually encapsulated by a PITR so that once encapsulated the attack corresponds to a inner address spoofing. One can also imagine an attacker forging a packet with encapsulation where both inner an outer source addresses are spoofed. It is important to notice that the combination of inner and outer spoofing makes the identification of the attacker complex as the - packet may not contain information that permits to detect the origin + packet may not contain information that allows to detect the origin of the attack. 2.2.5. Rogue attack In a rogue attack the attacker manages to appear as a legitimate source of information, without faking its identity (as opposed to a spoofing attacker). 2.2.6. Denial of Service (DoS) attack @@ -358,38 +359,38 @@ DoS and performance attacks on the control-plane. For example, if an attacker sends a packet for each address of a prefix not yet cached in the EID-to-RLOC cache of an xTR, the xTR will potentially send a Map-Request for each such packet until the mapping is installed which leads to an over-utilisation of the control-plane as each packet generates a control-plane event. For succeeding this example, the attacker may not need to use spoofing. Gleaning attacks are fundamentally involving a time-shifted mode of operation as the attack may last as long as the gleaned entry is kept - by the targeted xTR. Nevertheless, [RFC6830] recommends to store the + by the targeted xTR. RFC 6830 [RFC6830] recommends to store the gleaned entries for only a few seconds which limits the duration of the attack. Gleaning attacks always involve external data-plane attackers but results in attacks on either the control-plane or data-plane. It is worth to notice that the outer spoofed address does not need to be the RLOC of a LISP site an may be any address. 3.2. Locator Status Bits - When the L bit is set to 1, it indicates that the second 32-bits - longword of the LISP header contains the Locator Status Bits. In - this field, each bit position reflects the status of one of the RLOCs - mapped to the source EID found in the encapsulated packet. The - reaction of a LISP xTR that receives such a packet is left as - operational choice in [RFC6830]. + When the L bit in the LISP header is set to 1, it indicates that the + second 32-bits longword of the LISP header contains the Locator + Status Bits. In this field, each bit position reflects the status of + one of the RLOCs mapped to the source EID found in the encapsulated + packet. The reaction of a LISP xTR that receives such a packet is + left as operational choice in [RFC6830]. When an attacker sends a LISP encapsulated packet with a crafted LSB to an xTR, it can influence the xTR's choice of the locators for the prefix associated to the source EID. In case of an off-path attacker, the attacker must inject a forged packet in the network with a spoofed inner address. An on-path attacker can manipulate the LSB of legitimate packets passing through it and hence does not need to use spoofing. Instead of manipulating the LSB field, an on-path attacker can also obtain the same result of injecting packets with invalid LSB values by replaying packets. @@ -407,25 +408,25 @@ one of the RLOCs specified in the mapping, forcing packets to go via that RLOC implies that the attacker will gain access to the packets. Attacks using the LSB are fundamentally involving a time-shifted mode of operation as the attack may last as long as the reachability information gathered from the LSB is used by the xTR to decide the RLOCs to be used. 3.3. Map-Version - When the Map-Version bit is set to 1, it indicates that the low-order - 24 bits of the first 32 bits longword of the LISP header contain a - Source and Destination Map-Version. When a LISP xTR receives a LISP - encapsulated packet with the Map-Version bit set to 1, the following - actions are taken: + When the Map-Version bit of the LISP header is set to 1, it indicates + that the low-order 24 bits of the first 32 bits longword of the LISP + header contain a Source and Destination Map-Version. When a LISP xTR + receives a LISP encapsulated packet with the Map-Version bit set to + 1, the following actions are taken: o It compares the Destination Map-Version found in the header with the current version of its own configured EID-to-RLOC mapping, for the destination EID found in the encapsulated packet. If the received Destination Map-Version is smaller (i.e., older) than the current version, the ETR should apply the SMR procedure described in [RFC6830] and send a Map-Request with the SMR bit set. o If a mapping exists in the EID-to-RLOC Cache for the source EID, then it compares the Map-Version of that entry with the Source @@ -443,30 +444,30 @@ control-plane packets sent in response to the attacker's packet. With a spoofing attack and if the xTR considers that the spoofed ITR has an outdated mapping, it will send an SMR to the spoofed ITR which can result in performance, amplification, or DoS attack as well. Map-Version attackers are inherently cross mode as the Map-Version is a method to put control information in the data-plane. Moreover, this vector involves live attackers. Nevertheless, on-path attackers do not take specific advantage over off-path attackers. -3.4. Echo-Nonce algorithm +3.4. Echo-Nonce - The Nonce-Present and Echo-Nonce bits are used to verifying the - reachability of an xTR. An testing xTR sets the Echo-Nonce and the - Nonce-Present bits in LISP data encapsulated packets and include a - random nonce in the LISP header of packets. Upon reception of these - packets, the tested xTR stores the nonce and echo it whenever it - returns a LISP encapsulated data packets to the testing xTR. The - reception of the echoed nonce confirms that the tested xTR is - reachable. + The Nonce-Present and Echo-Nonce bits in the LISP header are used to + verify the reachability of an xTR. A testing xTR sets the Echo-Nonce + and the Nonce-Present bits in LISP data encapsulated packets and + include a random nonce in the LISP header of packets. Upon reception + of these packets, the tested xTR stores the nonce and echo it + whenever it returns a LISP encapsulated data packets to the testing + xTR. The reception of the echoed nonce confirms that the tested xTR + is reachable. An attacker can interfere with the reachability test by sending two different types of packets: 1. LISP data encapsulated packets with the Nonce-Present bit set and a random nonce. Such packets are normally used in response to a reachability test. 2. LISP data encapsulated packets with the Nonce-Present and the Echo-Nonce bits both set. These packets will force the receiving @@ -525,41 +526,41 @@ Request messages at high rate, the attacker can overload nodes involved in the mapping system. For instance sending Map-Requests at high rate can considerably increase the state maintained in a Map- Resolver or consume CPU cycles on ETRs that have to process the Map- Request packets they receive in their slow path (i.e., performance or DoS attack). When the Map-Reply packet is larger than the Map- Request sent by the attacker, that yields to an amplification attack. The attacker can combine the attack with a spoofing attack to overload the node to which the spoofed address is actually attached. - It is worth to notice that if the attacker sets the P bit in the Map- - Request, it is legitimate the send the Map-Request directly to the - ETR instead of passing through the mapping system. + It is worth to notice that if the attacker sets the P bit (Probe Bit) + in the Map-Request, it is legitimate the send the Map-Request + directly to the ETR instead of passing through the mapping system. The SMR bit can be used to mount a variant of these attacks. For efficiency reasons, Map-Records can be appended to Map-Request messages. When an xTR receives a Map-Request with appended Map- Records, it does the same operations as for the other Map-Request messages and is so subject to the same attacks. However, it also installs in its EID-to-RLOC cache the Map-Records contained in the Map-Request. An attacker can then use this vector to force the installation of mappings in its target xTR. Consequently, the EID- to-RLOC cache of the xTR is polluted by potentially forged mappings allowing the attacker to mount any of the attacks categorized in Section 2.2 (see Section 3.8 for more details). It is worth to mention that the attacker does not need to forge the mappings present in the Map-Request to succeed a performance or DoS attack. Indeed, if the attacker owns a large enough EID prefix it can de-aggregate it in many small prefixes, each corresponding to another mapping and it - them in the xTR cache by the mean of the Map-Request. + installs them in the xTR cache by mean of the Map-Request. Moreover, attackers can use Map Resolver and/or Map Server network elements to relay its attacks and hide the origin of the attack. Indeed, on the one hand, a Map Resolver is used to dispatch Map- Request to the mapping system and, on the other hand, a Map Server is used to dispatch Map-Requests coming from the mapping system to ETRs that are authoritative for the EID in the Map-Request. 3.8. Map-Reply messages @@ -573,74 +574,74 @@ If an attacker manages to send a valid (i.e., in response to a Map- Request and with the correct nonce) Map-Reply to an ITR, then it can perform any of the attack categorised in Section 2.2 as it can inject forged mappings directly in the ITR EID-to-RLOC cache. For instance, if the mapping injected to the ITR points to the address of a node controlled by the attacker, it can mount replay, packet manipulation, packet interception and suppression, or DoS attacks as it will receive every packet destined to a destination lying in the EID prefix of the injected mapping. In addition, the attacker can inject - plethora of mappings in the ITR to mount an performance attack by + plethora of mappings in the ITR to mount a performance attack by filling up the EID-to-RLOC cache of the ITR. If the attacker can also mount an amplification attack as soon as the ITR has to send a lot of packets to the EIDs matching the injected mapping. In this case, the RLOC address associated to the mapping is the address of the real target of the attacker and all the traffic of the ITR will be sent to the target which means that with one single packet the attacker may generate very high traffic towards its final target. If the attacker is a valid ETR in the system it can mount a rogue attack if it uses prefixes over-claiming. In such a scenario, the attacker ETR replies to a legitimate Map-Request message it received with a Map-Reply message that contains an EID-Prefix that is larger than the prefix owned by the attacker. For instance if the owned prefix is 192.0.2.0/25 but the Map-Reply contains a mapping for 192.0.2.0/24, then the mapping will influence packets destined to other EIDs than the one attacker has authority on. With such technique, the attacker can mount the attacks presented above as it can (partially) control the mappings installed on its target ITR. To force its target ITR to send a Map-Request, nothing prevents the - attacker to initiate some communication with the ITR. This method is - particularly interesting for internal attackers that want to control - the mappings installed in their site. To that aim, they simply have - to collude with an external attacker ready to over-claim prefixes on - behalf of the internal attacker. + attacker to initiate some communication with the ITR. This method + can be used by internal attackers that want to control the mappings + installed in their site. To that aim, they simply have to collude + with an external attacker ready to over-claim prefixes on behalf of + the internal attacker. It is worth to notice that when the Map-Reply is in response to a Map-Request sent via the mapping system (i.e., not send directly from the ITR to an ETR), the attacker does not need to use a spoofing attack to succeed its attack as by design the source IP address of a Map-Reply is not known in advance by the ITR. - Map-Request and Map-Reply messages are at the mercy of any type of + Map-Request and Map-Reply messages are exposed to any type of attackers, on-path or off-path but also external or internal attackers. Also, even though they are control message, they can be leveraged by data-plane attackers. As the decision of removing mappings is based on the TTL indicated in the mapping, time-shifted attackers can take benefit of injecting forged mappings as well. 3.9. Map-Register messages - Map-Register messages are sent by ETRs to indicate to the mapping - system the EID prefixes associated to them. The Map-Register message - provides an EID prefix and the list of ETRs that are able to provide - Map-Replies for the EID covered by the EID prefix. + Map-Register messages are sent by ETRs to Map Servers to indicate to + the mapping system the EID prefixes associated to them. The Map- + Register message provides an EID prefix and the list of ETRs that are + able to provide Map-Replies for the EID covered by the EID prefix. As Map-Register messages are protected by an authentication mechanism, only a compromised ETR can register itself to its allocated Map Server. A compromised ETR can over-claim the prefix it owns in order to influence the route followed by Map-Requests for EIDs outside the scope of its legitimate EID prefix (see Section 3.8 for the list of - attacks opened by over-claiming). + over-claiming attacks). A compromised ETR can also de-aggregate its EID prefix in order to register more EID prefixes than necessary to its Map Servers (see Section 3.7 for the impact of de-aggregation of prefixes by an attacker). Similarly, a compromised Map Server can accept invalid registration or advertise invalid EID prefix to the mapping system. 3.10. Map-Notify messages @@ -701,85 +702,88 @@ The authors would like to thank Ronald Bonica, Albert Cabellos, Ross Callon, Noel Chiappa, Florin Coras, Vina Ermagan, Dino Farinacci, Stephen Farrell, Joel Halpern, Emily Hiltzik, Darrel Lewis, Edward Lopez, Fabio Maino, Terry Manderson, and Jeff Wheeler for their comments. This work has been partially supported by the INFSO-ICT-216372 TRILOGY Project (www.trilogy-project.org). - The work of Luigi Iannone has been partially supported by the ANR-13- - INFR-0009 LISP-Lab Project (www.lisp-lab.org) and the EIT KIC ICT- + The work of Luigi Iannone has been partially supported by the ANR- + 13-INFR-0009 LISP-Lab Project (www.lisp-lab.org) and the EIT KIC ICT- Labs SOFNETS Project. 8. References 8.1. Normative References [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The - Locator/ID Separation Protocol (LISP)", RFC 6830, - January 2013. + Locator/ID Separation Protocol (LISP)", RFC 6830, January + 2013. [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, "Interworking between Locator/ID Separation Protocol (LISP) and Non-LISP Sites", RFC 6832, January 2013. [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation - Protocol (LISP) Map-Server Interface", RFC 6833, - January 2013. + Protocol (LISP) Map-Server Interface", RFC 6833, January + 2013. [RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID Separation Protocol (LISP) Map-Versioning", RFC 6834, January 2013. [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy - Considerations for Internet Protocols", RFC 6973, - July 2013. + Considerations for Internet Protocols", RFC 6973, July + 2013. 8.2. Informative References [I-D.bagnulo-lisp-threat] - Bagnulo, M., "Preliminary LISP Threat Analysis", - draft-bagnulo-lisp-threat-01 (work in progress), - July 2007. + Bagnulo, M., "Preliminary LISP Threat Analysis", draft- + bagnulo-lisp-threat-01 (work in progress), July 2007. [I-D.ietf-lisp-ddt] Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP - Delegated Database Tree", draft-ietf-lisp-ddt-01 (work in - progress), March 2013. + Delegated Database Tree", draft-ietf-lisp-ddt-02 (work in + progress), October 2014. [I-D.ietf-lisp-sec] Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. - Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-06 - (work in progress), April 2014. + Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-07 + (work in progress), October 2014. [RFC7215] Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo- Pascual, J., and D. Lewis, "Locator/Identifier Separation Protocol (LISP) Network Element Deployment Considerations", RFC 7215, April 2014. [Saucez13] Saucez, D., Iannone, L., and O. Bonaventure, "The Map-and- Encap Locator/Identifier separation paradigm: a Security Analysis", Solutions for Sustaining Scalability in Internet Growth, IGI Global, 2013. Appendix A. Document Change Log + o Version 11 Posted December 2014. + + * Editorial polishing. Clarifications added in few points. + o Version 10 Posted July 2014. * Document completely remodeled according to the discussions on - the mailing list in the thread - http://www.ietf.org/mail-archive/web/lisp/current/msg05206.html - and to address comments from Ronald Bonica and Ross Callon. + the mailing list in the thread http://www.ietf.org/mail- + archive/web/lisp/current/msg05206.html and to address comments + from Ronald Bonica and Ross Callon. o Version 09 Posted March 2014. * Updated document according to the review of A. Cabellos. o Version 08 Posted October 2013. * Addition of a privacy consideration note. * Editorial changes