Mobile IPv6 : architectures et protocoles

Transcription

1 Thèse de Doctorat de l Université Paris VI Pierre et Marie Curie Spécialité Systèmes Informatiques présentée par Guillaume Valadon pour obtenir le grade de Docteur de l Université Pierre et Marie Curie Mobile IPv6 : architectures et protocoles soutenue le 27 Juin 2008 devant le jury composé de MM. : Eric Fleury Rapporteurs Thomas Noel MM. : Rui Aguiar Examinateurs Hiroshi Esaki Sébastien Tixeuil M. : Serge Fdida Directeur M. : Ryuji Wakikawa Encadrant

2

3 Thèse de Doctorat de l Université Paris VI Pierre et Marie Curie Spécialité Systèmes Informatiques présentée par Guillaume Valadon pour obtenir le grade de Docteur de l Université Pierre et Marie Curie Mobile IPv6 : architectures et protocoles soutenue le 27 Juin 2008 devant le jury composé de MM. : Eric Fleury Rapporteurs Thomas Noel MM. : Rui Aguiar Examinateurs Hiroshi Esaki Sébastien Tixeuil M. : Serge Fdida Directeur M. : Ryuji Wakikawa Encadrant

4

5 Remerciements Je remercie Eric FLEURY, Professeur à l École Normale Supérieure de Lyon, et Thomas NOEL, Professeur à l Université Louis Pasteur de Strasbourg, d avoir bien voulu accepter la charge de rapporteurs. Je remercie Rui AGUIAR, Professeur à l Université d Aveiro au Portugal, Hiroshi ESAKI, Professeur à l Université de Tokyo au Japon, et Sébastien TIXEUIL, Professeur à l Université Pierre et Marie Curie, d avoir bien voulu juger ce travail. Je remercie Serge FDIDA, Professeur à l Université Pierre et Marie, d avoir bien voulu encadrer cette thèse. Je tiens également à remercier Ryuji WAKIKAWA, désormais Chercheur chez Toyota ITC au Japon, avec qui j ai eu l honneur de travailler sur différents projets liés à la mobilité comme Home Agent Migration, présenté dans cette thèse. Ses qualités scientifiques et humaines ont tout particulièrement contribué au très bon déroulement de mon séjour au Japon. Je remercie enfin Clémence MAGNIEN, Chargée de Recherche au CNRS, pour m avoir apporté une aide très précieuse dans la rédaction et les multiples relectures de ce manuscrit. Mon expérience japonaise, quant à elle, n aurait pas été possible sans l aide de nombreuses personnes dont Atau TANAKA, Professeur à l Université de Newcastle en Angleterre, et Kenjiro CHO, Chercheur chez Internet Initiative Japan, qui m ont présenté différents chercheurs japonais, et de ce fait ont activement participé aux premières étapes de mon projet de thèse au Japon. Dans ce contexte, je tiens tout d abord à remercier Hiroshi ESAKI pour m avoir chaleureusement accueilli dans son laboratoire à l Université de Tokyo et financé pendant les derniers mois de mon séjour. Je remercie également mes collègues de Murai lab, à l Université de Keio, ainsi que mes collègues d Esaki lab, à l Université de Tokyo. Qu il me soit permis de remercier séparément Seiichi YAMAMOTO pour tout le temps qu il a passé à m aider lors de mon installation à Tokyo, ainsi que dans les différentes démarches administratives précédant mon arrivée. J ai également rencontré de nombreuses personnes durant mes deux années au Japon qui resteront, je l espère, des amis malgré la distance. Pèle-mêle, merci à Daphne, Romain, Koshiro, Lou, Marin, Martin, Mai, et Yukie. Mention spéciale au master du meilleur restaurant du monde (à Yokohama) : le teppan et la bière sont deux éléments indissociables des recherches réussies! Finalement, je remercie Ema pour l aide qu elle m a apportée avant et pendant mon séjour. Sans elle, tout aurait été beaucoup plus compliqué, voire impossible. Merci de m avoir fait découvrir le Japon, et permis de pratiquer le peu de japonais que je connais! i

