A Deep Dive Into the LISP Cache and What Isps Should Know About It Juhoon Kim, Luigi Iannone, Anja Feldmann
Total Page:16
File Type:pdf, Size:1020Kb
A Deep Dive into the LISP Cache and What ISPs Should Know about It Juhoon Kim, Luigi Iannone, Anja Feldmann To cite this version: Juhoon Kim, Luigi Iannone, Anja Feldmann. A Deep Dive into the LISP Cache and What ISPs Should Know about It. 10th IFIP Networking Conference (NETWORKING), May 2011, Valencia, Spain. pp.367-378, 10.1007/978-3-642-20757-0_29. hal-01583403 HAL Id: hal-01583403 https://hal.inria.fr/hal-01583403 Submitted on 7 Sep 2017 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. Distributed under a Creative Commons Attribution| 4.0 International License ADeepDiveintotheLISPCache and what ISPs should know about it Juhoon Kim!, Luigi Iannone, and Anja Feldmann Deutsche Telekom Laboratories – Technische Universit¨at Berlin Ernst-Reuter-Platz 7, 10587 Berlin, Germany Abstract. Due to scalability issues that the current Internet is facing, the research community has re-discovered the Locator/ID Split paradigm. As the name suggests, this paradigm is based on the idea of separating the identity from the location of end-systems, in order to increase the scalability of the Internet architecture. One of the most successful pro- posals, currently under discussion at the IETF, is LISP (Locator/ID Separation Protocol). A critical component of LISP, from a performance and resources consumption perspective, as well as from a security point of view, is the LISP Cache. The LISP Cache is meant to temporarily store mappings, i.e., the bindings between identifiers and locations, in order to provide routers with the knowledge of where to forward pack- ets. This paper presents a thorough analysis of such a component, based on real packet-level traces. Furthermore, the implicationsofpoliciesto increase the level of security of LISP are also analyzed. Our results prove that even a timeout as short as 60 seconds provides high hit ratio and that the impact of using security policies is small. Keywords: Locator/ID Separation; Next Generation Internet; Addressing and Routing Architectures; Measurements; 1Introduction In the last years, there has been an increasing interest in the Locator/ID Split paradigm, which is recognized to be a strong candidate to become a fundamental building block of the Next Generation Internet. Differently from the current ar- chitecture, where one single namespace, namely the IP address space, is used for both indentifying and locating end-systems, in the Locator/ID Split paradigm two different namespaces are used: the ID space and the Locator space,tore- spectively identify and locate end-systems. Such a separation aims at solving the scalability issues that the current Internet is facing [19], mainly concerning the continuously increasing BGP routing table [1], but also concerning addressing, mobility, multi-homing [22], and inter-domain traffic engineering [25]. The main effort to tackle these issues has started three years ago,whenthe Routing Research Group (RRG) has been rechartered to explore the possibility ! Corresponding Author: Juhoon Kim ([email protected]). 2J.Kimetal. to enhance the Internet architecture by introducing some form ofLocator/ID Split. Among the numerous proposals introduced since then [16], the most suc- cessful so far are ILNP (Identifier/Locator Network Protocol [5]), which has been adopted by the RRG, and LISP (Locator/ID Separation Protocol [7]), which has been chartered as Working Group in the IETF and has been already deployed in an international test-bed [2]. On the one hand, all the proposals improve the Internet architecture, in a way or another, by some form of Locator/ID Split. On the other hand, they introduce the necessity to distribute and store bindings between IDs and Locators (i.e., mappings), which is the key critical component that can make the difference. Hence, the importance of evaluating what is the cost (i.e., memory consumption, overhead, ...) of storing and distributing these mappings. In addition, the way they are managed does also have an impact on the robustness of the proposed architecture with respect to security threats. Focusing on LISP as reference protocol, in this paper we present a thorough analysis of the mapping cache. In a previous work, Iannone et al. analyzed a Netflow traffic trace from a small/medium sized university campus [11]. We build our work on the same methodology, but develop a new emulator in order to go beyond previous results and provide a deeper analysis. For this purpose, we use two 24-hour packet-level traces from a large European ISP, taken at different periods of the year. Further, Saucez et al. [24], in their security analysis of the LISP protocol, highlighted that a number of attacks can be avoided by slightly modifying the policy that LISP uses to encapsulate and decapsulate packets. Hence, we evaluate what are the implications, from a scalability point of view, of running LISP in such a more secure manner, which we call symmetric LISP. The contributions of this paper are many-fold. We thoroughly analyze the behavior of a LISP Cache for traffic of a large number of DSL customers. Our results show that it is possible to maintain a high hit ratio with relatively small cache sizes, showing that there is no use in large timeouts. Compared to [11], we show how the LISP Cache has good scalability properties. We analyze what and how much would change if instead of running vanilla LISP, i.e., as defined in the specifications, symmetric LISP is used in order to increase security. Our results are important for ISPs in order to identify and quantify the resources needed to deploy LISP, with respect to the level of resiliency that they want toguarantee. The remainder of this paper is structured as follows. In Section 2 we present the related work. In Section 3 we provide an overview of LISP in order to high- light how the LISP Cache works and the motivation for symmetric LISP. Sec- tion 4 describes how we collected and analyzed the traces used to obtain the results presented in Section 5. Finally, we draw our conclusions in Section 6. 2RelatedWork The concept of Locator/ID Split was already discussed, but never widely ex- plored, in the late 90s ([23], [10]); rather used to solve specific issues, like crypto- graphic security with HIP (Host Identity Protocol [20]) or multi-homing for IPv6 with Shim6 [21]. The situation has changed after the rechartering of the RRG, ADeepDiveintotheLISPCache 3 with quite a number of proposals being discussed, either based on tunneling (e.g., LISP [7], HAIR [8]) or on address rewriting (e.g., ILNP [5], Six/One [26]). Despite the plethora of proposals, very few works have tackled the evaluation of such a critical component as the cache. Kim et al. [27] studied route caching based on Netflow data, showing how caching is feasible also for large ISPs. However, they used a generic approach, not focused on LISP, and a limited cache size. Iannone et al. [11] have performed an initial study, without considering security issues, based on a single Netflow trace of a small/medium sized university campus. We adopt a similar methodology to provide comparable results, which we discuss in Section 6. Nevertheless, because we base our results on two 24-hour packet level traces captured in different periods we are able to provide a deeper analysis, including security aspects. In the work of Zhang et al. [9], the authors propose a simple LISP Cache model with bounded size, using a Least Recently Used (LRU) policy to replace stale entries.1 Their evaluation is based on a 24-hour trace of outbound traffic of one link of the CERNET backbone, the China Education and Research Network. In our analysis we take a different approach, assuming that the cache is not limited in size. This is a reasonable assumption since, as we will show later,even for large ISPs there is no need to use large caches and by tuning the expiration timer, caches do not grow so large as to hit memory limits of current routers. Jakab et al. [14] propose a LISP simulator able to emulate the behaviorof different mapping systems. However, they focused on the evaluation of the la- tency of their own mapping system solution, namely LISP-TREE, and compared it to other approaches but neglecting the analysis of the LISP Cache. 3LISPOverview The main idea of the Locator/ID Separation Protocol (LISP [7]) is to split the IP addressing space in two orthogonal spaces, one used to identify the end-hosts, and one used to locate them in the Internet topology. By re-using IP addresses, LISP is incrementally deployable and meant to be used on the border routers of stub domains, like in the scenario presented in Figure 1. Stub domains use internally an IP prefix, called EID-Prefix as for End-system IDentifier, which is part of the ID space. This prefix does not need to be globally routable, since it is used only for routing in the local domain. On the contrary, the core of the Internet, known as Default Free Zone (DFZ), will use globally routable IP addresses that are part of the locator space. In particular, the IP addresses used by stub domains’ border routers on their upstream interfaces (toward the provider) are part of such a space and represent the Routing LOCators (RLOCs), since they allow to locate EID in the Internet.