Université de Technologie de Compiègne Automne 2003, 7 janvier VPN et Multicast. SR04, Réseaux. Yoann Hinard Benjamin Lorentz

Transcription

1 Université de Technologie de Compiègne Automne 2003, 7 janvier 2004 VPN et Multicast SR04, Réseaux Yoann Hinard Benjamin Lorentz

2 VPN et Multicast Benjamin Lorentz Yoann Hinard Automne 2003 Table des matières 1 Introduction 2 2 Présentation Qu est ce que le VPN? Raisons du développement Technologies mises en œuvre Fonctionnement, protocoles PPTP L2F L2TP IPSec Autres protocoles Extension multicast Protocole multicast PIM Généralités Scénario Solution de l IETF Principe Mise en œuvre Problèmes rencontrés Conclusion 15 Liste des figures 16 Références 17 1

3 1 INTRODUCTION 2 1 Introduction Dans ce document, nous allons présenter les VPN ainsi qu une extension multicast proposée par Cisco Systems. Nous présenterons d abord la genèse et les principes de cette technologie. Nous verrons ensuite un peu plus en détail les protocoles mis en œuvre. Afin d introduire le multicast nous verrons l algorithme PIM de construction d arbre multicast nécessaire au support proposé par Cisco, puis son utilisation dans le cadre des réseaux privés virtuels. 2 Présentation 2.1 Qu est ce que le VPN? Afin d introduire les VPN (Virtual Private Network 1 ) nous allons commencer par la définition standard de l IETF. Un VPN est : An emulation of a private Wide Area Network (WAN) using shared or public IP facilities, such as the Internet or private IP backbones. En d autres termes, nous pouvons dire qu un VPN est l extension d un intranet privé à travers un réseau public (tel qu Internet). Il offre une sécurité et une mise en œuvre simple grace aux tunnels sécurisés qui permettent d échanger les données de la même manière qu avec une connexion point à point. 2.2 Raisons du développement Historiquement les réseaux privés et public ont longtemps été séparés. Les entreprises avaient pour habitude de se séparer des autres utilisateurs du réseau public en combinant d importantes sécurités et filtres rendant impossible l accès à leurs ressources depuis l extérieur. Cela a conduit à séparer les différents sites d une entreprise. Le seul moyen pour les relier de nouveau de manière sécurisée consistait à louer une ligne dédiée. Les principaux problèmes de cette solution sont son coût élevé, l utilisation sporadique d un média, l impossibilité pour des membres en déplacement d accéder au réseau. La solution des VPN permettant d utiliser les canaux non sécurisés d un réseau public pour étendre la portée du réseau de l entreprise s est alors natu- 1 Le terme français Réseau Privé Virtuel est peu utilisé dans la littérature

4 2 PRÉSENTATION 3 Fig. 1 Schéma typique d un VPN rellement imposée. Le principe global est d encapsuler les données cryptées dans un paquet IP. 2.3 Technologies mises en œuvre La sécurité des VPN repose sur la combinaison des mécanismes suivants : Chiffrement : Le principe du chiffrement est de modifier les données contenues dans un message afin qu elles ne puissent être lues que par le destinataire. L algorithme est généralement connu de tout le monde, une clé est nécessaire pour décrypter les données. Le VPN repose sur l utilisation des clés privées / clés publiques. La clé privée est connue seulement de son possesseur, la clé publique est rendue disponible. Un message chiffré avec la clé publique ne peut être décrypté qu avec la clé privée lui correspondant et inversement. Authentification : Permet de s assurer que les données sont lues par le bon destinataire et qu elles arrivent intègres (non modifiées depuis l émission). De manière simple un système d authentification est constitué d un couple login / mot de passe, ou peut mettre en œuvre un chiffrement à base de clé publique / clé privée.