6 Merci aux membres du bureau 720 : Laurent, Georges, Florian, et Christophe, pour leurs délires, leur aide, et leur bonne humeur. Merci aux anciens et autres dinosaures, Augustin, Julien, Chantal, et Matthieu, pour m avoir montré la voie de la sagesse ; parce que c est important. Merci également aux autres membres du labo pour les discussions autour d un café et les dépannages de clopes! Finalement, merci à ma famille, mes amis et mes relectrices. Merci aux hipss, barbus, zedou et autres clubers du week-end. Merci à celles et ceux qui ont eu la patience et le courage de me supporter durant ces quatre années. Merci également à celles et ceux qui n ont pas eu cette chance. Merci à celles et ceux qui ont fait un détour par Tokyo. Merci à celles et ceux qui sont venus me chercher un mercredi matin à 4h30 à Roissy. Merci au Limoncello et à Radio Head. Merci à ceux qui m ont mis une red hat entre les mains par un beau dimanche de juin 98. Merci aux globotruncanidés. Merci aux Urgences (et surtout bienvenue). Merci à Philibert et au Quick. Merci aux joggings du vendredi soir. Par ordre alphabétique, sans ordre de préférence, et sur un air des Bérus, merci à toi : Alexis, Adeline, Arnaud, Boulette, Bozze, Carter, Ceache, Citrouille, Delphine, Emilie, Etis, Evy, Faustine, Flavie, Fred, Galipette, Gratoune, Grizz, Hélène, IKR, Julio, Karim, Kat, Kinou, Kozette, Léo, Manu, Marion, Mat, Mel, Michel, Philippe, Pingouin, Pwetty, Renaud, Romain, Sail, Séverine, Shai, Sly, Spyou, Thierry, troglocan, Vincent, Virginie, et Zoro. Si jamais malgré toute mon attention, je t ai oublié (ou alors si tu es mégalomane), ajoute ton nom ici : Enfin, merci à tous ceux qui ont relevé le défi d affronter la soutenance! ii

7 Résumé L architecture de l Internet est telle que, lorsqu un utilisateur se déplace et change de réseau, l adresse IP de son périphérique est modifiée, entraînant la perte des communications en cours. Afin de résoudre ce problème, des protocoles de gestion de la mobilité ont été définis pour rendre les communications insensibles aux mouvements et indépendantes du réseau où se trouve l utilisateur. Cependant, la plupart des propositions souffrent de problèmes affectant leurs performances, ou bien encore leur utilisation dans l architecture actuelle de l Internet. Par exemple, certaines d entre elles, comme le protocole HIP, imposent que tous les périphériques, y compris ceux qui sont fixes, implémentent le protocole de mobilité. D autres encore, tel que le protocole Mobile IPv6, induisent des chemins plus longs et donc des délais de communication plus importants. Ce travail de thèse vise à améliorer les performances du protocole Mobile IPv6 en contrôlant les différentes limitations induites par l utilisation d un routeur gérant la mobilité : le home agent. Pour ce faire, nous proposons deux approches complémentaires qui tout en étant compatibles avec l infrastructure actuelle de l Internet, permettent de gérer la mobilité de façon transparente à la fois pour le réseau et les périphériques fixes. Tout d abord, nous décrivons une nouvelle architecture distribuée de gestion de la mobilité appelée Home Agent Migration qui permet d utiliser plusieurs home agents simultanément. Grâce à un déploiement réel, nous montrons qu il est possible d obtenir des performances comparables à celles de communications n utilisant pas Mobile IPv6. Ensuite, nous définissons formellement les propriétés des emplacements des home agents en termes de théorie des graphes. En s appuyant sur cette étude, nous quantifions l impact du protocole Mobile IPv6 sur les communications. Finalement, nous proposons un nouvel algorithme qui permet de traiter les problématiques de déploiement de Mobile IPv6 et de Home Agent Migration dans des graphes qui modélisent des réseaux de communication. Mots-Clés Mobile IPv6, gestion de la mobilité, anycast, graphe, centralité iii

8

