Mobilité IPv6 et WLAN Expérimentation et évaluation à l'échelle d'un campus

Transcription

1 Mobilité IPv6 et WLAN Expérimentation et évaluation à l'échelle d'un campus Thomas Noel *, Nicolas Montavont *, Philippe Bertin * LSIIT Université Louis Pasteur Strasbourg {noel, montavont}@dpt-info.u-strasbg.fr France Télécom R&D philippe.bertin@francetelecom.com I. Introduction L utilisation de réseaux locaux sans fil ne cesse de se démocratiser, notamment dans les réseaux d'entreprise et domestiques, les lieux publics et les campus universitaires. Plus particulièrement, ces derniers sont confrontés à un problème croissant : les étudiants sont de plus en plus nombreux alors que les salles de ressources informatique à mettre à leur disposition ne sont pas extensibles dans les mêmes proportions. De plus, ils offrent un terrain d'expérimentation privilégié pour les nouvelles technologies de par leur étendue géographique et leur importante population segmentée en plusieurs catégories (étudiants, enseignants, chercheurs, visiteurs). Ces expérimentations permettent ainsi d'anticiper les usages à venir dans d'autres sphères d'activités, en particulier les entreprises. Les technologies de réseaux sans fil supportant la mobilité de niveau 2 (lien radio), il n'est possible de maintenir la continuité de service pour les applications IP que lorsque le terminal se déplace entre points d'accès d'un même sous-réseau IP. Cette continuité n'est donc pas assurée pour un réseau sans fil étendu sur plusieurs sous-réseaux IP, à moins de l'associer à un protocole réseau spécialisé dans la gestion de la mobilité tel que Mobile IP. En particulier, l utilisation de la nouvelle version du protocole IP (IPv6) associée au protocole Mobile IPv6 offre de nouvelles perspectives. Ces protocoles permettent notamment de mettre en œuvre un ensemble de mécanismes pour un meilleur support des équipements mobiles sur l Internet Nouvelle Génération. Nous avons donc cherché à trouver une réponse aux besoins d'accès informatiques à l'échelle d'un campus en déployant un réseau sans fil associé à la mise en œuvre des protocoles Internet de Nouvelle Génération. Cette expérimentation a plusieurs objectifs : d une part pallier aux manques de salles de ressources en offrant une connectivité réseau aux étudiants et cela en s affranchissant de contraintes logistiques et d autre part permettre aux étudiants de se déplacer sur le campus universitaire tout en restant connecté au réseau et ses services pendant leurs déplacements. Cet article décrit dans un premier temps les contraintes liées au déploiement d un tel réseau, il présente les différents choix technologiques retenus puis il détaille un certain nombre de résultats découlant de l utilisation conjointe de la mobilité IPv6 sur des réseaux sans fil.

2 II. Contraintes techniques Lors de la phase d étude préalable au déploiement et à l évaluation du réseau lui-même un certain nombre de contraintes techniques ont été identifiées : L utilisation de technologie sans fil pose un premier problème de dimensionnement. En effet, il est difficile à l heure actuelle d estimer le nombre d équipements nécessaires afin d offrir une aire de couverture «continue» sur l ensemble du campus.! La sécurité est certainement l un des points les plus sensibles. L utilisation de technologie sans fil pose le problème du contrôle d accès à ce médium. Il est impératif de s assurer que seules les personnes autorisées par l université (étudiants, enseignants, personnels de l université) puissent accéder à ces ressources. Il est également essentiel que les données transitant sur la voie radio soient encryptées de manière fiable.! Le protocole IPv6 est standardisé, toutefois les constructeurs d équipements et de systèmes d exploitations ne fournissent pas encore d équipements supportant l ensemble des fonctionnalités associées comme la mobilité IPv6 [1] dont la norme n'est pas encore stabilisée. Il a donc fallu réaliser des expérimentations à l aide de produits non finalisés.! Les applications sont le cœur de ce projet. Sans ces dernières le déploiement d une telle infrastructure n a que peu d intérêt. Or, il existe à ce jour peu d applications qui supportent IPv6 [2]. L'ensemble de ces points doit être validé même en cas de grande mobilité, c'est-à-dire en assurant la continuité de service et de sécurité lors des changements de points d'accès dans les différents sous-réseaux IP. Aussi le protocole Mobile IPv6 a été choisi pour offrir aux applications et aux utilisateurs une gestion transparente du déplacement entre sous réseaux. III. Déploiement du réseau sans fil et choix techniques La première phase de ce déploiement à consisté à installer 11 points d accès sans fil afin de couvrir un premier bâtiment. Les différents points d accès sans fil sont séparés en trois sousréseaux. Les équipements de routage réalisent du routage IPv6 RIPng. Le routage IPv4 n a été configuré que pour l administration des points d accès sans fil qui ne disposent que d une pile IPv4. Ce même routage a aussi été nécessaire pour l utilisation du protocole 802.1X [3] qui nécessite des envois de messages, au dessus du protocole IPv4, entre le serveur radius et les points d accès. Les clients du réseau sans fil sont soit des ordinateurs portables, soit des assistants personnels numériques. L ensemble des clients utilisent le système d exploitation Linux avec le support des protocoles IPv6 et Mobile IPv6. La pile IPv4 sur les clients est désactivée.

