diff options
Diffstat (limited to 'doc/rfc/rfc7834.txt')
| -rw-r--r-- | doc/rfc/rfc7834.txt | 1011 |
1 files changed, 1011 insertions, 0 deletions
diff --git a/doc/rfc/rfc7834.txt b/doc/rfc/rfc7834.txt new file mode 100644 index 0000000..606ca27 --- /dev/null +++ b/doc/rfc/rfc7834.txt @@ -0,0 +1,1011 @@ + + + + + + +Internet Engineering Task Force (IETF) D. Saucez +Request for Comments: 7834 INRIA +Category: Informational L. Iannone +ISSN: 2070-1721 Telecom ParisTech + A. Cabellos + F. Coras + Technical University of Catalonia + April 2016 + + + Locator/ID Separation Protocol (LISP) Impact + +Abstract + + The Locator/ID Separation Protocol (LISP) aims to improve the + Internet routing scalability properties by leveraging three + principles: address role separation, encapsulation, and mapping. In + this document, based on implementation work, deployment experiences, + and theoretical studies, we discuss the impact that the deployment of + LISP can have on both the routing infrastructure and the end user. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7834. + + + + + + + + + + + + + + + +Saucez, et al. Informational [Page 1] + +RFC 7834 LISP Impact April 2016 + + +Copyright Notice + + Copyright (c) 2016 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. LISP in a Nutshell . . . . . . . . . . . . . . . . . . . . . 4 + 3. LISP for Scaling the Internet Routing Architecture . . . . . 5 + 4. Beyond Scaling the Internet Routing Architecture . . . . . . 6 + 4.1. Traffic Engineering . . . . . . . . . . . . . . . . . . . 8 + 4.2. LISP for IPv6 Co-existence . . . . . . . . . . . . . . . 8 + 4.3. Inter-domain Multicast . . . . . . . . . . . . . . . . . 9 + 5. Impact of LISP on Operations and Business Models . . . . . . 10 + 5.1. Impact on Non-LISP Traffic and Sites . . . . . . . . . . 10 + 5.2. Impact on LISP Traffic and Sites . . . . . . . . . . . . 11 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 7.1. Normative References . . . . . . . . . . . . . . . . . . 13 + 7.2. Informative References . . . . . . . . . . . . . . . . . 14 + Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 + + + + + + + + + + + + + + + + + + +Saucez, et al. Informational [Page 2] + +RFC 7834 LISP Impact April 2016 + + +1. Introduction + + The Locator/ID Separation Protocol (LISP) relies on three principles + to improve the scalability properties of Internet routing: address + role separation, encapsulation, and mapping. When invented, LISP was + targeted at solving the Internet routing scaling problem [RFC4984]. + There have now been years of implementations and experiments + examining the impact and open questions of using LISP to improve + inter-domain routing scalability. Experience has shown that because + LISP utilizes mapping and encapsulation technologies, it can be + deployed and used for purposes that go beyond routing scalability. + For example, LISP provides a mean for a LISP site to precisely + control its inter-domain outgoing and incoming traffic, with the + possibility to apply different policies to different domains + exchanging traffic with it. LISP can also be used to ease the + transition from IPv4 to IPv6 as it allows the transport of IPv4 over + IPv6 or IPv6 over IPv4. Furthermore, LISP also supports inter-domain + multicast. + + Leveraging implementation and deployment experience, as well as + research work, this document describes, at a high level, the impacts + and open questions still seen in LISP. This information is + particularly useful for considering future approaches and to support + further experimentation to clarify some large open questions (e.g., + around the operations). LISP utilizes a tunnel-based data plane and + a distributed control plane. LISP requires some new functionalities, + such as reachability mechanisms. Because LISP is more than a simple + encapsulation technology and is a new technology, until even more + deployment experience is gained, some open questions related to LISP + deployment and operations remain. As an encapsulation technology, + there may be concerns on reduced Maximum Transmission Unit (MTU) size + in some deployments. An important impact of LISP is on network + operations related to resiliency and troubleshooting. As LISP relies + on cached mappings and on encapsulation, resiliency during failures + and troubleshooting may be more difficult. Also, the use of + encapsulation may make failure detection and recovery slower, and it + will require more coordination than with a single, non-encapsulated, + routing domain solution. + + + + + + + + + + + + + +Saucez, et al. Informational [Page 3] + +RFC 7834 LISP Impact April 2016 + + +2. LISP in a Nutshell + + LISP relies on three principles: address role separation, + encapsulation, and mapping. + + The address space is divided into two sets that have different + semantic meanings: the Routing Locators (RLOCs) and the Endpoint + Identifiers (EIDs). RLOCs are addresses typically assigned from the + Provider Aggregatable (PA) address space. The EIDs are attributed to + the nodes in the edge networks, by a block of contiguous addresses, + which are typically Provider Independent (PI). To limit the + scalability problem, LISP only requires the PA routes towards the + RLOCs to be announced in the provider infrastructure. Whereas for + non-LISP deployments, the EIDs need to be propagated as well. + + LISP routers are used at the boundary between the EID and the RLOC + spaces. Routers used to exit the EID space (towards the provider + domain) are called Ingress Tunnel Routers (ITRs), and those used to + enter the EID space (from the provider domain) are called the Egress + Tunnel Routers (ETRs). When a host sends a packet to a remote + destination, it sends it as in the non-LISP Internet. The packet + arrives at the border of its site at an ITR. Because EIDs are not + routable on the Internet, the packet is encapsulated with the source + address set to the ITR RLOC and the destination address set to the + ETR RLOC. The encapsulated packet is then forwarded in the provider + domain until it reaches the selected ETR. The ETR de-encapsulates + the packet and forwards it to its final destination. The acronym xTR + stands for Ingress/Egress Tunnel Router and is used for a router + playing these two roles. + + The correspondence between EIDs and RLOCs is given by the mappings. + When an ITR needs to find ETR RLOCs that serve an EID, it queries a + mapping system. With the LISP Canonical Address Format (LCAF) + [LISP-LCAF], LISP is not restricted to the Internet protocol for the + EID addresses. With LCAF, any address type can be used as EID (the + address is only the key for the mapping lookup). LISP can transport, + for example, Ethernet frames over the Internet. + + An introduction to LISP can be found in [RFC7215]. The LISP + specifications are given in [RFC6830], [RFC6833], [LISP-DDT], + [RFC6836], [RFC6832], and [RFC6834]. + + + + + + + + + + +Saucez, et al. Informational [Page 4] + +RFC 7834 LISP Impact April 2016 + + +3. LISP for Scaling the Internet Routing Architecture + + The original goal of LISP was to improve the scalability properties + of the Internet routing architecture. LISP utilizes traffic + engineering and stub Autonomous System (AS) prefixes (not announced + anymore in the Default-Free Zone (DFZ)), so that routing tables are + smaller and more stable (i.e., they experience less churn). + Furthermore, at the edge of the network, information necessary to + forward packets (i.e., the mappings) is obtained on demand using a + pull model (whereas the current Internet BGP model uses a push + model). Therefore, the scalability of edge networks is less + dependent on the Internet's size and more related to its traffic + matrix. This scaling improvement has been proven by several studies + (see below). The research studies cited hereafter are based on the + following assumptions: + + o EID-to-RLOC mappings follow the same prefix size as the current + BGP routing infrastructure (current PI addresses only); + + o EIDs are used only at the stub ASes, not in the transit ASes; and + + o the RLOCs of an EID prefix are deployed at the edge between the + stubs owning the EID prefix and the providers, allocating the + RLOCs in a PA mode. + + The above assumptions are inline with [RFC7215] and current LISP + deployments. It is recognized these assumptions may change in the + longer term. [KIF13] and [CDLC] explore different EID prefix space + sizes and still show results that are consistent and equivalent to + the above assumptions. + + Quoitin et al. [QIdLB07] show that the separation between locator and + identifier roles at the network level improves the routing + scalability by reducing the Routing Information Base (RIB) size (up + to one order of magnitude) and increases path diversity and thus the + traffic engineering capabilities. [IB07] and [KIF13] show, based on + real Internet traffic traces, that the number of mapping entries that + must be handled by an ITR of a network with up to 20,000 users is + limited to few tens of thousands; the signaling traffic (i.e., + Map-Request/Map-Reply packets) is in the same order of magnitude + similar to DNS request/reply traffic; and the encapsulation overhead, + while not negligible, is very limited (in the order of few percentage + points of the total traffic volume). + + Previous studies consider the case of a timer-based cache eviction + policy (i.e., mappings are deleted from the cache upon timeout), + while [CDLC] has a more general approach based on the Least Recently + Used (LRU) eviction policy, proposing an analytic model for the EID- + + + +Saucez, et al. Informational [Page 5] + +RFC 7834 LISP Impact April 2016 + + + to-RLOC cache size when prefix-level traffic has a stationary + generating process. The model shows that miss rate can be accurately + predicted from the EID-to-RLOC cache size and a small set of easily + measurable traffic parameters. The model was validated using four + one-day-long packet traces collected at egress points of a campus + network and an academic exchange point considering EID prefixes as + being of the same size as BGP prefixes. Consequently, operators can + provision the EID-to-RLOC cache of their ITRs according to the miss + rate they want to achieve for their given traffic. + + Results in [CDLC] indicate that for a given target miss ratio, the + size of the cache depends only on the parameters of the popularity + distribution; the size of the cache is independent of the number of + users (the size of the LISP site) and the number of destinations (the + size of the EID prefix space). Assuming that the popularity + distribution remains constant, this means that as the number of users + and the number of destinations grow, the cache size needed to obtain + a given miss rate remains constant O(1). + + LISP usually populates its EID-to-RLOC cache in a pull mode, which + means that mappings are retrieved on demand by the ITR. The main + advantage of this mode is that the EID-to-RLOC cache size only + depends on the traffic characteristics at the ITR and is independent + of the size of the provider domain. This benefit comes at the cost + of some delay to transmit the packets that do not hit an entry in the + cache (for which a mapping has to be learned). This delay is bound + by the time necessary to retrieve the mapping from the mapping + system. Moreover, similarly to a push model (e.g., BGP), the pull + model induces signaling messages that correspond to the retrieval of + mappings upon cache miss. The difference being that the signaling + load only depends on the traffic at the ITR and is not triggered by + external events such as in BGP. [CDLC] shows that the miss rate is a + function of the EID-to-RLOC cache size and traffic generation + process, and [CDLC], [SDIB08], and [SDIB08] show from traffic traces + that, in practice, the cache miss rate, and thus the signaling rate, + remain low. + +4. Beyond Scaling the Internet Routing Architecture + + LISP is more than just a scalability solution; it is also a tool to + provide both incoming and outgoing traffic engineering [S11] + [LISP-TE], it can be used as an IPv6 transition at the routing level, + and it can be used for inter-domain multicast [RFC6831] [LISP-RE]. + Also, LISP has been identified for use to support devices' Internet + mobility [LISP-MN] and to support virtual machines' mobility in data + centers and multi-tenant VPNs. These last two uses are not discussed + further as they are out of the scope of the current LISP Working + Group charter. + + + +Saucez, et al. Informational [Page 6] + +RFC 7834 LISP Impact April 2016 + + + A key advantage of the LISP architecture is that it facilitates + routing in environments where there is little to no correlation + between network endpoints and topological location. In service- + provider environments, this application is needed in a range of + consumer use cases that require an inline anchor to deliver a service + to subscribers. Inline anchors provide one of three types of + capabilities: + + o enable mobility of subscriber endpoints + + o enable chaining of middlebox functions and services + + o enable functions to be scaled out seamlessly + + Without LISP, the approach commonly used by operators is to aggregate + service anchors in custom-built boxes. This limits deployments as + endpoints can only move on the same mobile gateway, functions can be + chained only if traffic traverses the same wire or the same Deep + Packet Inspection (DPI) box, and capacity can be scaled out only if + traffic fans out to/from a specific load balancer. + + With LISP, service providers are able to distribute, virtualize, and + instantiate subscriber-service anchors anywhere in the network. + Typical use cases for virtualized inline anchors and network + functions include Distributed Mobility and Virtualized Evolved Packet + Core (vEPC), Virtualized Customer Premise Equipment (vCPE), where + functionality previously anchored at a customer premise is now + dynamically allocated in the network, Virtualized SGi LAN, Virtual IP + Multimedia Subsystems (IMSs), Virtual Session Border Controller + (SBC), etc. + + ConteXtream [ConteXtream] has been deploying map-assisted overlay + networks since 2006, first with a proprietary solution, then evolving + to standard LISP. The solution has been deployed in production in + three tier-1 operators spanning hundreds of millions of subscribers. + Map-assisted overlays had been primarily used to map subscriber flows + to services resources dynamically based on profiles and conditions. + Specifically, it has been used to map mobile subscribers to value- + added/optimization services, broadband subscribers to telephony + services, and fixed-mobile subscribers to Broadband Network Gateway + (BNG) functions and Internet access services. The LISP map-assisted + overlay architecture is used to optimally resolve subscriber to + services, functions, instances, and IP overlay aggregation locations + on a per-flow basis and just in time. + + + + + + + +Saucez, et al. Informational [Page 7] + +RFC 7834 LISP Impact April 2016 + + +4.1. Traffic Engineering + + In the current (non-LISP) routing infrastructure, addresses used by + stub networks are globally routable, and the routing system + distributes the routes to reach these stubs. With LISP, the EID + prefixes of a LISP site are not routable in the DFZ; mappings are + needed in order to determine the list of LISP routers to contact to + forward packets. This difference is significant for two reasons. + First, packets are not forwarded to a site but to a specific router. + Second, a site can control the entry points for its traffic by + controlling its mappings. + + For traffic engineering purposes, a mapping associates an EID prefix + to a list of RLOCs. Each RLOC is annotated with a priority and a + weight. When there are several RLOCs, the ITR selects the one with + the highest priority and sends the encapsulated packet to this RLOC. + If several RLOCs with the highest priority exist, then the traffic is + balanced proportionally to their weight among such RLOCs. Traffic + engineering in LISP thus allows the mapping owner to have a fine- + grained control on the primary and backup path for its incoming and + outgoing packet use. In addition, it can share the load among its + links. An example of the use of such a feature is described by + Saucez et al. [SDIB08], which shows how to use LISP to direct + different types of traffic on different links having different + capacity. + + Traffic engineering in LISP goes one step further, as every Map- + Request contains the source EID address of the packet that caused a + cache miss and triggered the Map-Request. It is thus possible for a + mapping owner to differentiate the answer (Map-Reply) it gives to + Map-Requests based on the requester. This functionality is not + available today with BGP because a domain cannot control exactly the + routes that will be received by domains that are not in the direct + neighborhood. + +4.2. LISP for IPv6 Co-existence + + The LISP encapsulation mechanism is designed to support any + combination of address families for locators and identifiers. It is + then possible to bind IPv6 EIDs with IPv4 RLOCs and vice versa. This + allows transporting IPv6 packets over an IPv4 network (or IPv4 + packets over an IPv6 network), making LISP a valuable mechanism to + ease the transition to IPv6. + + An example is the case of the network infrastructure of a data center + being IPv4 only while dual-stack front-end load balancers are used. + In this scenario, LISP can be used to provide IPv6 access to servers + even though the network and the servers only support IPv4. Assuming + + + +Saucez, et al. Informational [Page 8] + +RFC 7834 LISP Impact April 2016 + + + that the data center's ISP offers IPv6 connectivity, the data center + only needs to deploy one (or more) xTR(s) at its border with the ISP + and one (or more) xTR(s) directly connected to the load balancers. + The xTR(s) at the ISP's border tunnels IPv6 packets over IPv4 to the + xTR(s) directly attached to the load balancer. The load balancer's + xTR de-encapsulates the packets and forwards them to the load + balancer, which act as a proxy, translating each IPv6 packet into an + IPv4 packet. IPv4 packets are then sent to the appropriate servers. + Similarly, when the server's response arrives at the load balancer, + the packet is translated back into an IPv6 packet and forwarded to + its xTR(s), which in turn will tunnel it back, over the IPv4-only + infrastructure, to an xTR connected to the ISP. The packet is then + de-encapsulated and forwarded to the ISP natively in IPv6. + +4.3. Inter-domain Multicast + + LISP has native support for multicast [RFC6831]. From the data-plane + perspective, at a multicast-enabled xTR, an EID-sourced multicast + packet is encapsulated in another multicast packet and subsequently + forwarded in an RLOC-level distribution tree. Therefore, xTRs must + participate in both EID and RLOC-level distribution trees. Control- + plane wise, since group addresses have no topological significance, + they need not be mapped. It is worth noting that, to properly + function, LISP-Multicast requires that inter-domain multicast be + available. + + LISP Replication Engineering (LISP-RE) [LISP-RE] [CDM12] leverages + LISP messages [LISP-MULTI-SIGNALING] for multicast state distribution + to construct xTR-based inter-domain multicast distribution trees when + inter-domain multicast support is not available. Simulations of + three different management strategies for low-latency content + delivery show that such overlays can support thousands of member + xTRs, support hundreds of thousands of end hosts, and deliver content + at latencies close to unicast ones [CDM12]. It was also observed + that high client churn has a limited impact on performance and + management overhead. + + Similar to LISP-RE, "Signal-Free LISP Multicast" [LISP-SFM] can be + used when the core network does not provide multicast support. But + instead of using signaling to build inter-domain multicast trees, + signal-free exclusively leverages the map server for multicast state + storage and distribution. As a result, the source ITR generally + performs head-end replication, but it might also be used to emulate + LISP-RE distribution trees. + + + + + + + +Saucez, et al. Informational [Page 9] + +RFC 7834 LISP Impact April 2016 + + +5. Impact of LISP on Operations and Business Models + + Numerous implementation efforts ([IOSNXOS], [OpenLISP], [LISPmob], + [LISPClick], [LISPcp], and [LISPfritz]) have been made to assess the + specifications, and additionally, interoperability tests [Was09] have + been successful. A worldwide large deployment in the international + lisp4.net testbed, which is currently composed of nodes running at + least three different implementations, will allow us to learn further + operational aspects related to LISP. + + The following sections distinguish the impact of LISP on LISP sites + from the impact on non-LISP sites. + +5.1. Impact on Non-LISP Traffic and Sites + + LISP has no impact on traffic that has neither LISP origin nor LISP + destination. However, LISP can have a significant impact on traffic + between a LISP site and a non-LISP site. Traffic between a non-LISP + site and a LISP site is subject to the same issues as those observed + for LISP-to-LISP traffic but also has issues specific to the + transition mechanism that allow the LISP site to exchange packets + with a non-LISP site [RFC6832] [RFC7215]. + + The transition requires setup of proxy tunnel routers (PxTRs). + Proxies cause what is referred to as path stretch (i.e., a + lengthening of the path compared to the topological shortest path) + and make troubleshooting harder. There are still questions related + to PxTRs that need to be answered: + + o Where to deploy PxTRs? The placement in the topology has an + important impact on the path stretch. + + o How many PxTRs? The number of PxTRs has a direct impact on the + load and the impact of the failure of a PxTR on the traffic. + + o What part of the EID space? Will all the PxTRs be proxies for the + whole EID space, or will it be segmented between different PxTRs? + + o Who operates PxTRs? An important question to answer is related to + the entities that will deploy PxTRs: how will they manage their + additional Capital Expenditure (CAPEX) / Operating Expenses (OPEX) + associated with PxTRs? How will the traffic be carried with + respect to security and privacy? + + A PxTR will also normally advertise in BGP the EID prefix for which + they are proxies. However, if proxies are managed by different + entities, they will belong to different ASes. In this case, we need + to be sure that this will not cause Multi-Origin AS (MOAS) issues + + + +Saucez, et al. Informational [Page 10] + +RFC 7834 LISP Impact April 2016 + + + that could negatively influence routing. Moreover, it is important + to ensure that the way EID prefixes will be de-aggregated by the + proxies will remain reasonable so as not to contribute to BGP + scalability issues. + +5.2. Impact on LISP Traffic and Sites + + LISP is a protocol based on the map-and-encap paradigm, which has the + positive impacts that we have summarized in the above sections. + However, LISP also has impacts on operations: + + MTU issue: As LISP uses encapsulation, the MTU is reduced; this has + implications on potentially all of the traffic. However, in + practice, on the lisp4.net network, no major issue due to the MTU + has been observed. This is probably due to the fact that current + end-host stacks are well designed to deal with the problem of MTU. + + Resiliency issue: The advantage of flexibility and control offered + by the Locator/ID separation comes at the cost of increasing the + complexity of the reachability detection. Indeed, identifiers are + not directly routable and have to be mapped to locators, but a + locator may be unreachable while others are still reachable. This + is an important problem for any tunnel-based solution. In the + current Internet, packets are forwarded independently of the + border router of the network meaning that, in case of the failure + of a border router, another one can be used. With LISP, the + destination RLOC specifically designates one particular ETR; + hence, if this ETR fails, the traffic is dropped, even though + other ETRs are available for the destination site. Another + resiliency issue is linked to the fact that mappings are learned + on demand. When an ITR fails, all its traffic is redirected to + other ITRs that might not have the mappings requested by the + redirected traffic. Existing studies [SKI12] [SD12] show, based + on measurements and traffic traces, that failure of ITRs and RLOC + are infrequent but that when such failure happens, a critical + number of packets can be dropped. Unfortunately, the current + techniques for LISP resiliency, based on monitoring or probing, + are not rapid enough (failure recovery on the order of a few + seconds). To tackle this issue, [LISP-PRESERVE] and + [LISP-ITR-GRACEFUL] propose techniques based on local failure + detection and recovery. + + Middleboxes/filters: Because of the increasingly common use of + encryption as a response to pervasive monitoring [RFC7258] with + LISP providing the option to encrypt traffic between xTRs + [LISP-CRYPTO], middleboxes are increasingly likely to be unable to + understand encapsulated traffic, which can cause them to drop + legitimate packets. In addition, LISP allows triangular or even + + + +Saucez, et al. Informational [Page 11] + +RFC 7834 LISP Impact April 2016 + + + rectangular routing, so it is difficult to maintain a correct + state even if the middlebox understands LISP. Finally, filtering + may also have problems because they may think only one host is + generating the traffic (the ITR), as long as it is not + de-encapsulated. To deal with LISP encapsulation, LISP-aware + firewalls that inspect inner LISP packets are proposed + [lispfirewall]. + + Troubleshooting/debugging: The major issue that LISP experimentation + has shown is the difficulty of troubleshooting. When there is a + problem in the network, it is hard to pinpoint the reason as the + operator only has a partial view of the network. The operator can + see what is in its EID-to-RLOC cache/database and can try to + obtain what is potentially elsewhere by querying the Map + Resolvers, but the knowledge remains partial. On top of that, + ICMP packets only carry the first few tens of bytes of the + original packet, which means that when an ICMP arrives at the ITR, + it might not contain enough information to allow correct + troubleshooting. Deployment in the beta network has shown that + LISP+ALT [RFC6836] was not easy to maintain and control [CCR13], + which explains the migration to LISP-DDT [LISP-DDT], based on a + massively distributed and hierarchical approach [CCR13]. + + Business/operational related: Iannone et al. [IL10] have shown that + there are economical incentives to migrate to LISP; however, some + questions remain. For example, how will the EIDs be allocated to + allow aggregation and hence scalability of the mapping system? + Who will operate the mapping system infrastructure and for what + benefits? What if several operators run different mapping + systems? How will they interoperate or share mapping information? + + Reachability: The overhead related to RLOC reachability mechanisms + is not known. + +6. Security Considerations + + A thorough security and threat analysis of LISP is carried out in + detail in [RFC7835]. For LISP and other Internet technologies, most + of the threats can be mitigated using Best Current Practices, meaning + with careful deployment and configuration (e.g., filter), by + activating only features that are really necessary in the deployment, + and by verifying all the information obtained from third parties. + Unless gleaning (Section 6 of [RFC6830] and Section 3.1 of [RFC7835]) + features are used, the LISP data plane shows the same level of + security as other IP-over-IP technologies. From a security + perspective, the control plane remains the critical part of the LISP + architecture. To mitigate the threats on the mapping system, + authentication should be used for all control-plane messages. The + + + +Saucez, et al. Informational [Page 12] + +RFC 7834 LISP Impact April 2016 + + + current specification defines security mechanisms [RFC6836] + [LISP-SEC] that can reduce threats in open network environments. The + LISP specification defines a generic authentication data field for + control-plane messages [RFC6836], which could be used for a general + authentication mechanism for the LISP control plane while staying + backward compatible. + +7. References + +7.1. Normative References + + [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The + Locator/ID Separation Protocol (LISP)", RFC 6830, + DOI 10.17487/RFC6830, January 2013, + <http://www.rfc-editor.org/info/rfc6830>. + + [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The + Locator/ID Separation Protocol (LISP) for Multicast + Environments", RFC 6831, DOI 10.17487/RFC6831, January + 2013, <http://www.rfc-editor.org/info/rfc6831>. + + [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, + "Interworking between Locator/ID Separation Protocol + (LISP) and Non-LISP Sites", RFC 6832, + DOI 10.17487/RFC6832, January 2013, + <http://www.rfc-editor.org/info/rfc6832>. + + [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation + Protocol (LISP) Map-Server Interface", RFC 6833, + DOI 10.17487/RFC6833, January 2013, + <http://www.rfc-editor.org/info/rfc6833>. + + [RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID + Separation Protocol (LISP) Map-Versioning", RFC 6834, + DOI 10.17487/RFC6834, January 2013, + <http://www.rfc-editor.org/info/rfc6834>. + + [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, + "Locator/ID Separation Protocol Alternative Logical + Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836, + January 2013, <http://www.rfc-editor.org/info/rfc6836>. + + [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, DOI 10.17487/RFC7215, April + 2014, <http://www.rfc-editor.org/info/rfc7215>. + + + + +Saucez, et al. Informational [Page 13] + +RFC 7834 LISP Impact April 2016 + + + [RFC7835] Saucez, D., Iannone, L., and O. Bonaventure, "Locator/ID + Separation Protocol (LISP) Threat Analysis", RFC 7835, + DOI 10.17487/RFC7835, April 2016, + <http://www.rfc-editor.org/info/rfc7835>. + +7.2. Informative References + + [CCR13] Saucez, D., Iannone, L., and B. Donnet, "A First + Measurement Look at the Deployment and Evolution of the + Locator/ID Separation Protocol", ACM SIGCOMM Computer + Communication Review, Vol. 43, Issue 2, pp. 37-43, + DOI 10.1145/2479957.2479963, April 2013. + + [CDLC] Coras, F., Domingo, J., Lewis, D., and A. Cabellos, "An + Analytical Model for Loc/ID Mappings Caches", IEEE/ACM + Transactions on Networking, Vol. 24, Issue 1, pp. 506-516, + DOI 10.1109/TNET.2014.2373398, February 2014. + + [CDM12] Coras, F., Domingo-Pascual, J., Maino, F., Farinacci, D., + and A. Cabellos-Aparicio, "Lcast: Software-defined Inter- + Domain Multicast", Computer Networks, Vol. 59, pp. + 153-170, DOI 10.1016/j.bjp.2013.10.010, February 2014. + + [ConteXtream] + ConteXtream Software Company, , "SDN and NFV solutions for + carrier networks. (Further details on LISP only through + private inquiry.)", <http://www.contextream.com>. + + [IB07] Iannone, L. and O. Bonaventure, "On the cost of caching + locator/ID mappings", in Proceedings of ACM CoNEXT 2007, + DOI 0.1145/1364654.1364663, December 2007. + + [IL10] Iannone, L. and T. Leva, "Modeling the economics of Loc/ID + Split for the Future Internet", IOS Press, pp. 11-20, + DOI 10.3233/978-1-60750-539-6-11, May 2010. + + [IOSNXOS] Cisco Systems Inc., "Locator/ID Separation Protocol + (LISP)", 2015, <http://lisp4.cisco.com>. + + [KIF13] Kim, J., Iannone, L., and A. Feldmann, "Caching Locator/ID + mappings: An experimental scalability analysis and its + implications", Computer Networks, Vol. 57, Issue 4, + DOI 10.1016/j.comnet.2012.11.007, March 2013. + + [LISP-CRYPTO] + Farinacci, D. and B. Weis, "LISP Data-Plane + Confidentiality", Work in Progress, + draft-ietf-lisp-crypto-03, September 2015. + + + +Saucez, et al. Informational [Page 14] + +RFC 7834 LISP Impact April 2016 + + + [LISP-DDT] Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP + Delegated Database Tree", Work in Progress, + draft-ietf-lisp-ddt-03, April 2015. + + [LISP-ITR-GRACEFUL] + Saucez, D., Bonaventure, O., Iannone, L., and C. Filsfils, + "LISP ITR Graceful Restart", Work in Progress, + draft-saucez-lisp-itr-graceful-03, December 2013. + + [LISP-LCAF] + Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical + Address Format (LCAF)", Work in Progress, + draft-ietf-lisp-lcaf-12, September 2015. + + [LISP-MN] Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP + Mobile Node", Work in Progress, draft-meyer-lisp-mn-14, + July 2015. + + [LISP-MULTI-SIGNALING] + Farinacci, D. and M. Napierala, "LISP Control-Plane + Multicast Signaling", Work in Progress, draft-farinacci- + lisp-mr-signaling-06, February 2015. + + [LISP-PRESERVE] + Bonaventure, O., Francois, P., and D. Saucez, "Preserving + the reachability of LISP ETRs in case of failures", Work + in Progress, draft-bonaventure-lisp-preserve-00, July + 2009. + + [LISP-RE] Coras, F., Cabellos-Aparicio, A., Domingo-Pascual, J., + Maino, F., and D. Farinacci, "LISP Replication + Engineering", Work in Progress, draft-coras-lisp-re-08, + November 2015. + + [LISP-SEC] Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. + Saucez, "LISP-Security (LISP-SEC)", Work in Progress, + draft-ietf-lisp-sec-10, October 2015. + + [LISP-SFM] Moreno, V. and D. Farinacci, "Signal-Free LISP Multicast", + Work in Progress, draft-ietf-lisp-signal-free- + multicast-01, April 2016. + + [LISP-TE] Farinacci, D., Kowal, M., and P. Lahiri, "LISP Traffic + Engineering Use-Cases", Work in Progress, + draft-farinacci-lisp-te-10, September 2015. + + + + + + +Saucez, et al. Informational [Page 15] + +RFC 7834 LISP Impact April 2016 + + + [LISPClick] + Saucez, D. and V. Nguyen, "LISP-Click: A Click + implementation of the Locator/ID Separation Protocol", 1st + Symposium on Click Modular Router, November 2009, + <http://hdl.handle.net/2078.1/79067>. + + [LISPcp] "LIP6-LISP open source project", 2014, + <https://github.com/lip6-lisp>. + + [lispfirewall] + "LISP and Zone-Based Firewalls Integration and + Interoperability", 2014, + <http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ + sec_data_zbf/configuration/xe-3s/sec-data-zbf-xe-book/ + sec-zbf-lisp-inner-pac-insp.html>. + + [LISPfritz] + "Unsere FRITZ!Box-Produkte", 2014, + <http://avm.de/produkte/fritzbox/>. + + [LISPmob] "An open-source LISP implementation for Linux, Android and + OpenWRT", 2015, <http://lispmob.org>. + + [OpenLISP] "The OpenLISP Project", 2013, <http://www.openlisp.org>. + + [QIdLB07] Quoitin, B., Iannone, L., de Launois, C., and O. + Bonaventure, "Evaluating the Benefits of the Locator/ + Identifier Separation", in Proceedings of MobiArch, + Article No. 5, DOI 10.1145/1366919.1366926, August 2007. + + [RFC4984] Meyer, D., Ed., Zhang, L., Ed., and K. Fall, Ed., "Report + from the IAB Workshop on Routing and Addressing", + RFC 4984, DOI 10.17487/RFC4984, September 2007, + <http://www.rfc-editor.org/info/rfc4984>. + + [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an + Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May + 2014, <http://www.rfc-editor.org/info/rfc7258>. + + [S11] Saucez, D., "Mechanisms for Interdomain Traffic + Engineering with LISP", PhD Thesis, Universite catholique + de Louvain, September 2011, + <http://hdl.handle.net/2078.1/92231>. + + [SD12] Saucez, D. and B. Donnet, "On the Dynamics of Locators in + LISP", in Proceedings of IFIP/TC6 Networking, pp. 385-396, + DOI 10.1007/978-3-642-30045-5_29, May 2012. + + + + +Saucez, et al. Informational [Page 16] + +RFC 7834 LISP Impact April 2016 + + + [SDIB08] Saucez, D., Donnet, B., Iannone, L., and O. Bonaventure, + "Interdomain Traffic Engineering in a Locator/Identifier + Separation Context", in Proceedings of Internet Network + Management Workshop, DOI 10.1109/INETMW.2008.4660330, + October 2008. + + [SKI12] Saucez, D., Kim, J., Iannone, L., Bonaventure, O., and C. + Filsfils, "A Local Approach to Fast Failure Recovery of + LISP Ingress Tunnel Routers", in Proceedings of IFIP + Networking 2012, pp. 397-408, + DOI 10.1007/978-3-642-30045-5_30, May 2012. + + [Was09] Wasserman, M., "LISP Interoperability Testing", IETF + 76, LISP WG Presentation, November 2009. + +Acknowledgments + + Thanks to Deborah Brungard, Ben Campbell, Spencer Dawkins, Stephen + Farrel, Wassim Haddad, Kathleen Moriarty, and Hilarie Orman for their + thorough reviews, comments, and suggestions. + + The people that contributed to this document are Alia Atlas, Sharon + Barkai, Ron Bonica, Ross Callon, Vince Fuller, Joel Halpern, Terry + Manderson, and Gregg Schudel. + + The work of Luigi Iannone has been partially supported by the + ANR 13 INFR 0009 LISP-Lab Project <http://www.lisp-lab.org>. + + + + + + + + + + + + + + + + + + + + + + + + +Saucez, et al. Informational [Page 17] + +RFC 7834 LISP Impact April 2016 + + +Authors' Addresses + + Damien Saucez + INRIA + 2004 route des Lucioles BP 93 + 06902 Sophia Antipolis Cedex + France + + Email: damien.saucez@inria.fr + + + Luigi Iannone + Telecom ParisTech + 23, Avenue d'Italie, CS 51327 + 75214 Paris Cedex 13 + France + + Email: ggx@gigix.net + + + Albert Cabellos + Technical University of Catalonia + C/Jordi Girona, s/n + 08034 Barcelona + Spain + + Email: acabello@ac.upc.edu + + + Florin Coras + Technical University of Catalonia + C/Jordi Girona, s/n + 08034 Barcelona + Spain + + Email: fcoras@ac.upc.edu + + + + + + + + + + + + + + + +Saucez, et al. Informational [Page 18] + |