9 Abstract Nowadays, mobile devices, such as laptops, are commonly used to access the Internet from different locations during the same day. With the current Internet architecture, a change of location requires a mandatory modification of the IP address, and as a result the loss of ongoing communications. Under these constraints, mobility protocols were designed to make communications resilient to movements and location independent. So far, diverse mobility protocols were defined that efficiently solve mobility related issues. Unfortunately, most of them suffer from design choices that impact their performances, or make them impractical for immediate deployments. For example, some protocols require that every node implements mobility support, including non-mobile ones; or causes longer paths and higher communications delays. In this thesis, we present two possible approaches to improving Mobile IPv6 performances, and to control its current shortcomings. These approaches are completely compatible with the current networking technologies, and can be used to perform immediate deployments of mobility support on the Internet. We first propose Home Agent Migration, an additional mobility management plane, which distributes home agents (specific mobility routers) inside the Internet topology. Practical experiments show that it is possible to obtain performances almost identical to communications without Mobile IPv6. Then, we formally define the properties of home agent locations in terms of graph theory, and quantify the impact of Mobile IPv6 on communications. Finally, based on this study, we describe a new algorithm that addresses deployment issues of Mobile IPv6 and Home Agent Migration that could be applied to any operator s network. Keywords Mobile IPv6, mobility management, anycast, graph, betweenness centrality v

10

11 Contents Remerciements Résumé Abstract Contents i iii v vii 1 Introduction Standard problems induced by Mobility What is mobility support anyway? Approaches for Internet mobility support Locators and identifiers Which identifiers? Design constraints Overview of Mobile IPv Contributions Outline Background on Mobile IPv Mobile IPv Preliminary terminology Operation of Mobile IPv Return Routability Procedure NEMO Home Agent Discovery vii

12 2.2 Protocols limitations Mobile IPv Return Routability Procedure NEMO Security overview Possible attacks against Mobile IPv IPsec protection Standardized optimizations Hierarchical Mobile IPv Fast Handover for Mobile IPv Multiple Care-of Address Conclusion Home Agent Migration General overview How it works Typical deployments Advantages Drawbacks Practical implementation Notion of Binding Cache Communication examples Movements of mobile nodes Example of a typical deployment The underlying protocol NEMO support Security considerations Evaluation Performances comparisons Experimental results Related Work Conclusion Mobile IPv6 deployments Graph theory reminders Preliminary definitions Importance of vertices viii

13 4.2 Networks as graphs Observing networks Modeling networks Weights on edges Home Agents locations Impact on paths lengths Optimal locations Comparison methodology Evaluation Studied networks Relationship between the degree and the betweenness Mobile IPv Home Agent Migration Related work Conclusion Conclusion 87 A Scapy: IPv6 and BPF extensions 93 A.1 Contributed extensions A.1.1 Scapy A.1.2 BPF extension A.2 Routing Header Type A.2.1 In a nutshell A.2.2 Advanced traceroutes A.2.3 Amplification attacks B Thesis French Version 107 B.1 Introduction B.1.1 Protocoles de mobilité B.1.2 Plan B.2 Mobile IPv6 et ses limitations B.2.1 Fonctionnement de Mobile IPv B.2.2 Limitations de Mobile IPv B.2.3 Conclusion B.3 Home Agent Migration B.3.1 Aperçu ix

14 B.3.2 Fonctionnement B.3.3 Résultats expérimentaux B.3.4 Conclusion B.4 Déploiement de Mobile IPv B.4.1 Emplacements des home agents B.4.2 Méthodologie B.4.3 Évaluation B.4.4 Conclusion B.5 Conclusion B.5.1 Contributions B.5.2 Perspectives Bibliography 131 List of Figures 141 List of Tables 143 x

15 Chapter 1 Introduction Contents 1.1 Standard problems induced by Mobility What is mobility support anyway? Approaches for Internet mobility support Locators and identifiers Which identifiers? Design constraints Overview of Mobile IPv Contributions Outline