3 Parallèlement aux points d accès sans fil un certain nombre de services réseau ont été mis en place : Un serveur DNS IPv6 : il est difficilement envisageable de déployer un réseau IPv6 sans DNS. En effet, la longueur des adresses IPv6 rend leur saisie particulièrement ardue. Aussi un DNS IPv6 fut installé. Ce DNS supporte l interrogation de sa base en IPv6 natif, ce qui est indispensable pour le support de la mobilité IPv6. Un serveur d authentification : comme nous le mentionnons précédemment, le déploiement d un réseau sans fil sur le campus universitaire strasbourgeois devait s accompagner de mesures de sécurité appropriées. La solution retenue a l heure actuelle fut la mise en place de l architecture reposant sur le standard IEEE 802.1X. Toutefois, la mise en place d une telle architecture nous a obligé à déployer un routage IPv4. Celui-ci est invisible pour les clients et non routé sur l Internet mais il était obligatoire de le mettre en place pour les échanges de messages d authentification entre les points d accès et le serveur Radius. En effet, ni le serveur Radius ni les point d accès sans fil ne supportent le protocole IPv6 à l heure actuelle. IV. La sécurité L architecture de sécurité retenue repose principalement sur une sécurisation des communications de niveau 2. En effet, les spécifications de la mobilité IPv6 ainsi que les implémentations existantes ne nous ont pas permis pour l instant de mettre en place une sécurité de niveau 3 basée par exemple sur IPSec [4]. Mais comme nous allons le montrer les techniques actuelles de sécurisation des connexions sans fil offrent déjà un certain nombre de réponses. Notre architecture de sécurité repose donc sur l utilisation d une version propriétaire de 802.1X. Cette architecture permet d une part d authentifier les utilisateurs et donc de s assurer de leurs droits «d entrée sur le réseau» mais elle permet également d avoir un historique de l utilisation du réseau sans fil. Nous pouvons donc savoir en temps réel qui est connecté au réseau sans fil. L architecture retenue repose également sur le cryptage des trames b [5]. Ce cryptage repose sur le protocole WEP avec des clés d encryption de 128 bits. Ces clés d encryption ne sont pas à positionner manuellement sur chacun des postes clients mais téléchargées par le point d accès sur les cartes des clients connectés. Enfin, parmi les autres points de sécurité mis en place, nous avons interdit depuis les points d accès le «broadcast» du SSID. En effet, cette fonctionnalité permet notamment à certains systèmes d exploitation d offrir à leurs utilisateurs la liste des réseaux sans fil disponibles sans que ces utilisateurs n aient besoin de connaître leur nom. Certes, il s agit là, d un petit moyen de sécurisation. Mais la combinaison des différents choix énumérés précédemment (interdiction du broadcast des SSID, clés WEP sur 128 bits, authentification 802.1X) nous permet déjà d offrir un niveau de sécurité acceptable.