5 3 FONCTIONNEMENT, PROTOCOLES 4 Autorisation : Gestion des accès aux ressources du réseau après authentification de l utilisateur. L outil fondamental à la mise en place est le tunneling. Il consiste à chiffrer les données entrantes et les envoyer sur un réseau non sécurisé (Figure 1). L application gère ce type de connexion de la même manière qu une connexion point à point. Il se comporte comme on pourrait l imaginer, on entre les données d un côté, elles ressortent de l autre et personne ne peut les voir ou les modifier pendant le transport. Il existe principalement quatre protocoles de tunneling : IP Security (IPSec) : Développé par l IETF, IPSec est un standard libre se situant au niveau 3 du modele OSI. Point-to-Point Tunneling Protocol (PPTP) : Développé en commun par Microsoft et 3COM il était inclus dans les versions NT4 et 98 de Windows, il a donc été massivement distribué. Layer 2 Forwarding (L2F) : Développé par Cisco Systems il reprend le principe du PPTP de Microsoft. Layer 2 tunneling Protocol (L2TP) : Développé par l IETF à partir des protocoles PPTP et L2F proposés comme standards. 3 Fonctionnement, protocoles Dans cette partie nous allons voir les protocoles qui permettent le tunneling. Ils sont fondamentaux pour construire un VPN et sécuriser les transmissions. La plupart de ceux-ci sont situés sur la deuxième couche du modèle OSI. Le protocole IPSec est par contre implémenté sur la couche trois. 3.1 PPTP Le protocole PPTP (Point-to-Point Tunneling Protocol) a été développé principalement par Microsoft à partir du protocole PPP. Il se situe sur la couche liaison (2) du modèle OSI. L utilisateur doit se connecter à travers un réseau public au serveur RAS (Remote Acces Service) de son réseau local. Le protocole PPTP simule la présence de l utilisateur dans le réseau local en transmettant les paquets par le tunnel ouvert. La transmission est effectuée après le cryptage du paquet initial avec le protocole PPP qui est un standard. Les paquets PPP sont encapsulés dans un paquet de tranport (obligatoirement IP). Nous voyons sur la Figure 2 que le paquet initial (PPP Payload) qui va être encapsulé peut contenir n importe quel type de données (il peut être un paquet IP, IPX, Netbios,...).

6 3 FONCTIONNEMENT, PROTOCOLES 5 L en-tête GRE (Generic Routing Encapsulation) permet de préciser le type de paquet encapsulé (ici PPP). Fig. 2 Format d un paquet PPTP Les type de cryptage utilisé dans PPTP n est pas figé. Par défaut, sont inclus dans Windows 98/NT PAP (Password Authentication Protocol) et CHAP (Challenge Handshaking Authentication Protocol). Via l utilisation de PAP les identifiants / mots de passe sont transférés en clair sur le lien. Lorsque CHAP est utilisé, le serveur RAS tire un nombre aléatoire, il le chiffre avec la clé publique du client et lui envoi, celui-ci doit alors le décrypter avec sa clé privée et renvoyer son propre mot de passe crypté avec ce nombre. Cette méthode empêche la réutilisation de paquets d authentification interceptés. Fig. 3 Communication avec un ISP supportant ou non PPTP

7 3 FONCTIONNEMENT, PROTOCOLES 6 La connexion PPTP s effectue dans de bonnes conditions lorsque l ISP (Internet Service Provider) supporte le protocole PPTP. Dans le cas contraire (Figure 3) la communication PPTP s effectue directement entre le client et le serveur RAS. Cela necessite l encapsulation complète des paquets PPTP du client dans ses propres paquets PPP (via une encapsulation dans IP) ce qui réduit fortement la quantité utile de données qui transitent sur le lien entre le client et son ISP. 3.2 L2F L2F a été développé par Cisco Systems comme une alternative au protocole PPTP. Comme ce dernier il s appuie sur la couche deux du modèle OSI. Il est par contre beaucoup plus souple sur les protocoles réseaux utilisés. En effet, PPTP ne peut être encapsulé que dans des paquets IP alors que L2F peut aussi être encapsulé dans du X25 par exemple. Comme pour PPTP L2F permet l utilisation de différentes méthodes d authentification. L authentification L2F est différente de celle de PPTP qui nécessite juste l autorisation du RAS du LAN sur lequel on se connecte. En effet, l authentification L2F nécessite l approbation préalable du serveur RAS du provider. Fig. 4 Communication L2F La figure 4 montre l établissement d une connexion VPN L2F, voici la description des différentes actions : 1. L utilisateur initialise la connexion avec le RAS du provider (protocole PPP). Le RAS commence le processus d authentification (CHAP, PAP ou autre).