16 Standard problems induced by Mobility Since 2000, both computing and networking landscapes have drastically changed. In developed countries, networks are accessible virtually everywhere, thanks to heterogeneous wireless technologies and computing devices that can easily fit in one s pocket and are powerful enough to compete with desktops. Moreover these technical evolutions also change how we interact with the technology itself. Mobile phones are indeed entirely part of our daily life. We use them not only for work but also to communicate with friends, access the Internet or play games. They are slowly modifying the way we socialize with each other [80] and how we access the information: in 2006, mobile devices in Japan represents 57% 1 of all user access to the Internet. Nowadays, users can do with their mobile phones what they would sitting in front of their desktops: exchange s [2], access maps [6] or buy music [7]. For decades, people had been mobile on a daily basis but they can only use technology on the go since a few years. Another change in mobile phones usages recently took place thanks to dual-mode GSM/Wi-Fi handsets and Voice over IP (VoIP) services. In metropolitan areas, wireless networks are available in diverse locations such as workplaces, cafés, parks or homes. As a consequence, the high density of Wi-Fi access points [55, 68, 67] and their wide communication ranges allow mobile devices to detect tens of access points from the same location while walking in the streets. Users can therefore take advantage of their VoIP accounts by using Wi-Fi to make cheap phone calls wherever they are. 1.1 Standard problems induced by Mobility A high density of Wi-Fi access points is however not synonym of mobility. Strictly speaking, a mobile device is only connected to one access point at the same time. Traditionally, if the device goes out of the access point s range, it looses its network connectivity and must connect to another access point. Previous works addressed this issue by expanding a unique network broadcast domain across several Wi-Fi access points by relying on wired or wireless [17, 61] backbones. Nevertheless, as of today, it is not possible to perform vertical handovers in order to provide seamless voice calls between different access technologies such as Wi-Fi and HSDPA. Such handovers would for example allow a mobile phone to automatically switch a phone call from a paying HSDPA link to a free Wi-Fi one when the user comes in range of well-known Wi-Fi access points. From the Internet Protocol (IP) perspective, a handover 2 occurs when a node moves from one subnetwork to another. 1 owned by approximately 48 million people, according to The Japanese Ministry of Internal Affairs and Communications. 2 either horizontal or vertical.

17 Chapter 1. Introduction 3 Technically, it currently implies a mandatory change of the node s IP address and therefore the termination of ongoing UDP and TCP connections. They cannot be recovered, and must be restarted using the newly acquired address. If we consider phone calls, this change of address means that the call is first stopped then restarted. As of today, handovers in Internet-like architecture are far from being easy to recover from, as they must be handled either manually by the users, or independently in every single application. This example intelligibly lays down the context of mobility support on the Internet as well as technical constraints that it must deal with. We list the main categories of such constraints below. 1. Change of IP address Due to the Internet routing and addressing architectures, a node s IP address must correspond to its physical location at all times. Otherwise it is not able to receive and send IP packets to its correspondents. Consequently, a node cannot use the same address everywhere it goes, and must obtain a new address when it joins a new subnetwork. 2. Connection losses The most popular transport protocols (TCP and UDP) were not designed to handle changes of IP address. As a result, ongoing communications stop working after a movement. Similarly, applications need to implement mechanisms to automatically recover from connection losses. However, most applications do not have such mechanisms and, in practice, users must manually restart lost connections. 3. End-to-end communications The recent arrival of Voice over IP makes the first move towards the come back of real end-to-end communications. Today, client/server communications prevail and close to zero application makes use of end-to-end communications. Even though some applications 3 are able to establish direct communications in Network Address Traversal (NAT) environments, they cannot be considered as pure end-toend communications as a third party is necessary to punch holes into NAT [51]. In a mobility context, end-to-end communications represent an important technical challenge, as they must survive both changes of IP address and connection losses. So far, various protocols [93, 91, 83, 94, 74, 100, 20] were defined at the Internet Engineering Task Force (IETF) to provide mobility support to mobile nodes and to 3 such as Skype.