4 V. Les applications Comme nous le mentionnons précédemment, les applications sont le cœur de ce projet. Un certain nombre d application ont été installées ou portées en IPv6 dans le cadre de cette expérimentation : Un proxy http, ftp : la consultation de serveurs Web en IPv6 se fait de manière native mais ces derniers ne sont pas encore nombreux et les serveurs habituellement consultés par la communauté étudiante ne supportent pas encore IPv6. La mise en place d un proxy hébergé sur un serveur double pile permet de consulter des serveurs IPv4 alors que les clients ne disposent que d une connectivité IPv6. Un serveur de vidéo à la demande : ce service fut rempli par le logiciel VideoLAN développé à l école centrale de Paris. Ce dernier ne supportait pas à l époque le protocole IPv6, aussi un portage a été réalisé. Une messagerie instantanée : ce service rencontre un grand succès, notamment dans le communauté étudiante, on peut le comparer aux SMS des réseaux de téléphonie mobile. Aussi le portage en IPv6 du serveur Jabber fut réalisé. Une radio en ligne : la diffusion de musique en ligne est également un service de plus en plus utilisé. Aussi, nous avons décidé de mettre en place une architecture permettant de diffuser en ligne et sans interruption une liste de chansons présélectionnées. Le format de transmission est le format MP3. Un jeu : afin de compléter la liste des services mis à la disposition des utilisateurs du réseau sans fil, un jeu fonctionnant en mode client/serveur fut également installé. A l issue de ces portages et installation de serveurs d applications, le réseau sans fil IPv6 était opérationnel. Nous avons pu alors mener à bien un certain nombre d expérimentations. VI. Tests et Mesures L un des objectifs de ce projet est de valider l ensemble des composants déployés. A savoir l utilisation de l architecture de sécurité retenue, mais également la possibilité d utiliser l ensemble de l offre logicielle en situation de mobilité et notamment en mobilité IPv6. Pour ce faire, nous avons réalisé un certain nombre de tests pour valider ces différents concepts. VI.1Méthode de calcul des temps de handovers Avant de détailler les tests il convient de présenter certaines spécificités des réseaux de type b. Lorsqu un mobile utilise une interface sans fil IEEE b, il mesure en permanence la qualité du signal reçu par le point d accès. Lorsque ce signal devient trop faible, il commence à envoyer des messages du type «Probe Request». Lorsqu un point d accès

5 reçoit ce type de message, il répond par un message : «Probe Response». Si le mobile constate que le signal venant du nouveau point d accès est meilleur, il entame alors le handover. Pour cela, il effectue un échange de messages avec le point d accès. Lorsque ce dernier envoie un message du type «Association/Reassociation Response», le portable est connecté au nouveau point d accès. Ceci termine le handover de niveau 2 (niveau de la couche liaison dans le modèle OSI). C est à ce moment que le protocole de mobilité IPv6 entre en jeu. Arès avoir reçu un «Routeur Advertissement» [6], l équipement mobile envoie un message du type «Binding Update» au Home Agent pour lui signaler qu il a changé de réseau. Le Home Agent répond à ce message par un «BUAck» pour signaler au portable que le message précédent est bien arrivé et a été accepté. Le handover de niveau 3 est terminé. Agent Mère Nouveau Routeur d Accès Nouveau Point d Accès Mobile Active scanning Probe Request Probe Response Passive scanning Probe Request Beacon Authentication Handover Niveau 2 Authentication Association Request Association Response Timeout? Handover Niveau 3 Router Solicitation Router Advertisement Détection du nouveau lien DAD sur l adresse lien local Binding Update Nouvelle adresse temporaire Binding Acknowledge Figure 1 : Messages pris en compte dans le calcul du temps de handover de niveau 2 et 3

6 Maintenant que nous connaissons les différentes étapes du handover, nous pouvons en déduire une méthode pour calculer le temps de celui-ci. Il est sage de penser que le handover débute à partir du moment où le premier message du type «Probe Request» est envoyé par le portable. En effet, comme nous l avons vu précédemment, c est à partir de cet instant que l ordinateur souhaite changer de point d accès, et part ainsi à la recherche d un nouveau. Il y a deux types de handover : le handover de niveau 2 et celui de niveau 3. Le handover de niveau 2 est le laps de temps qui sépare le premier message de type «Probe Request» du message «Association/Reassociation Response». Quant au handover de niveau 3 c est la différence de temps entre, le premier message de type «Probe Request» et le message de type «BUAck». Grâce à ces messages nous sommes maintenant capable de calculer les temps de handoff. La figure 1 retrace les échanges de messages et leurs chronologies afin de mieux comprendre les messages pris en compte dans le calcul des handovers de niveau 2 et 3. VI.1 La sécurité Notre première série de test a consisté à déterminer si la mise en place des mécanismes de sécurité était coûteuse dans le cadre des handovers entre points d accès. Nous avons donc effectué une série de tests sans aucune sécurité puis dans les mêmes conditions nous avons activé le cryptage WEP puis dans une troisième série mis en place 802.1X, c est à dire l authentification et le cryptage simultanément. Les résultats de ces trois mesures sont donnés dans la figure 2. 0,33 0,32 Sans sécurité WEP bits 802.1X 0,31 Temps en secondes 0,3 0,29 0,28 0,27 0,26 Figure 2 : Impact de le sécurité sur les handovers de niveau 2