8 3 FONCTIONNEMENT, PROTOCOLES 7 2. Le RAS du provider interroge la base de données afin de savoir s il faut ouvrir un canal virtuel ou en utiliser un existant. 3. Création d un canal sécurisé entre le provider et le LAN. 4. Authentification par le RAS du LAN 5. Si l authentification a été acceptée, le RAS du LAN informe le RAS du provider de la validité (protocole PPP) 6. Stockage dans la base de données des informations concernant l état du VPN (canaux ouverts, utilisateurs en cours) 7. Transfert entre l utilisateur et le LAN (encapsulation sécurisée). 3.3 L2TP Le protocole PPTP fut soumis à l IETF comme candidat à un protocole standard. Il a reçu le statut project at the Internet standard cependant, malgré sa large distribution (notamment avec son intégration à windows 98 et NT4) le standard n a jamais été accepté. Actuellement, l IETF pense adopter L2TP comme standard. Il intègre les meilleures caractéristiques de L2F et PPTP. Il est distribué par Cisco Systems. L2TP comprend en plus un contrôle de flux qui était absent dans L2F. Le chiffrement de L2TP n est pas figé comme pour L2F et PPTP mais il est recommandé de l utiliser avec IPSec protocole de niveau trois (Section 3.4) ce qui était impossible avec PPTP. Le principe est d utiliser IPSec en mode transport pour chiffrer les données (Figure 6) puis d utiliser le paquet de sortie pour l encapsuler avec L2TP (paquet PPP Payload Figure 2). Fig. 5 Communication L2TP La communication L2TP (Figure 5) s effectue en plusieurs étapes. Le client contacte le concentrateur L2TP du réseau public en utilisant PPTP. Le concentrateur L2TP du provider determine l adresse IP du serveur L2TP du LAN. Il ouvre ensuite une communication L2TP avec et se charge de transférer les paquets en provenance du client.

9 3 FONCTIONNEMENT, PROTOCOLES 8 Malgré tous ces avantages, L2TP n élimine pas tous les problèmes. Il faut toujours que le provider supporte la technologie. Ce protocole limite l accès de l utilisateur au LAN de l netreprise (aucune connexion a Internet en même temps). 3.4 IPSec Contrairement aux protocoles précédents, IPSec se situe sur la couche trois du modèle OSI. Il peut être utilisé dans deux modes différents. Le mode transport (figure 6) l intègre à la pile IP (l en-tête IP est conservée) alors que le mode tunnel (figure 7) fonctionne de manière analogue aux protocoles précedemment vus, il crypte l intégralité du paquet IP à transférer puis l encapsule dans un paquet nouvellement créé. Ce protocole sera inclus dans la nouvelle version du protocole IP (IPv6). Fig. 6 IPSec en mode transport Nous pouvons voir sur la Figure 6 que le protocole IPSec en mode transport s intègre parfaitement dans la pile IP. En effet, l en-tête n est pas modifiée seules les données sont cryptées. Cela permet de ne pas effectuer d aller-retours dans la pile (comme les protocoles de niveau deux qui sont ensuite réencapsulés dans des paquets IP). Il n y a pas besoin de support particulier du coté provider puisque les paquets transportés sont des paquets IP standards. L en-tête AH (Authentication Header) assure l intégrité des paquets, l authentification de la source et la protection contre la duplication des paquets. Le degré de protection dépend du mode choisi. En effet, tous les champs de l en-tête IP sont cryptés lors de l utilisation en mode tunnel (Figure 7). Le protocole ESP (Encapsulating Security Payload) procure plus de fonctions de sécurité que le protocole AH. Généralement on l utilise pour le cryptage des paquets IP mais il peut servir à l authentification, la protection contre la corruption et duplication.

10 4 EXTENSION MULTICAST 9 Fig. 7 IPSec en mode tunnel 3.5 Autres protocoles Il existe aussi des protocoles au niveau session (SSL, SOCKS). Le problème principal de ce type de protocoles est la dépendance directe des applications. En effet, plus le protocole se situe a un niveau élevé, plus les applications risquent de devoir l interfacer directement. 4 Extension multicast Nous allons présenter l extension multicast au VPN présenté dans un draft de l IETF (Référence :[5]). Dans ce draft, le prérequis à l installation d un VPN multicast est la présence de PIM (Protocol Independent Multicast). Nous allons donc commencer par présenter ce protocole puis nous parlerons d une solution proposée par Cisco. 4.1 Protocole multicast PIM PIM est un protocole de routage multicast indépendant du protocole unicast mis en place. Le principe de ce type de protocole est de construire un arbre optimal (dépend de la métrique choisie) afin de diffuser les messages multicast à tous les destinataires inscrits. PIM peut s utiliser en deux modes, le mode DM (Dense Mode) qui consiste à diffuser un message initial puis élaguer les liens inutiles. Le mode SM (Sparse Mode) est le seul utilisable sur un réseau de grande taille comme Internet (diffusion inenvisageable). C est ce mode qui est utilisé lors de communications VPN multicast.