18 What is mobility support anyway? solve problems such as previously described. This thesis focuses on the Mobile IPv6 protocol [66], described in Section 1.4, which aims at achieving immediate deployments of mobility services over the Internet through incremental upgrades of its current architecture. This thesis proposes solutions to improve the performance of Mobile IPv6 and solve its various limitations. It specifically concentrates on the IPv6 protocol that makes up a favorable environment for mobility with the disappearance of NAT, and a flat addressing space. Unless stated otherwise, this manuscript will only discuss IPv6 [41, 18], therefore terms such as IP address or IP must be interpreted as IPv6 address and IPv What is mobility support anyway? With mobile phones technologies, such as GSM [118], users keep the same phone number, a unique identifier, when they move or even travel to a different country; they can be reached whatever their locations. Handovers are appropriately supported: voice calls are not stopped during or after movements. Using these technologies as a reference, mobility can be interpreted as the capacity to move easily and freely without impacting the ongoing communications. Accordingly from an end-user perspective, being mobile is being able to move a device around while seamlessly accessing the communication network with no modification to the device applications nor configurations. This implies that every device must be uniquely and permanently identified independently of its physical location. From the network architecture point of view, an address is required to deliver data from, and to users. On the Internet, as described in Section 1.1, when a node moves, its IP address changes. Because, the address is strongly linked to the node s physical location and the subnetwork it is connected to, it is called a locator. Providing mobility support on the Internet is therefore offering a permanent identifier to a mobile device 4 along with a temporary locator which can change over time, and defining mechanisms to store and retrieve the binding between identifiers and locators. Nowadays, many research works try to address mobility support on the Internet: they range from local to Internet scopes, are implemented at the transport or network level, or target modifications of end-nodes or the infrastructure. Their application time lines are also different: some research aim at providing near future deployments [66], while other ones require heavy changes to the current Internet architecture [49] that will not be possible until several tens of years. In the remainder of this chapter, we 4 also referred as a mobile node.

19 Chapter 1. Introduction 5 will first provide a deeper analysis of requirements to support mobility on the Internet. Then, we will briefly present our work to improve the performance of the Mobile IPv6 protocol. 1.3 Approaches for Internet mobility support In this section, we summarize the issues and technical choices that arise while designing mobility protocols for the Internet. Our goal is to describe the common requirements of Internet mobility support and briefly present typical mobility protocols as well as their design constraints Locators and identifiers As previously discussed, the primary property of a mobility protocol is to give both an identifier and a locator to mobile nodes; two elements that describe a node s identity and its physical location. However, in order to make mobility protocols complete, there must be some mechanisms to map a locator to an identifier, and retrieve a locator given its corresponding identifier. For example, in a phone book, people s names are the identifiers and phone numbers are the locators that change over time as people move to new residences. In order to make a phone call to a friend, a user can look up into a phone book and find the corresponding phone number. If it changes, the user can look up into an updated phone book and find its friends new phone number. From the network perspective, this metaphor brings several problematic questions that affect mobility protocols design. 1. What are identifiers and locators exactly? Phone numbers; IPv6 addresses; domain names; people names? 2. How is the mapping performed? In mobile nodes; with an external database; in a peer-to-peer fashion; by pushing only the mapping to well-known correspondents? 3. When does a correspondent choose to retrieve the mapping? Each time it needs to communicate with the mobile node; at fixed time interval; with a cache that uses a timer to make entries expire; never? On the Internet, the addressing and routing architectures strongly constrain the location of a node. An IPv6 address belonging to an IPv6 prefix allocated to a French