7 Ces premiers tests nous permettent de constater que l utilisation de WEP entraîne une pénalisation dans le temps de handover de 7%, l activation de 802.1X entraîne quant à lui un délai de 11% par rapport à un handover sans aucun niveau de sécurité. V1.2 Trafic MP3 Une autre série de tests a consisté à mener une campagne de mesures lorsque les utilisateurs réceptionnent un trafic de type MP3. Ce service est notamment disponible sur le réseau sans fil à travers une radio qui diffuse de la musique en continu. VI.3 Trafic MP3 sur 1 mobile 2,5 Handover L2 Handover L3 2 Temps en secondes 1,5 1 0, ,5 11 Débits en MBits/s Figure 3 : Mesures des temps de handovers de niveau 2 et 3 avec du trafic MP3 sur 1 mobile

8 Ce test consistait à avoir 6 stations «fixes» associées sur le point d accès sur lequel se trouvait le mobile et 6 stations «fixes» associées au point d accès sur lequel le mobile allait se rattacher après un déplacement. Ces stations ne généraient pas de trafic autre qu un trafic de contrôle. Les tests ont été mené pour un flux MPEG3 générant un trafic de 128 Kbits/sec à destination du mobile. Les tests ont été effectués pour des débits offerts par les points d accès à 1, 2, 5,5 et 11 Mbits/s (cf. Figure 3). Ces résultats nous montrent d une part que le handover de niveau 2 est relativement stable et dure en moyenne 320 msec. Par contre, ce qui peut paraître plus surprenant est le temps du handover de niveau 3 qui est relativement «long» (en moyenne 1,653 sec) mais qui peut s expliquer par la fréquence des Router Advertissement des routeurs IPv6. Ces derniers étant envoyés toutes les secondes, comme le propose les spécifications de la mobilité IPv6. 3,5 3 L2HO - 1 M obile L3HO - 1 M obile 2,5 L2HO - 2 M obiles L3HO - 2 M obiles Temps en secondes 2 1,5 L2HO - 3 M obiles L3HO - 3 M obiles L2HO - 4 M obiles L3HO - 4 M obiles 1 L2HO - 5 M obiles L3HO - 5 M obiles 0,5 L2HO - 6 M obiles L3HO - 6 M obiles ,5 11 Débits en Mbits/s Figure 4 : Mesures des temps de handovers de niveau 2 et 3 avec du trafic MP3 sur 6 mobiles

9 A ce stade il nous paraissait intéressant d évaluer les temps de handover lorsque plusieurs mobiles changent simultanément de points d accès. Nous avons donc reproduit ces tests à tous les débits pour 1 à 6 mobiles (cf. Figure 4). On peut remarquer qu à partir de 4 mobiles les tests avec un débit de 1 Mbps ont été stoppés. En effet 4*128 Kbits/sec = 512 Kbits/sec et il s est avéré que la radio devenait inaudible. Le même problème s est reproduit avec un débit de 2 Mbits/sec et 6 stations mobiles qui se déplacent. 6 x 128 Kbits/sec = 768 Kbits/sec. Sur le graphique précédent (Figure 4) nous récapitulons les temps de handover de niveau 2 et niveau 3 pour tous les débits et pour 1 à 6 mobiles en déplacement recevant chacun un flux MP3. Ces résultats nous montrent que le handover de niveau 2 est relativement constant est dure généralement 300 msec. Le handover de niveau 3 est en moyenne assez constant (autour de 2 secondes). Deux conclusions importantes sont à tirer de cette série de tests, d une part si le trafic ne sature pas la bande passant disponible alors la durée des handovers est constante et d autre part, Mobile IPv6 n offre pas encore suffisamment de fonctionnalités pour supporter des déplacements rapides, sans micro-coupures. VI.4 VidéoIPv6 à la demande Les tests réalisés précédemment nous apportent déjà un certain nombre de réponses. Mais nous avons décidé de réaliser également une série de mesures en utilisant le logiciel de vidéo IPv6 à la demande. Ce dernier supporte l envoi de flux IPv6 au format MPEG2, nos mesures ont montrées que les différentes séquences vidéos transmises génèrent un débit de 3 Mbits/sec par client en unicast. Nous avons effectué des tests de mobilité IPv6 de 1 à 4 mobiles (cf. Figure 5) et pour les différents débits supportés en fonction du nombre de clients. La figure 5 montre les résultats des handovers de niveau 2 et 3 avec de tels flux. Les résultats obtenus sont assez intéressants puisqu ils montrent que le handover de niveau 2 est toujours stable autour de 300 msecs, ce qui n est pas le cas du handover de niveau 3. Ce résultat a une explication, lorsqu un trafic sature le réseau sans fil, les pertes de paquets sont nombreuses et cela retarde fortement les enregistrements de niveau 3. De plus, le trafic de contrôle de niveau a plus rapidement accès au médium que le trafic de données. En effet même si les trames de contrôle sont échangées sur le même canal que les trames de données, elles ont un accès prioritaire par rapport à ces dernières.