11 4 EXTENSION MULTICAST Généralités Le protocole PIM base ses communications sur un serveur de rendez-vous (DR). Il est chargé de gérer les enregistrements des sources et destinataires. Des messages particuliers (prune 2 ) sont chargés de transmettre les informations destinées à rompre un lien. Il existe deux types d arbres lors de l utilisation de PIM. Les arbres dont la racine est la source du message et les arbres dont la racine est le serveur de rendez-vous. Les messages d informations sur le lien sont de la forme (*,G) si la racine est le DR et (S,G) si la racine est la source Scénario Les graphiques utilisés dans cette partie sont tirés du document [9]. Figure 8 : le client envoie une demande d enregistrement au serveur en envoyant un message join (*,G). Le routeur C crée l état (*,G) pour l interface allant au destinataire. Le serveur créé l état (*,G) et met un lien vers le routeur C. Figure 9 : la source envoie des données (adresse multicast), le routeur A les encapsule en unicast et envoie ce paquet (de type register)vers le serveur. Le serveur crée l état (S,G) et envoie les données sur l arbre partagé (de type (*,G)). Il envoie une demande join vers la source afin de créer un chemin (S,G) sur A et B. Quand les données arrivent correctement en multicast, le serveur envoie une demande d arrêt d encapsulation (register stop) au routeur A. Figure 10 : le routeur C cherche un chemin plus court vers la source, pour cela il envoie un message de type join vers la source (unicast). Lorsqu il reçoit le message de type (S,G) de la source, il envoie une demande de rupture de lien (prune) au serveur de rendez-vous. Celui-ci n ayant plus d autre liens ouverts détruit le chemin vers la source. Figure 11 : Le client 2 veut s enregistrer. E crée l état de type (*,G) et envoie le message join vers le serveur. C intercerpte cette demande et lui envoie une réponse de type (S,G) et (*,G). Ensuite, il privilégiera le lien (S,G). 2 Elaguer

12 4 EXTENSION MULTICAST 11 Fig. 8 PIM : Enregistrement d un destinataire sur le serveur de rendez-vous Fig. 9 PIM : Enregistrement de la source sur le serveur de rendez-vous

13 4 EXTENSION MULTICAST 12 Fig. 10 PIM : Recherche d un chemin plus court Fig. 11 PIM : Enregistrement d un deuxième destinataire

14 4 EXTENSION MULTICAST Solution de l IETF Afin de supporter le VPN multicast défini dans le draft (Ref [5]) et par Cisco System (Ref [6]), le réseau public doit supporter le protocole de routage multicast PIM Principe Le principe global est de relier entre-eux différents réseaux privés. Ces réseaux privés sont reliés au réseau public par l intermédiaire de PE (Provider Edge). La diffusion multicast d un réseau privé doit pouvoir être reçue de manière transparente par un utilisateur faisant partie d un autre réseau privé. Un arbre multicast classique est ouvert (sur le réseau public) pour chaque VPN mis en œuvre (Figure 12). On utilise le principe du tunneling GRE (voir section 3.1) pour transférer les paquets multicast entre les différents PE. Il peut y avoir plusieurs arbres multicast privés transportés par un arbre public. Les routeurs publics n ont donc à maintenir qu un seul couple (*,G) (S,G) (section 4.1.1) par arbre public. Nous pouvons noter que les PE sont à la fois feuilles et racines (source et destinataires) des arbre publics. Fig. 12 Schéma d un VPN multicast Mise en œuvre Chaque PE lance autant d instance de PIM que de VRF 3 (VPN Routing and Forwarding) qu il possède (Figure 13). Les paquets sont encapsulés par le PE au moment d arriver sur le réseau 3 Table de routage spécifique aux VPN