20 Approaches for Internet mobility support Names Domain names ID IP addresses Protocols DNS HIP, SCTP MIPv6, LISP, NETLMM Table 1.1: Identifiers examples Internet Service Provider cannot be used to receive packets in Japan. Consequently, the current Internet architecture makes it impossible to keep the same address when a node moves. This problem is linked to the dual function of the IP address. First, it implicitly provides the position of a node on the globe (the locator). Then, it uniquely identifies the node in the whole Internet topology (the identifier). As a consequence, mobility protocols simply rely on the Internet routing architecture to ensure the delivery of mobile nodes packets, and use IP addresses as mobile nodes locators. The different protocols will therefore compete in the way they provide permanent identifiers and efficient mapping mechanisms Which identifiers? The elements used as identifiers are deeply related to the design of mobility protocols. As listed in Table 1.1, several possibilities to supply permanent identifiers are available. For example, if we consider domain names as the identifier, we can define an elementary application-based mobility protocol as follows. Every time a mobile node joins a new subnetwork, it updates its DNS Resource Record [82] with its newly acquired IPv6 address. This could be easily implemented with virtually no modification to correspondents or mobile nodes, and will work on the current Internet. However, this protocol presents drawbacks as ongoing connections are lost after handovers, and as correspondents must access the DNS server frequently to retrieve the most recent IP address. On the other hand, HIP [83] and SCTP [91, 104] are designed as new transport 5 protocols implemented in both mobile and correspondent nodes. Connections in these protocols are able to survive to a handover by automatically notifying correspondents of a change of IP address: ongoing connections can therefore be used after a movement. 5 although HIP is often referred as a layer 3.5 protocol.

21 Chapter 1. Introduction 7 From the application perspective, packet losses put aside, handovers have no impact. These protocols allow both end-nodes to move inside the Internet topology. However, they require all applications to be modified so as to benefit from their mobility support: HIP and SCTP sockets are not compatible with regular TCP and UDP ones. Finally with mobility protocols that use IPv6 addresses as identifiers, such as Mobile IPv6, LISP (Locator/ID Separation Protocol) [49] or NETLMM (Network-based Localized Mobility Management) [56], correspondents nodes are not concerned by mobile nodes mobility and communicate with them using the IPv6 address as they would do with non-mobile nodes. Consequently, such protocols are fully compatible with current implementations of TCP and UDP. Applications are not aware that mobility support is being used, even on the mobile node s side. In such protocols, mobility is either supported by mobile nodes or by the network. These protocols can however introduce longer communication delays due to non-optimal communication paths Design constraints As previously discussed, all mobility protocols designed at the IETF take different approaches to provide mobility support over the Internet. While these protocols may sometime look divergent, they can however be classified and compared using the following requirements. 1. Realistic utilization In order to ease its deployment and accelerate its adoption, a mobility protocol must not require any modification on correspondents sides: they should be able to communicate with mobile nodes as if they were not mobile. Concerning an immediate usage of mobility support on the Internet, it is indeed unreasonable to assume that all nodes will be upgraded to support mobility. Moreover, it is unlikely that any mobility protocol will be implemented on the server side, such as Google or MSN, as this leads to higher operational costs without any performance benefit for the service provider. 2. Small impact on the existing network architecture This is somehow similar to (1) but from a network perspective. All required changes to the network architecture should remain compatible with the current Internet technologies. Concerning immediate deployments, only incremental changes could be seriously considered for practical mobility support: it is not feasible to break the current addressing and routing architectures.

22 Approaches for Internet mobility support Protocols DNS-based x x SCTP, HIP x x LISP x x x MIPv6 x x x MIPv6 & RRP x x x OLSR, AODV x x Table 1.2: Design constraints and mobility protocols examples 3. Transparency to transport layers and applications We allow packet losses, but ongoing connections must smoothly survive handovers. Moreover, mobility support must not require any modification to applications. This is impracticable, as every application would need to be upgraded. In terms of network layers, this means that the mobility protocol must either reside below transport layers, or provide its functionalities through transparent application proxies such as SOCKS [75]. 4. Similar performances A mobility protocol should not seriously impact the communications performances, nor increase the load on the network. Moreover, it should also scale to provide acceptable performances when the number of mobile nodes increases. Ultimately, the users experience should remain the same as in a non-mobile context. Giving the four design constraints, we provide an overview of different mobility protocols alternatives in Table 1.2. It easily highlights that the implementation choices (such as the networking layer, the locator/identifier mapping, or the locator types) impact application scopes of mobility protocols. For example, the Optimized Link State Routing (OLSR) routing protocol [33], designed to support Mobile Ad-hoc Networks (MANET), must be implemented in every node that want to benefit from its features. However, it allows nodes to communicate in areas where there is no communication infrastructure by automatically adapting itself to nodes movements. On the other hand, LISP efficiently separates nodes identifiers from routing locators while remaining