10 8 Temps en secondes L2HO - 1 Mobile L3HO - 1 Mobile L2HO - 2 L3HO - 2 L2HO - 3 L3HO - 3 L2HO - 4 L3HO ,5 11 Débits en Mbits/s Figure 5 : Mesures des temps de handovers de niveau 2 et 3 avec du trafic MPEG2 sur 6 mobiles VII. Conclusion La conclusion principale de ce projet est la démonstration réussie en grandeur réelle de l utilisation conjointe des WLANs, d IPv6 et de Mobile IPv6. En effet, nous avons pu démontrer que nous ne sommes plus très loin d avoir des fonctionnalités complètes proches d un produit grand public. Bien sûr un certain nombre de problèmes ont été identifiés comme la sécurité qui repose sur une solution propriétaire pour le niveau 2 et n'est pas résolue pour le niveau de la mobilité IPv6, ainsi que des micro-coupures lors des handovers soit de niveau 2 soit de niveau 3. Concernant la sécurité de la mobilité IPv6, l IETF travaille activement pour proposer une solution, bien que celle-ci ne rencontre pas l unanimité des experts en la matière. Pour le niveau 2 les améliorations en termes d'authentification et cryptage considérées dans le groupe de travail i de l'ieee devraient également permettre à terme de se reposer sur une solution normalisée. Concernant les micros coupures des propositions sont également faites à l IETF.

11 Enfin, un des enseignements de cette première étude est la nécessité de modifier certaines applications pour les rendre moins sujettes aux déplacements de l utilisateur. On peut définir trois types d applications: les applications faiblement interactives (consultation mail, Web, transfert de fichiers, messagerie instantanée), les applications "quasi" temps réel (streaming audio et vidéo), et les applications temps réel (visio et audio conférence). Les applications faiblement interactives ne sont pratiquement pas pénalisées par les déplacements et la mise en place des mécanismes de mobilité de niveau 2 et 3. Les applications temps réel ont elles besoin de nouveaux protocoles pour minimiser les temps de handovers (i.e. bi-casting [7], FMIPv6 [8], ). Par contre les applications de streaming pourraient êtres simplement modifiées pour mieux prendre en compte le concept du terminal Mobile IPv6. En effet, la plupart des ces applications proposent un mécanisme de bufferisation, toutefois celui-ci n est pas suffisamment étendu pour rendre transparent les handovers des terminaux. Il serait donc nécessaire de mieux gérer ces buffers pour masquer ces désagréments aux utilisateurs. Pour finir, ce projet a ouvert de nouvelles voies d expérimentation, comme l utilisation de logiciels de «VoIPv6 over WLAN», mais également l étude du comportement des usagers des WLANs, afin de déterminer leur manière d utiliser ces nouvelles technologies. Sont-ils fortement mobiles ou pas, cela dépend-t-il du type d équipements qu ils utilisent, des logiciels à leur disposition?. Références [1] David B. Johnson, C. Perkins, Jari Arkko, Mobility Support in IPv6, Internet Draft, Work in Progress, Novembre [2] S. Deering, R. Hinden, Internet Protocol Version 6 (IPv6) Specification, RFC 2460, Dec [3] IEEE Draft 802.1X, Standard for Port based Network Access Control, March [4] S. Kent, R. Atkinson, Security Architecture for the Internet Protocol, RFC 2401, November [5] IEEE b, Part 11 : Wireless Medium Access Control (MAC) and Physical Layer (PHY) specifications, IEEE Std b 1999 [6] Thomson, S., Narten, T., IPv6 Stateless Address Autoconfiguration, Internet Engineering Task Force (IETF) Request for Comments 2462, December [7] K. El Malki, H. Soliman, Simultaneous Bindings for Mobile IPv6 Fast Handoffs, Internet Draft, Work in Progress, June [8] Dommety, G., Yegin, A., Perkins, C., Tsirtsis, G., El-Malki, K., Khalil, M. Fast Handovers for Mobile IPv6. Internet Engineering Task Force (IETF) draft-ietf-mobileip-fast-mipv6-02.txt. July 2001