15 4 EXTENSION MULTICAST 14 Fig. 13 MVPN : Instances de PIM public. Il sont ensuite transférés par le protocole classique de routage multicast jusqu aux différents PE s étant enregistrés pour ce VPN. Nous pouvons d ailleurs remarquer que les paquets de multicast arrivent jusqu au PE d un réseau privé même si aucun de ses membres ne s est enregistré pour cette diffusion. Il en résulte une perte de rendement, surtout si les données transférés sont très consommatrices de bande-passante. Afin de ne plus envoyer de données inutiles à tous les membres de l arbre multicast par défaut (arbre du réseau public avec pour membres les PE), l idée proposée est d ouvrir un nouvel arbre (Data Multicast Distribution Tree) destiné à transporter les données volumineuses (Figure 14). Ce canal reste un arbre multicast mais est ouvert seulement vers les PE dont des membres désirent cette diffusion. A ce moment, il y a donc plusieurs arbres qui cohabitent, les arbres de données sont forcément des sous-arbres de l arbre par défaut. Fig. 14 MVPN : Ouverture d un canal de données

16 5 CONCLUSION Problèmes rencontrés D après cette proposition d implémentation, il est nécessaire d avoir accès à un provider supportant l instanciation multiple de PIM. Cela peut être assez facile si le but est de relier différents pôles d une entreprise mais beaucoup plus difficile pour des utilisateurs itinérants. Le trafic envoyé vers les PE n est pas forcément utile. Il est possible d ouvrir des canaux spéciaux pour les flux de données importants mais les pertes restent existantes pour de faibles transferts. Une solution proposée consiste à multiplier les arbres mais la maintenance des tables de routage publiques serait beaucoup plus coûteuse. Ce type d implémentation n est pas encore disponible. La version d octobre 2003 d IOS (système d exploitation des routeurs Cisco) ne pouvait gérer qu un seul domaine multicast par réseau virtuel (par mvrf). 5 Conclusion Nous avons vu l utilité et le fonctionnement des VPN. Son extension multicast demeure malgré tout au stade expérimental et peu de solutions sont proposées dans cette voie. Les drafts disponibles sur l IETF [5, 7, 8] sont difficilement accessibles aux non-spécialistes. D une part à cause des très nombreuses abréviations inexplicitées et du support texte qui interdit tout graphique. Néanmoins, cette technologie semble très prometteuse en raison de la sécurité qu elle fournit à un faible coût (comparé à la location de lignes dédiées). De plus la mobilité croissante dans les entreprises augmente grandement le besoin d interconnexion.

17 TABLE DES FIGURES 16 Table des figures 1 Schéma typique d un VPN Format d un paquet PPTP Communication avec un ISP supportant ou non PPTP Communication L2F Communication L2TP IPSec en mode transport IPSec en mode tunnel PIM : Enregistrement d un destinataire sur le serveur de rendezvous PIM : Enregistrement de la source sur le serveur de rendez-vous PIM : Recherche d un chemin plus court PIM : Enregistrement d un deuxième destinataire Schéma d un VPN multicast MVPN : Instances de PIM MVPN : Ouverture d un canal de données

18 RÉFÉRENCES 17 Références [1] Meeta Gupta, Building a Virtual Private Network, Premier Press, [2] A. Moldovyan N. Moldovyan D. Summerville V. Zima, Protected Internet, Intranet, & Virtual Private Network, A-List, [3] C. Scott P. Wolfe M. Erwin, Virtual Private Networks 2nd, O REILLY, [4] E. Rosen Y. Rekhter, RFC 2547 : BGP/MPLS VPNs, IETF, [5] E. Rosen Y. Cai D. Tappan I. Wijnands Y. Rekhter D. Farinacci draftrosen-vpn-mcast-06, IETF, Octobre , 4.2, 5 [6] Yiqun Cai, Multicast VPN Architecture (mvpn), Cisco Systems, Octobre [7] Ananth Nagarajan, draft-ietf-l3vpn-generic-reqts-01, IETF, Août [8] B. Fenner M. Handley H. Holbrook I. Kouvelas, draft-ietf-pim-sm-v2-new- 08, IETF, Octobre [9] B. Rapacchi B. Tuy, Protocoles de routage multicast, http ://