Tutorial VPN. Principales abréviations

Tutorial VPN Ecole d ingénieurs du Canton de Vaud Institut de Télécommunications Tutorial sur les VPN, destiné aux étudiants; rédigé dans le cadre du travail de diplôme. Tutorial VPN Complément au laboratoire sur les VPN Auteur: Christian Tettamanti Principales abréviations

AH CHAP ESP GRE ICV IETF IKE IPSec ISAKMP ISP L2TP MPPE MS-CHAP NAS PAP PPP PPTP SA SPI VPN Authentication Header Challenge Handshake Authentication Protocol Encapsulating Security Payload Internet Generic Routing Encapsulation Integrity Check Value Internet Engineering Task Force Internet Key Exchange IP Security Protocol Internet Security Association and Key Management Protocol Internet Service Provider Layer 2 Tunneling Protocol Microsoft Point-to-Point Encryption Microsoft Challenge Handshake Authentication Protocol Network Access Server Password Authentication Protocol Point-to-Point Protocol Point-to-Point Tunneling Protocol Security Association Security Parameter Index Virtual Private Network Travail de diplôme Tutorial VPN Page 2

1. Table des matières 1. Table des matières...3 2. Introduction...5 3. Définition de VPN (Virtual Private Networks)...5 4. Motivations pour le choix d'une solution VPN...7 4.1 Utilisations communes des VPN...9 4.1.1 Accès à distance à travers Internet (Host to LAN)...9 4.1.2 Connexion entre plusieurs réseaux à travers Internet (LAN to LAN)...9 4.1.3 Réseau privé entre deux ordinateurs (Host to Host)...10 5. Exigences de base des VPN...10 6. Protocoles VPN...11 6.1 Concepts de base sur les tunnels...11 6.1.1 Types de tunnel...12 6.2 PPTP Point-to-Point Tunneling Protocol...12 6.2.1 Préambule...12 6.2.2 PPTP et les VPN...12 6.2.3 Scénario PPTP typique...13 6.2.4 Clients PPTP...14 6.2.5 Serveur d'accès réseau de l'isp...15 6.2.6 Serveur PPTP...15 6.2.7 Architecture PPTP...15 6.2.8 Vue d'ensemble de l'architecture PPTP...15 6.2.9 Connexion de contrôle PPTP...16 6.2.10 Transmission de données PPTP...30 6.2.11 Exemple de connexion...32 6.2.12 La sécurité de PPTP...33 6.2.13 Contrôle d'accès...34 6.2.14 Le chiffrement de données...34 6.2.15 Usage de PPTP avec des firewalls...35 6.3 L2TP Layer 2 Tunneling Protocol...36 6.3.1 Vue d'ensemble du protocole...36 6.3.2 Format de l'entête L2TP...37 6.3.3 Connexion de contrôle L2TP...38 6.4 IPSec IP Security Protocol...39 6.4.1 Architecture de IPSec...39 6.4.2 AH (Authentication Header)...41 6.4.3 ESP (Encapsulating Security Payload)...44 6.4.4 IKE (Internet Key Exchange)...47 7. Conclusions...51 8. Bibliographie...52 8.1 Ouvrages...52 8.2 Articles et documents du web (annexés)...52 8.3 Compléments (annexés)...52 Travail de diplôme Tutorial VPN Page 3

Table des illustrations Figure 1 : Exemple de VPN....6 Figure 2 : Réseau privé virtuel construit sur Internet....7 Figure 3 : Plusieurs communications dans le même média...8 Figure 4 : Communications utilisant chacune un média indépendant...8 Figure 5 : Utilisation d'un VPN pour connecter un client distant à un réseau privé....9 Figure 6 : Connexions LAN to LAN...10 Figure 7 : VPN entre deux hôtes....10 Figure 8 : Tunneling...11 Figure 9 : Tunnel PPTP....13 Figure 10 : Connexion à distance entre un client PPTP et un réseau privé....14 Figure 11 : message de contrôle Start-Control-Connection-Request...17 Figure 12 : message de contrôle Start-Control-Connection-Reply...18 Figure 13 : message de contrôle Stop-Control-Connection-Request...19 Figure 14 : message de contrôle Echo-Request...20 Figure 15 : message de contrôle Echo-Reply...20 Figure 16 : message de contrôle Outgoing-Call-Request...21 Figure 17 : message de contrôle Outgoing-Call-Reply...22 Figure 18 : message de contrôle Incoming-Call-Request...23 Figure 19 : message de contrôle Incoming-Call-Reply...24 Figure 20 : message de contrôle Incoming-Call-Connected...25 Figure 21 : message de contrôle Call-Clear-Request...26 Figure 22 : message de contrôle Call-Disconnect-Notify...27 Figure 23 : message de contrôle WAN-Error-Notify...28 Figure 24 : message de contrôle Set-Link-Info...29 Figure 25 : Datagramme PPTP avec message de contrôle...30 Figure 26 : Datagramme GRE...31 Figure 27 : Encapsulation des données dans GRE dans le cas de PPTP....31 Figure 28 : Exemple d'ouverture, maintient et fermeture d'une connexion PPTP...32 Figure 29 : Processus CHAP...33 Figure 30: Serveur PPTP derrière un firewall....35 Figure 31 : Structure du protocole L2TP...36 Figure 32 : Entête L2TP...37 Figure 33 : Mode transport d'ipsec....40 Figure 34 : Mode tunnel d'ipsec...40 Figure 35 : Entête du protocole AH....41 Figure 36 : AH en mode Transport...42 Figure 37 : AH en mode Tunnel...42 Figure 38 : Entête du protocole ESP....44 Figure 39 : ESP en mode Transport...45 Figure 40 : ESP en mode Tunnel....45 Figure 41 : Entête ISAKMP...47 Figure 42 : Entête générique de ISAKMP...47 Figure 43 : Chaînage possible d'un message ISAKMP....49 Figure 44 : Main mode exchange de IKE....50 Figure 45 : Quick Mode Exchange....51 Travail de diplôme Tutorial VPN Page 4

2. Introduction Ce document est supposé être un complément au laboratoire 'Configuration d'un VPN'. Il explique les bases théoriques pour pouvoir bien comprendre la manipulation pratique. Ceci dit, le tutorial devrait être connu préalablement à la manipulation pratique. 3. Définition de VPN (Virtual Private Networks) Lorsqu on aborde pour la première fois le sujet des réseaux privés virtuels, on s aperçoit que le nombre de définitions d un VPN est très élevé. Ceci dit, il n est pas possible de donner une seule définition. La façon la plus simple de trouver une définition commune pourrait être celle d analyser, individuellement, chaque mot de l acronyme VPN. Ceci permet de regrouper les différentes analyses et donner ainsi une définition correcte de sens commun. La difficulté d'analyse motive le choix de classement suivant: network : private : Ce mot est sans autre le plus facile à analyser et comprendre; sa définition est commune et acceptée par l industrie. Un "réseau" (network) consiste en un nombre de dispositifs pouvant communiquer entre eux à l'aide de méthodes arbitraires. Ces dispositifs peuvent être de nature différente : les ordinateurs, les imprimantes, les routeurs, etc., y sont inclus. Géographiquement, ils peuvent se trouver dans différents sites. Les méthodes avec lesquelles ces dispositifs peuvent communiquer sont très nombreuses, car elles dépendent du niveau d application. Des spécifications pour le niveau physique, liaison, transport et application devront donc être énoncées. En conclusion, un réseau est une collection de dispositifs qui peuvent communiquer entre eux et donc s échanger des données. Le terme "privé" (private) est assez correct et il est lié au concept de virtualisation dans la définition des VPN. La définition la plus simple de "privé" indique que la communication entre deux ou plusieurs dispositifs est secrète. Les dispositifs n'étant pas concernés par la communication de nature privée, ne pourront pas lire le contenu des messages privés. Ceci dit, ils ignorent tout de la relation entre les dispositifs concernés. La confidentialité des données et la sécurité (intégrité) sont des aspects importants dont il faut tenir compte lorsqu'on considère un type particulier d'implémentation VPN. La définition "privé" peut être exprimée à l'aide de la définition de son antonyme "public". Un service public est accessible ouvertement et contrôlé dans les limites et les contraintes d'une ressource publique commune, souvent par l'intermédiaire d'une entité administrative publique. Au contraire, un service privé est accessible uniquement par un groupe d'entités définies. Des tiers ne pourront pas en avoir accès. En général, la ressource privée est gérée par des entités qui ont un droit exclusif d'accès. Des exemples de ce type de réseau privé peuvent être trouvés dans des réseaux d'organisation qui ne sont pas connectés à Internet. Ces réseaux sont privés, car aucune connexion externe, et donc aucune communication de réseau avec l'extérieur, est présente. Un autre aspect important de la confidentialité dans les VPN, est donné à travers son implémentation technique. Laquelle décrit la confidentialité des systèmes d'adressage et de routage. L'adressage, utilisé dans une communauté VPN d'intérêts, est séparé par rapport à celui du réseau partagé et des autres communautés VPN. Le schéma d'adressage et de routage d'un VPN devrait être indépendant de chaque communauté VPN. Travail de diplôme Tutorial VPN Page 5

virtual : Le concept "virtuel" (virtual) est le plus compliqué des trois mots qui composent l'acronyme VPN. Dans le contexte des VPN il pourrait être défini par : simulé, qui exécute des fonctions d'un objet non réel. L'aspect de virtualisation est similaire à la définition de "privé" qu'on vient de décrire, bien que le scénario soit un peu modifié. La communication privée est établie sur une infrastructure de réseau partagée par plus qu'une organisation. De cette façon, la ressource privée est construite en se basant sur un partitionnement logique de la ressource partagé à la place d'utiliser des connexions de circuits physiques. Le réseau privé est une création qui n'a pas de contrepartie physique. La communication virtuelle entre deux ou plusieurs machines est due au fait que les machines qui ne sont pas concernées par la communication n'ont pas la possibilité de percevoir des données. Ceci dit, elles sont incapables de déterminer la relation entre les machines concernées. L'infrastructure du réseau partagé peut être par exemple représentée par le réseau global Internet et un nombre d'organisations utilisant des réseaux virtuels. Ces dernières peuvent être des centaines, des milliers, voir des millions! La combinaison de ces termes produit VPN un réseau privé dont la confidentialité est introduite par des moyens de virtualisation. Un VPN peut être créé entre deux systèmes, entre deux organisations, entre plusieurs systèmes et une organisation ou entre plusieurs organisations répandues dans Internet, soit encore entre des applications individuelles ou une combinaison des ces possibilités. La définition, la plus utilisée, qui caractérise un VPN est la suivante: Un VPN est un environnement de communication dans lequel l'accès est contrôlé, afin de permettre des connections entre une communauté d'intérêts seulement. Un VPN est construit avec un partitionnement d'un média de communication commun qui offre des services de façon non exclusive. Voilà une autre définition, plus simple et approximative: Un VPN est un réseau privé construit sur l'infrastructure d'un réseau public, comme l'est Internet. On peut noter qu'une solution exhaustive de VPN fournit un support pour l'accès via modem, pour l'accès avec des lignes dédiées, et la possibilité de supporter des connexions depuis le réseau global Internet. Figure 1 : Exemple de VPN. Travail de diplôme Tutorial VPN Page 6

On a vu qu'un VPN permet de créer un réseau privé à travers un réseau public comme Internet; voilà un exemple de VPN construit sur Internet: Figure 2 : Réseau privé virtuel construit sur Internet. 4. Motivations pour le choix d'une solution VPN Il y a plusieurs motivations qui induisent à utiliser le VPN, mais le point commun à chaque motivation est celui de vouloir virtualiser une partie des communications d'une organisation. Autrement dit, le besoin d'avoir une partie (ou toutes) des communications, essentiellement invisible de la part d'un observateur externe, tout en préservant les avantages d'une infrastructure commune. La motivation principale pour choisir une solution VPN couvre les aspects économiques des communications. Les systèmes de communications ont aujourd'hui la caractéristique d'avoir un prix constant et élevé avec des petits coûts variables qui changent selon la capacité de transport ou la bande passante du système. Dans cet environnement, il est financièrement plus attractif de réunir un nombre de communications discrètes dans une plate-forme de communication de grande capacité, permettant ainsi l'amortissement des prix élevés des composants par un grand nombre de clients, à la place d'utiliser une ligne dédiée pour chaque communication. Ainsi, une collection de VPN implémentés sur un seul média physique commun, est moins cher qu'une collection équivalente de petits médias discrets, chacun reliant un seul client réseau. Travail de diplôme Tutorial VPN Page 7

Les figures suivantes montrent les concepts énoncés. Figure 3 : Plusieurs communications dans le même média. Figure 4 : Communications utilisant chacune un média indépendant. Une autre motivation concerne la confidentialité des communications. Les caractéristiques et l'intégrité des services de communications isolés diffèrent des autres environnements qui partagent un média commun. Le niveau de confidentialité dépend de la politique de l'organisation. Si le besoin de confidentialité est bas, la simple abstraction de discrétion pourra suffire. Tandis que si le besoin en confidentialité est grand, il y a un fort besoin de sécuriser les accès et les données passant dans le média commun. Travail de diplôme Tutorial VPN Page 8

4.1 Utilisations communes des VPN Cette section décrit brièvement les solutions VPN les plus souvent utilisées. 4.1.1 Accès à distance à travers Internet (Host to LAN) Un VPN permet aux utilisateurs éloignés de se connecter à un réseau privé tout en maintenant la confidentialité. La figure suivante montre un utilisateur VPN connecté à un réseau d'entreprise à travers Internet. Au lieu d'effectuer un appel téléphonique à longue distance à destination de l'entreprise, l'utilisateur se connecte simplement à Internet et ensuite il crée une connexion VPN jusqu'au réseau de l'entreprise. Figure 5 : Utilisation d'un VPN pour connecter un client distant à un réseau privé. L'utilisateur distant sera connecté logiquement au réseau LAN de l'entreprise comme s'il l'était physiquement. 4.1.2 Connexion entre plusieurs réseaux à travers Internet (LAN to LAN) Il y a deux méthodes pour connecter des réseaux locaux entre eux avec un VPN: 1. En utilisant des lignes dédiées Au lieu d'utiliser des lignes louées très coûteuses à longue distance entre deux LAN, on utilise une ligne dédiée locale pour se connecter à un ISP pour permettre des connexions à Internet. Le réseau privé virtuel sera donc créé à l'aide des connexions locales à l'isp et à l'aide du réseau public Internet. 2. À l'aide d'une liaison téléphonique Au lieu d'utiliser des lignes dédiées pour se connecter à l'isp, il suffit d'avoir une liaison téléphonique permettant l'appel de son propre ISP. Comme pour la solution précédente, le réseau privé virtuel sera créé à l'aide des connexions locales à l'isp et à l'aide du réseau public Internet. Travail de diplôme Tutorial VPN Page 9

Ces deux solutions diffèrent uniquement dans la façon de se connecter à son propre ISP. L'image suivante montre ces solutions. Figure 6 : Connexions LAN to LAN. 4.1.3 Réseau privé entre deux ordinateurs (Host to Host) Dans ce cas de figure, on veut connecter deux ordinateurs distants entre eux pour des raisons de confidentialité. On crée donc un VPN entre eux, et toutes les données y transmises sont encryptées et compréhensibles que par les deux paires correspondantes. La figure suivante montre cet exemple. Figure 7 : VPN entre deux hôtes. 5. Exigences de base des VPN Lorsqu'on veut créer des VPN, l'entreprise nécessite d'un contrôle d'accès facilité aux ressources et aux informations partagées. La solution doit permettre aux utilisateurs distants de se connecter aux ressources du réseau LAN local (solution Host-to-LAN). La solution doit aussi permettre à des réseaux distants de pouvoir se connecter au réseau LAN, afin de partager les ressources et les informations (solution LAN-to- LAN). De plus la solution doit assurer la confidentialité et l'intégrité des données à travers Internet. Le même concept doit être appliqué à des données sensibles traversant le réseau d'entreprise. En conséquence une solution VPN doit offrir au minimum les fonctions suivantes : Authentification de l'utilisateur : la solution doit vérifier l'identité de l'utilisateur et limiter l'accès VPN seulement aux utilisateurs autorisés. Il doit de même pouvoir enregistrer les accès, afin de permettre ensuite de déterminer qui s'est connecté et quand il s'est connecté. Administration des adresses : la solution doit assigner une adresse du réseau privé à chaque client et assurer que les adresses privées restent en tant que privées. Encryption des données : les données circulants dans le réseau public (Internet) doivent être illisibles aux clients non autorisés. Administration des clés : la solution doit générer et mettre à jour les clés pour l'encryption des données pour le client et le serveur. Support multiprotocoles : la solution doit permettre l'utilisation de protocoles communs utilisés dans le réseau public. IP, IPX, etc. sont inclus. Travail de diplôme Tutorial VPN Page 10

Une solution VPN peut être basée sur le protocole PPTP (Point-to-Point Tunneling Protocol), le protocole L2TP (Layer 2 Tunneling Protocol) ou IPSec (IP Security Protocol). 6. Protocoles VPN 6.1 Concepts de base sur les tunnels Le tunneling permet l'envoi de données d'un réseau à un autre en utilisant une infrastructure d'inter réseau. Les données à transférer (ou la charge utile - payload) peuvent être les trames (ou des paquets) d'un autre protocole. Au lieu d'envoyer une trame dans son état originaire, le protocole qui implémente le tunnel encapsule la trame dans une en-tête supplémentaire. L'en-tête supplémentaire fournit des informations de routage de sorte que la charge utile encapsulée puisse traverser le réseau intermédiaire. Les paquets encapsulés sont alors conduits entre les points finaux du tunnel à travers le réseau intermédiaire. Le chemin d'accès logique, par lequel les paquets encapsulés traversent l'inter réseau, s'appelle tunnel. Une fois que les trames encapsulées atteignent leur destination, la trame est décapsulée et expédiée à sa destination finale. Le tunneling inclut l'entier processus : encapsulation, transmission, et décapsulation des paquets. Figure 8 : Tunneling. Pour la création d'un tunnel, tant le client que le serveur doivent implémenter le même protocole. Les technologies utilisant le tunneling peuvent être basées sur des protocoles de niveau 2 ou 3. Ces niveaux correspondent aux différentes couches du modèle de référence OSI (Open Systems Interconnection). Les protocoles de niveau 2 correspondent à des protocoles de couche liaison. PPTP (Point-to-Point Tunneling Protocol) et L2TP (Layer 2 Tunneling Protocol) sont des protocoles de niveau 2; les deux encapsulent la charge utile dans une trame PPP (Point-to-Point Protocol) pour être ensuite envoyé à travers le réseau intermédiaire. Les protocoles de niveau 3 correspondent à des protocoles de couche réseau. Le mode tunnel de IPSec (IP Security) représente un exemple d'un protocole de niveau 3. En bref : PPTP permet au trafic IP, IPX ou NetBEUI d'être encrypté et ensuite d'être encapsulé dans un paquet IP, afin d'être envoyé à travers un réseau intermédiaire IP, comme Internet. L2TP permet au trafic IP, IPX ou NetBEUI d'être encrypté et ensuite d'être envoyé à travers n'importe quel type de média qui supporte la livraison de datagramme point à point, comme IP, X.25, Frame Relay ou ATM. IPSec (configuré en mode tunnel) permet l'encryptage de la charge utile IP, l'encapsulation dans un autre paquet IP, et l'envoi à travers un réseau intermédiaire IP, comme Internet. Ces protocoles feront respectivement l'objet d'une présentation dans les chapitres 6.2, 6.3 et 6.4. Travail de diplôme Tutorial VPN Page 11

6.1.1 Types de tunnel Les tunnels peuvent être créés selon des manières différentes. Tunnel volontaire : un client peut émettre une demande de création de VPN, afin de configurer et de créer un tunnel volontaire. Dans ce cas, l'ordinateur de l'utilisateur est un point final du tunnel. Le tunneling volontaire se produit lorsqu'un poste de travail ou un serveur de routage emploie un client implémentant le tunneling pour créer une connexion virtuelle avec le serveur destinataire. Les VPN n'exigent pas une connexion commutée. C'est une étape préliminaire en vue de créer un tunnel et n'est pas une partie du protocole de tunnel elle-même. Ils exigent seulement la gestion du réseau IP. Tunnel d'office : un serveur d'accès réseau implémemtant un protocole VPN configure et crée un tunnel d'office. Avec un tunnel d'office, l'ordinateur de l'utilisateur n'est pas un point final de tunnel. C'est le serveur d'accès à distance, entre l'ordinateur de l'utilisateur et le serveur VPN, qui est le point final du tunnel et agit en tant que client VPN. 6.2 PPTP Point-to-Point Tunneling Protocol 6.2.1 Préambule PPTP (Point-to-Point Tunnelling Protocol) est un protocole réseau permettant le transfert sécurisé de données entre un client distant et un serveur privé. Ceci est possible par la création d'un VPN utilisant TCP/IP. PPTP supporte les VPN à la demande multiprotocole sur des réseaux publics comme Internet. La technologie utilisée par PPTP est une extension du protocole permettant l'accès à distance PPP (Pointto-Point Protocol) défini dans le document de l'ietf (Internet Engineering Task Force) intitulé "The Pointto-Point Protocol for the transmission of multiprotocols Datagrams over Point-to-Point Links" (RFC 1171, v. CD en annexe). PPTP est un protocole qui encapsule les paquets PPP dans des datagrammes IP pour la transmission sur Internet ou un autre réseau public basé sur TCP/IP. PPTP peut être de même utilisé pour des liaisons LAN-to-LAN. Le protocole PPTP est expliqué dans le document "Point-to-Point Tunnelling Protocol, (RFC 2637, v. CD en annexe).un avant-projet de ce document fut envoyé à l'ietf en juin 1996 par les entreprises du PPTP forum. US Robotics, ECI Telematics, 3 Com/Primary Access, Ascend Communications, Microsofts Corporation sont inclus. 6.2.2 PPTP et les VPN PPTP permet la création de VPN sur demande à travers des réseaux basés sur TCP/IP. Il peut de même être utilisé pour créer un VPN entre deux ordinateurs dans le même réseau local. Une caractéristique importante de PPTP est son support pour la création de réseaux privés virtuels en utilisant le réseau téléphonique public (PSTN). PPTP simplifie et réduits les coûts d'une solution pour l'accès longue distance par les utilisateurs distants mobiles. Ceci, car il permet des communications encryptées sûres à travers les liaisons téléphoniques et l'internet. Généralement, l'usage de PPTP implique: - un client PPTP; - un serveur d'accès réseau (Network Access Server NAS); - un serveur PPTP. Travail de diplôme Tutorial VPN Page 12

L'usage d'un serveur d'accès réseau pour la création d'un tunnel PPTP entre deux dispositifs sur le même LAN n'est pas nécessaire. Ceci, en raison du fait que les dispositifs se trouvent déjà sur le même réseau. Le sous-chapitre suivant décrira un scénario typique de l'usage de PPTP entre deux ordinateurs et en expliquera la relation. 6.2.3 Scénario PPTP typique L'usage typique de PPTP commence avec le besoin de la part d'un client PPTP, qui soit distant ou mobile, de se connecter au réseau privé d'une entreprise. Pour se faire, le client doit se connecter à Internet à l'aide d'un ISP local (Internet Service Provider). Le client se connecte au serveur d'accès (NAS) 1 de l'isp. Une fois connecté le client peut envoyer et recevoir des paquets depuis Internet et utiliser TCP/IP. Après que le client ait créé la connexion PPP initiale avec l'isp une seconde connexion PPP est faite sur l'existante. Les données envoyées à travers la deuxième connexion sont sous la forme de datagrammes IP contenants des paquets PPP; ces paquets PPP sont en fait des paquets PPP encapsulés. Cette deuxième connexion crée la liaison VPN avec le serveur PPTP de l'entreprise et elle est appelée "tunnel". La figure suivante montre un tunnel PPTP. Figure 9 : Tunnel PPTP. Le processus permettant l'envoie de paquets vers un ordinateur se trouvant dans un réseau privé, en faisant un routage des paquets sur d'autres réseaux, comme Internet, est appelé "Tunneling". Les routeurs des autres réseaux ne peuvent pas accéder à l'ordinateur qui se trouve dans le réseau privé. Toutefois, le tunneling permet au réseau public de transmettre les paquets à un dispositif intermédiaire, comme un serveur PPTP, qui est connecté, tant au réseau public qu'au réseau privé. Le client et le serveur PPTP utilisent le tunnel pour router les paquets vers un ordinateur situé dans le réseau privé en utilisant des routeurs qui connaissent seulement l'adresse publique du serveur intermédiaire qui fait office de passerelle. Lorsque le serveur PPTP reçoit des paquets provenant du réseau public, il les envoie à l'ordinateur destinataire qui se trouve dans le réseau privé. Le serveur PPTP fait cela après avoir analysé le paquet PPTP et avoir obtenu le nom de la machine destinatrice, soit l'adresse dans le paquet PPP encapsulé. Il faut remarquer que le paquet PPP encapsulé peut contenir plusieurs types de protocoles comme TCP/IP, IPX ou NetBEUI. Puisque le serveur PPTP est configuré pour communiquer à travers le réseau privé en utilisant les protocoles du réseau privé, il est capable de comprendre les paquets de plusieurs protocoles. 1 NAS Network Acces Server : Les serveurs d'accès-réseau sont référencés de même en tant que FEPs (Front End Processors). Les serveurs Dial-in comme POP (Point-Of-Presence servers). Travail de diplôme Tutorial VPN Page 13

La figure suivante montre le support multiprotocole de PPTP. Un paquet envoyé par le client vers le serveur PPTP passe à travers le tunnel et va rejoindre la machine destinatrice dans le réseau local. Figure 10 : Connexion à distance entre un client PPTP et un réseau privé. PPTP encapsule les paquets PPP cryptés et compressés dans un datagramme IP pour la transmission sur Internet. Ces datagrammes sont routés à travers Internet jusqu'au serveur PPTP qui est connecté tant au réseau public qu'au réseau privé. Ensuite le serveur PPTP désassemble ces datagrammes dans des paquets PPP et encode ces paquets dans le protocole utilisé dans le réseau local (IPX, TCP/IP, NetBEUI). 6.2.4 Clients PPTP Un client PPTP peut être un ordinateur qui supporte le protocole PPTP, comme par exemple un client Linux ou Microsoft. Il peut se connecter à un serveur PPTP de deux manières différentes : Soit en utilisant l'accès d'un ISP qui supporte des connexions PPP entrantes; Soit en utilisant une connexion TCP/IP physique qui lui permet de se connecter directement au serveur PPTP. Un client qui utilise l'accès d'un ISP doit être doté d'un modem et d'un dispositif VPN 2 ; qui permettent respectivement la connexion à l'isp et au serveur PPTP. Comme vu dans le chapitre précédent le tunnel PPTP est créé à partir de deux connexions. La première connexion est une connexion PPP par modem à destination des fournisseurs d'accès Internet. La deuxième est une connexion VPN PPTP utilisant la première connexion pour créer un tunnel à travers Internet vers un dispositif VPN sur le serveur PPTP. La deuxième connexion nécessite de la première, car le tunnel entre les deux dispositifs VPN est établi en utilisant le modem et la connexion PPP vers Internet. Une autre possibilité consiste à créer un réseau privé virtuel entre deux ordinateurs connectés physiquement au réseau LAN privé. Dans ce scénario, le client PPTP est déjà connecté au réseau et il a seulement besoin du dispositif VPN pour la connexion à un serveur PPTP dans le LAN. Les paquets d'un client distant (accès par modem) et d'un client local (LAN) sont traités différemment. Un paquet PPTP provenant d'un client distant est placé dans le média physique du dispositif de télécommunication (modem) qui peut être une ligne téléphonique ou le téléréseau, etc.. Tandis qu'un paquet PPTP provenant d'un client relié physiquement au réseau local est placé dans l'adaptateur du média physique, comme par exemple une carte Ethernet. 2 En pratique, le dispositif VPN est un module sur Linux ou une carte VPN fictive sur Windows. Travail de diplôme Tutorial VPN Page 14

6.2.5 Serveur d'accès réseau de l'isp Les fournisseurs d'internet utilisent des serveurs d'accès (NAS) pour permettre à ces propres clients d'accéder à Internet à l'aide de protocoles comme SLIP, soit PPP. Pour supporter des clients PPTP, un NAS doit pouvoir offrir le service PPP. Les serveurs d'accès de l'isp sont paramétrés et configurés pour permettre un grand nombre d'appels entrants de la part des clients. Certains NAS supportent eux-mêmes PPTP. Dans ce cas, les clients n'on pas besoin d'avoir une interface VPN, car c'est le NAS qui agit en tant que client PPTP et qui se connecte au réseau privé en créant un tunnel entre l'isp et le serveur PPTP. 6.2.6 Serveur PPTP Les serveurs PPTP sont des serveurs qui ont des capacités de routage et sont connectés tant au réseau privé qu'à Internet. Un serveur PPTP peut être implémenté par un ordinateur tournant Linux et le daemon pptpd ou par un ordinateur ayant Window NT. Dans le cas de WinNT, PPTP est défini comme un protocole réseau. Pendant l'installation, PPTP est configuré en rajoutant le dispositif virtuel VPNs (Virtual Private Networks) à l'accès à distance. 6.2.7 Architecture PPTP Comme vu précédemment PPTP a été conçu, afin d'obtenir une méthode sûre pour rejoindre un réseau privé à travers Internet. Par les prochains chapitres, on examinera : Le protocole PPP; La connexion de contrôle PPTP; Le Tunnel PPTP. 6.2.8 Vue d'ensemble de l'architecture PPTP La création d'un VPN à l'aide de PPTP implique typiquement trois processus; chacun ayant besoin la terminaison correcte du processus précédent. Voici les processus impliqués. Connexion et communication PPTP : un client PPTP utilise PPP pour se connecter à son ISP à l'aide d'une ligne téléphonique analogique ou RNIS. Cette connexion utilise le protocole PPP pour établir la connexion et encrypter les paquets. Connexion de contrôle PPTP : en utilisant la connexion à Internet établie par PPP, le protocole PPTP crée une connexion de contrôle entre le client et le serveur PPTP. Cette connexion TCP utilise le port de destination 1723 pour établir le tunnel PPTP. Tunnel PPTP : enfin, le protocole PPTP crée des datagrammes IP contenants des paquets PPP encryptés, lesquels sont ensuite envoyés à travers le tunnel PPTP au serveur. Le serveur désassemble les datagrammes IP, les décrypte et les redirige vers le réseau LAN privé. Protocole PPP : PPP est un protocole pour l'accès à distance utilisé par PPTP pour l'envoi de données à travers les réseaux basés sur TCP/IP. PPP encapsule les paquets IP, IPX ou NetBEUI dans des trames. Ces trames sont envoyées en créant un lien point à point entre l'ordinateur émetteur et celui récepteur. La plupart des sessions PPTP sont démarrées par un client appelant un serveur d'accès d'un ISP. Le protocole PPP est utilisé pour la création de la connexion entre le client et le serveur d'accès réseau. PPP offre ces trois options : Etablir et former la connexion physique : le protocole PPP utilise la séquence définie dans le document de référence (RFC 1662, v. CD en annexe) pour la création, le maintien et la fermeture de la connexion. Authentifier les utilisateurs : les clients PPTP sont authentifiés par le protocole PPP. L'authentification peut être faite par l'envoi de clés en clair ou encryptées. Créer des datagrammes PPP contenants des paquets IPX, NetBEUI, soit TCP/IP : PPP crée des datagrammes contentant un ou plusieurs paquets TCP/IP, IPX soit NetBEUI. Vu que tous les Travail de diplôme Tutorial VPN Page 15

paquets sont encryptés, le trafic entre un client PPP et un serveur d'accès peut être considéré comme sûr. 6.2.9 Connexion de contrôle PPTP Le protocole PPTP défini une série de messages de contrôle échangés entre le client et le serveur PPTP. Ces commandes établissent, maintiennent et terminent le tunnel PPTP. La liste suivante représente les messages utilisés pour établir et maintenir le tunnel. Messages de gestion de la connexion: START_CONTROL_REQUEST START_CONTROL_REPLY STOP_CONTROL_REQUEST STOP_CONTROL_REPLY ECHO_REQUEST ECHO_REPLY Demande de début de session Réponse à la demande de début de session Demande de fin de session Réponse à la demande de fin de session Demande de maintient la session de contrôle Réponse à la demande de maintient Messages de gestion du tunnel: OUTGOING_CALL_REQUEST OUTGOING_CALL_REPLY INCOMING_CALL_REQUEST INCOMING_CALL_REPLY INCOMING_CALL_CONNECTED CLEAR_CALL_REQUEST DISCONNECT_CALL_NOTIFY Demande de création du tunnel de la part du client Réponse à la demande de création du tunnel de la part du client Demande de création du tunnel de la part du serveur Réponse à la demande de création du tunnel de la part du serveur Tunnel en entrée crée Demande de terminaison de la session PPTP Réponse à la demande de terminaison et fin de la session PPTP Messages d'erreurs: WAN_ERROR_NOTIFY Erreur dans la connexion PPP Messages de gestion de la session PPP: SET_LINK_INFO Configure la connexion entre le client et le serveur 6.2.9.1 Messages de gestion de la connexion Ces messages sont utilisés pour établir et terminer une session d'utilisateur. Ces messages sont envoyés Travail de diplôme Tutorial VPN Page 16

comme données dans la connexion TCP 1723 établie auparavant entre le client et le serveur PPTP. Start-Control-Connection-Request Le Start-Control-Connection-Request est un message de contrôle PPTP employé pour établir la connexion de contrôle entre un client et un serveur. Une connexion de contrôle doit être créée pour chaque paire client-serveur. Une connexion de contrôle doit être établie avant que tous les autres messages de contrôle PPTP puissent être émis. 16 bit 16 bit PPTP Message Type Control Message Type Reserved0 Protocol Version Reserved1 Framing Capabilities Bearer Capabilities Maximum Channels Firmware Revision Host Name (64 octets) Vendor String (64 octets) Figure 11 : message de contrôle Start-Control-Connection-Request Déscription des champs de la trame: Longueur totale en octets du message PPTP. L'entête est incluse. PPTP Message Type Valeur 1 pour un message de contrôle. Valeur 0x1A2B3C4D. Cette constante est utilisée comme test pour les paquets reçus. Control Message Type Valeur 1 pour indiquer le message Start-Control-Connection-Request. Reserved0 Ce champ doit être à 0. Protocol Version Indique la version de PPTP utilisée. Reserved1 Ce champ doit être à 0. Framing Capabilities Indique le type des trames. Deux valeurs sont possibles: 1 - Asynchronous Framing 2 - Synchronous Framing Bearer Capabilities Indique le type d'accés. Deux valeurs sont possibles: 1 - Accès analogique supporté 2 - Accès numérique supporté Maximum Channels Indique le nombre maximal de session PPP individuelles. Dans le cas du message Start-Control-Connection-Requests envoyé par le client, cette valeur doit être à 0. Firmware Revision Ce champ contient la version du firmware Host Name Indique le nom du client ou du serveur. Ce champ est de 64 octets. Vendor Name Indique le nom du constructeur du client ou du serveur. Ce champ est de 64 octets. Start-Control-Connection-Reply Ce message est utilisé comme réponse au message Start-Control-Connection-Request. Il contient le Travail de diplôme Tutorial VPN Page 17

résultat de la demande de connexion. 16 bit 16 bit PPTP Message Type Control Message Type Reserved0 Protocol Version Result Code Error Code Framing Capabilities Bearer Capabilities Maximum Channels Firmware Revision Host Name (64 octets) Vendor String (64 octets) Figure 12 : message de contrôle Start-Control-Connection-Reply Déscription des champs de la trame: Longueur totale en octets du message PPTP. L'entête est incluse. PPTP Message Type Valeur 1 pour un message de contrôle. Valeur 0x1A2B3C4D. Cette constante est utilisée comme test pour les paquets reçus. Control Message Type Valeur 2 pour indiquer le message Start-Control-Connection-Reply. Reserved0 Ce champ doit être à 0. Protocol Version Indique la version de PPTP utilisée. Result Code Indique le résultat de la tentative de connexion. Les valeurs possibles sont: 1 - Connexion établie avec succès 2 - Erreur générale. Si défini, il est spécifié dans le champ Error Code 3 - La connexion de contrôle existe déjà 4 - Le client n'est pas autorisé à créer la connexion de contrôle. 5 - La version du protocole n'est pas supportée Error Code Tant qu'il n'y a pas d'erreur générale, ce champ vaut 0. Sinon il indique le type d'erreur. Framing Capabilities Indique le type des trames. Deux valeurs sont possibles: 1 - Asynchronous Framing 2 - Synchronous Framing Bearer Capabilities Indique le type d'accés. Deux valeurs sont possibles: 1 - Accès analogique supporté 2 - Accès numérique supporté Maximum Channels Indique le nombre maximal de sessions PPP individuelles. Dans le cas du message Start-Control-Connection-Requests envoyé par le client, cette valeur doit être à 0. Firmware Revision Ce champ contient la version du firmware Host Name Indique le nom du client ou du serveur. Ce champ est de 64 octets. Vendor Name Indique le nom du constructeur du client ou du serveur. Ce champ est de 64 octets. Stop-Control-Connection-Request Le Stop-Control-Connection-Request est un message de contrôle envoyé par un pair de la connexion afin Travail de diplôme Tutorial VPN Page 18

d'informer l'autre que la connexion de contrôle devrait être fermée. En plus de fermer la connexion, tous les appels d'utilisateur actifs sont implicitement effacés. La raison de l'émission de cette demande est indiquée dans le champ Reason. 16 bit 16 bit PPTP Message Type Control Message Type Reserved0 Reason Reserved1 Reserved2 Figure 13 : message de contrôle Stop-Control-Connection-Request Déscription des champs de la trame: Longueur totale en octets du message PPTP. L'entête est incluse. PPTP Message Type Valeur 1 pour un message de contrôle. Valeur 0x1A2B3C4D. Cette constante est utilisée comme test pour les paquets reçus. Control Message Type Valeur 3 pour indiquer le message Stop-Control-Connection-Request. Reserved0 Ce champ doit être à 0. Reason Indique la raison pour la fermeture de la connexion. Che champs peut avoir les valeurs: 1 - (None) Requête générale pour la fermeture de la connexion 2 - (Stop-Protocol) Version de protocole non supportée 3 - (Stop-Local-Shutdown) Arrêt de l'ordinateur qui fait la requête Reserved1, Reserved2 Ce champ doit être à 0. Stop-Control-Connection-Reply Le Stop-Control-Connection-Reply est un message de contrôle envoyé par un pair d'une connexion de contrôle à la réception d'un message Control-Connection-Request de l'autre pair. 16 bit 16 bit PPTP Message Type Control Message Type Reserved0 Result Code Error Code Reserved1 Déscription des champs de la trame: Longueur totale en octets du message PPTP. L'entête est incluse. PPTP Message Type Valeur 1 pour un message de contrôle. Valeur 0x1A2B3C4D. Cette constante est utilisée comme test pour les paquets reçus. Control Message Type Valeur 4 pour indiquer le message Stop-Control-Connection-Reply. Reserved0 Ce champ doit être à 0. Result Code sont: Indique le resultat de la demande de déconnexion. Les valeurs possibles 1 (OK) - Connexion de contrôle fremée. 2 (General Error) - Connexion de contrôle pas fermée à cause de Error Code Travail de diplôme Tutorial VPN Page 19

Error Code Tant qu'il n'y a pas d'erreur générale, ce champ vaut 0. Sinon il indique le type d'erreur. Reserved1 Ce champ doit être à 0. Echo-Request L'Echo-Request est un message de contrôle envoyé par l'un ou l'autre pair d'une connexion de contrôle. Ce message est utilisé comme test d'existance de la connexion de contrôle. Le pair de réception émet un Echo-Reply à chaque Echo-Request reçu. Si l'expéditeur ne reçoit pas un Echo-Reply en réponse à un Echo-Request, il peut fermer la connexion. 16 bit 16 bit PPTP Message Type Control Message Type Reserved0 Identifier Figure 14 : message de contrôle Echo-Request Déscription des champs de la trame: Longueur totale en octets du message PPTP. L'entête est incluse. PPTP Message Type Valeur 1 pour un message de contrôle. Valeur 0x1A2B3C4D. Cette constante est utilisée comme test pour les paquets reçus. Control Message Type Valeur 5 pour indiquer le message Echo-Request. Reserved0 Ce champ doit être à 0. Identifier Valeur choisit par l'émetteur pour la correspondance avec le message suivant Echo-Reply. Echo-Reply L'Echo-Reply est un message de contrôle envoyé par l'un ou l'autre pair d'une connexion de contrôle en réponse à la réception d'une demande d'écho. 16 bit 16 bit PPTP Message Type Control Message Type Reserved0 Identifier Result Code Error Code Reserved1 Figure 15 : message de contrôle Echo-Reply Déscription des champs de la trame: Longueur totale en octets du message PPTP. L'entête est incluse. PPTP Message Type Valeur 1 pour un message de contrôle. Valeur 0x1A2B3C4D. Cette constante est utilisée comme test pour les paquets reçus. Control Message Type Valeur 6 pour indiquer le message Echo-Reply. Reserved0 Ce champ doit être à 0. Identifier Valeur choisit par l'émetteur pour la correspondance avec le message Echo- Request. La valeur est celle reçue dans le champ Identifier du message Echo-Request. Travail de diplôme Tutorial VPN Page 20

Result Code Indique le résultat de la requête Echo-Request. Les valeurs possibles sont: 1 (OK) - Requête valide 2 (General Error) - Requête Echo-Request non acceptée Error Code Tant qu'il n'y a pas d'erreur générale, ce champ vaut 0. Sinon il indique le type d'erreur. Reserved1 Ce champ doit être à 0. 6.2.9.2 Messages de gestion du tunnel Ces messages servent à la gestion du tunnel GRE. Outgoing-Call-Request L'Outgoing-Call-Request est un message envoyé par le client pour indiquer qu'un tunnel pour les données doit être établi. Cette demande fournit au serveur des informations qui permettent la régulation de la transmission des données. 16 bit 16 bit PPTP Message Type Control Message Type Reserved0 Call ID Call Serial Number Minimum BPS Maximum BPS Bearer Type Framing Type Packet Recv. Window Size Packet Processing Delay Phone Number Reserved1 Phone Number (64 octets) Subaddress (64 octets) Figure 16 : message de contrôle Outgoing-Call-Request Déscription des champs de la trame: Longueur totale en octets du message PPTP. L'entête est incluse. PPTP Message Type Valeur 1 pour un message de contrôle. Valeur 0x1A2B3C4D. Cette constante est utilisée comme test pour les paquets reçus. Control Message Type Valeur 7 pour indiquer le message Outgoing-Call-Request. Reserved0 Ce champ doit être à 0. Call ID Un identificateur unique assigné par le client à cette session. Elle est employée pour multiplexer et démultiplexer des données envoyées dans le tunnel. Call Serial Number Un identificateur assigné par le client à cette. À la différence de l'identification d'appel, le client et le serveur associent le même numéro d'appel à une session donnée. La combinaison du numéro de série et de l'adresse IP et d'appel devrait être unique. Minimum BPS Vitesse de ligne minimale (in bits/sec) pour cette session. Maximum BPS Vitesse de ligne maximale (in bits/sec) pour cette session. Bearer Capabilities Indique le type d'accès. Deux valeurs sont possibles: 1 - Accès analogique supporté Travail de diplôme Tutorial VPN Page 21

2 - Accès numérique supporté 3 - Tous les types d'accès sont supportés Framing Capabilities Indique le type des trames. Deux valeurs sont possibles: 1 - Asynchronous Framing 2 - Synchronous Framing 3 - Tous les types sont supportés Packet Recv. Window Size Le nombre de paquets de données reçus que le client protégera pour cette session. Packet Processing Delay Une mesure du retard de traitement de paquet qui pourrait être imposé aux données a envoyé au client. Cette valeur est indiquée dans les unités de 1/10 de secondes. Pour le client ce nombre devrait être très petit. Phone Number Le nombre réel de chiffres valides dans le domaine de numéro de téléphone. Reserved1 Ce champ doit être à 0. Phone Number Le nombre à composer pour établir la session sortante. Pour des appels numériques et analogiques cette zone est une chaîne de caractères ascii. Si le numéro de téléphone est moins de 64 octets de longueur, le reste de cette zone est rempli d'octets de valeur 0. Subaddress Une zone de 64 octets indiquant de l'information supplémentaire. Outgoing-Call-Reply L'Outgoing-Call-Reply est un message de contrôle du serveur en réponse à un message Outgoing-Call- Request. La réponse indique le résultat de la tentative d'appel sortant. Elle fournit également des informations au client au sujet des paramètres particuliers utilisés pour l'appel. 16 bit 16 bit PPTP Message Type Control Message Type Reserved0 Call ID Peer's Call ID Result Code Error Code Cause Code Connect Speed Packet Recv. Window Size Packet Processing Delay Physical Channel ID Figure 17 : message de contrôle Outgoing-Call-Reply Déscription des champs de la trame: Longueur totale en octets du message PPTP. L'entête est incluse. PPTP Message Type Valeur 1 pour un message de contrôle. Valeur 0x1A2B3C4D. Cette constante est utilisée comme test pour les paquets reçus. Control Message Type Valeur 8 pour indiquer le message Outgoing-Call-Reply. Reserved0 Ce champ doit être à 0. Call ID Un identificateur unique assigné par le serveur à cette session. Elle est employée pour multiplexer et démultiplexer des données envoyées dans le tunnel. Peer's Call ID Dans ce champ se trouve la valeur reçue dans le domaine d'identification d'appel du message précedent d'outgoing-call-request. Elle est employée par le client pour comparer l'outgoing-call-reply avec l'outgoing-call- Request qu'il a émis. Travail de diplôme Tutorial VPN Page 22

Result Code Indique le résultat de la requête Outgoing-Call-Request. Les valeurs possibles sont: 1 - Connexion établie avec succès 2 - Erreur générale. Si défini, il est spécifié dans le champ Error Code 3 (No Carrier) - Aucune porteuse détectée 4 (Busy) - Ligne occupée 5 (No Dial Tone) - L'appel sortant est échoué en raison du manque de la tonalité 6 (Time-out) - L'appel sortant n'a pas été établi dans le temps établi par le serveur 7 (Do Not Accept) - Appel sortant administrativement interdit Error Code Tant qu'il n'y a pas d'erreur générale, ce champ vaut 0. Sinon il indique le type d'erreur. Cause Code Ce champ fournit l'information supplémentaire de panne. Sa valeur peut changer à dépendance du type d'appel. Connect Speed La vitesse réelle de connexion utilisée, en bits/sec. Packet Recv. Window Size Le nombre de paquets de données reçus que le serveur protégera pour cette session. Packet Processing Delay Une mesure du retard de traitement de paquet qui pourrait être imposé aux données a envoyé au serveur. Cette valeur est indiquée dans les unités de 1/10 de secondes. Pour le client ce nombre devrait être très petit. Physical Channel ID Ce champ est configuré par le serveur avec le numéro de canal physique employé pour cet appel. Il est utilisé pour des buts d'enregistrements seulement. Incoming-Call-Request L'Incoming-Call-Request est un message de contrôle envoyé par le serveur pour indiquer qu'un tunnel doit être établi. Le serveur ne peut pas le créer jusqu'à ce qu'elle ait reçu un Incoming-Call-Reply du client, indiquant que l'appel peut être établi. Ce mécanisme permet au client d'obtenir des informations suffisantes sur le tunnel avant qu'on lui réponde pour déterminer si l'appel doit être répondu ou pas. 16 bit 16 bit PPTP Message Type Control Message Type Reserved0 Call ID Call Serial Number Call Bearer Type Physical Channel ID Dialed Number Dialing Number Dialed Number (64 octets) Dialing Number (64 octets) Subaddress (64 octets) Figure 18 : message de contrôle Incoming-Call-Request Déscription des champs de la trame: PPTP Message Type Longueur totale en octets du message PPTP. L'entête est incluse. Valeur 1 pour un message de contrôle. Travail de diplôme Tutorial VPN Page 23

Valeur 0x1A2B3C4D. Cette constante est utilisée comme test pour les paquets reçus. Control Message Type Valeur 9 pour indiquer le message Incoming-Call-Request. Reserved0 Ce champ doit être à 0. Call ID Un identificateur unique assigné par le serveur à cette session. Elle est employée pour multiplexer et démultiplexer des données envoyées dans le tunnel. Call Serial Number Un identificateur assigné par le serveur à cette. À la différence de l'identification d'appel, le client et le serveur associent le même numéro d'appel à une session donnée. La combinaison du numéro de série et de l'adresse IP et d'appel devrait être unique. Bearer Type Valeur indiquant le type de canal utilisé pour l'appel entrant. Les valeurs possibles sont: 1 - Call is on an analog channel 2 - Call is on a digital channel Physical Channel ID Ce champ est configuré par le serveur avec le numéro de canal physique employé pour cet appel. Il est utilisé pour des buts d'enregistrements seulement. Dialed Number Le nombre réel de chiffres valides dans le champ du nombre composé. Dialing Number Le nombre réel de chiffres valides dans le champ du nombre à composer. Dialed Number Le numéro qui a été composé par l'appelant. Pour des appels de numériques et analogiques ce champ est une chaîne de caractères ascii. Si le numéro composé est moins de 64 octets de longueur, le reste de ces champs est rempli d'octets de valeur 0. Dialing Number Le numéro qui est à composer. Pour des appels de numériques et analogiques ce champ est une chaîne de caractères ascii. Si le numéro composé est moins de 64 octets de longueur, le reste de ce champs est rempli d'octets de valeur 0. Subaddress Une zone de 64 octets indiquant de l'information supplémentaire. Incoming-Call-Reply L'Incoming-Call-Reply est un message envoyé par le client en réponse à un message d'incoming-call- Request. La réponse indique le résultat de la tentative d'appel d'arrivée. Elle fournit également des informations pour permettre au client de régler la transmission de données. Il indique au serveur si l'appel doit être répondu ou pas. 16 bit 16 bit PPTP Message Type Control Message Type Reserved0 Call ID Peer's Call ID Result Code Error Code Packet Recv. Window Size Packet Transmit Delay Reserved1 Physical Channel ID Figure 19 : message de contrôle Incoming-Call-Reply Déscription des champs de la trame: PPTP Message Type Longueur totale en octets du message PPTP. L'entête est incluse. Valeur 1 pour un message de contrôle. Travail de diplôme Tutorial VPN Page 24

Valeur 0x1A2B3C4D. Cette constante est utilisée comme test pour les paquets reçus. Control Message Type Valeur 10 pour indiquer le message Incoming-Call-Reply. Reserved0 Ce champ doit être à 0. Call ID Un identificateur unique assigné par le client à cette session. Elle est employée pour multiplexer et démultiplexer des données envoyées dans le tunnel. Peer's Call ID Dans ce champ se trouve la valeur reçue dans le champ d'identification d'appel du message Incoming-Call-Request. Elle est employée par le serveur pour comparer l'incoming-call-reply avec l'incoming-call-request qu'il a émis. Result Code Indique le résultat de la requête Incoming-Call-Request. Les valeurs possibles sont: 1 - Connexion établie avec succès 2 - Erreur générale. Si défini, il est spécifié dans le champ Error Code 3 - (Do Not Accept) Le serveur n'accepte pas la requête. Il doit accrocher ou envoyer un signal d'occupation Error Code Tant qu'il n'y a pas d'erreur générale, ce champ vaut 0. Sinon il indique le type d'erreur. Packet Recv. Window Size Le nombre de paquets de données reçus que le serveur protégera pour cette session. Packet Transmit Delay Une mesure du retard de traitement de paquet qui pourrait être imposé aux données a envoyé au serveur. Cette valeur est indiquée dans les unités de 1/10 de secondes. Pour le client ce nombre devrait être très petit. Reserved1 Ce champ doit être à 0. Incoming-Call-Connected Le message d'incoming-call-connected est un message envoyé par le serveur en réponse à un Incoming- Call-Reply reçu. Il fournit des informations au client au sujet des paramètres particuliers utilisés pour l'appel. Il fournit un mécanisme pour donner au client des informations supplémentaires sur l'appel qui ne peut pas, en général, être obtenu lorsque l'incoming-call-request est émis par le serveur. 16 bit 16 bit PPTP Message Type Control Message Type Reserved0 Peer's Call ID Reserved1 Connect Speed Packet Recv. Window Size Packet Transmit Delay Framing Type Figure 20 : message de contrôle Incoming-Call-Connected Déscription des champs de la trame: Longueur totale en octets du message PPTP. L'entête est incluse. PPTP Message Type Valeur 1 pour un message de contrôle. Valeur 0x1A2B3C4D. Cette constante est utilisée comme test pour les paquets reçus. Control Message Type Valeur 11 pour indiquer le message Incoming-Call-Connected. Reserved0 Ce champ doit être à 0. Travail de diplôme Tutorial VPN Page 25

Peer's Call ID Dans ce champ se trouve la valeur reçue dans le champ d'identification d'appel du message Incoming-Call-Reply. Elle est employée par le client pour comparer l'incoming-call-connected avec l'incoming-call-reply qu'il a émis. Connect Speed La vitesse réelle de connexion utilisée, en bits/sec. Packet Recv. Window Size Le nombre de paquets de données reçus que le serveur protégera pour cette session. Packet Transmit Delay Une mesure du retard de traitement de paquet qui pourrait être imposé aux données a envoyé au serveur. Cette valeur est indiquée dans les unités de 1/10 de secondes. Pour le client ce nombre devrait être très petit. Framing Type Valeur indiquant le type de trame utilisé. Ce champ peut valoir: 1 - Appel de type asynchrone 2 - Appel de type synchrone Call-Clear-Request Le Call-Clear-Request est un message de contrôle envoyé par le client indiquant qu'un tunnel particulier doit être fermé. Le tunnel à terminer peut être un tunnel entrant ou sortant, dans n'importe quel état. Le serveur répond à ce message avec un Call-Disconnect-Notify. 16 bit 16 bit PPTP Message Type Control Message Type Reserved0 Call ID Reserved1 Framing Type Figure 21 : message de contrôle Call-Clear-Request Déscription des champs de la trame: Longueur totale en octets du message PPTP. L'entête est incluse. PPTP Message Type Valeur 1 pour un message de contrôle. Valeur 0x1A2B3C4D. Cette constante est utilisée comme test pour les paquets reçus. Control Message Type Valeur 12 pour indiquer le message Call-Clear-Request. Reserved0 Ce champ doit être à 0. Call ID Le numéro d'authentification assigné par le client à cet appel. Reserved1 Ce champ doit être à 0. Call-Disconnect-Notify Travail de diplôme Tutorial VPN Page 26

Le message de Call-Disconnect-Notify est un contrôle envoyé par le serveur. Il est émis toutes les fois qu'un tunnel est fermé, en raison de la réception par le serveur d'un Call-Clear-Request ou pour n'importe quelle autre raison. Son but est d'informer le client du tunnel et de la raison de cette fermeture. 16 bit 16 bit PPTP Message Type Control Message Type Reserved0 Call ID Result Code Error Code Cause Code Reserved1 Call Statistics (128 octets) Figure 22 : message de contrôle Call-Disconnect-Notify Déscription des champs de la trame: PPTP Message Type Longueur totale en octets du message PPTP. L'entête est incluse. Valeur 1 pour un message de contrôle. Valeur 0x1A2B3C4D. Cette constante est utilisée comme test pour les paquets reçus. Valeur 13 pour indiquer le message Call-Disconnect-Notify. Control Message Type Reserved0 Ce champ doit être à 0. Call ID Le numéro d'authentification assigné par le serveur à cet appel. Result Code Error Code Cause Code Call Statistics Indique la raison de la déconnexion. Les valeurs possibles sont: 1 (Lost Carrier) - Perte de la porteuse 2 (General Error) - Erreur générale 3 (Admin Shutdown) - Déconnecté pour der raisons administratives 4 (Request) - Déconnecté a cause d'une requête Call-Clear-Request Tant qu'il n'y a pas d'erreur générale, ce champ vaut 0. Sinon il indique le type d'erreur. Ce champ fournit l'information supplémentaire de panne. Sa valeur peut changer à dépendance du type d'appel. Ce champ contient un texte ascii contenant des statistiques d'appel et qui peuvent être enregistrés pour des diagnostiques. Si la longueur de ce texte est inférieure à 128, les bit restants sont mis à 0. Travail de diplôme Tutorial VPN Page 27

6.2.9.3 Messages d'erreurs WAN-Error-Notify Le message WAN-Error-Notify est un message de contrôle envoyé par le serveur pour indiquer des erreurs WAN (qui se produisent sur l'interface PPP supportante). Les compteurs dans ce message sont cumulatifs. Ce message devrait seulement être envoyé quand une erreur se produit, et pas plus d'une fois toutes les 60 secondes. Les compteurs sont remis à l'état initial quand un nouvel appel est établi. 16 bit 16 bit PPTP Message Type Control Message Type Reserved0 Peer's Call ID Reserved1 CRC Errors Framing Errors Hardware Overruns Buffer Overruns Time-out Errors Alignment Errors Figure 23 : message de contrôle WAN-Error-Notify Déscription des champs de la trame: Longueur totale en octets du message PPTP. L'entête est incluse. PPTP Message Type Valeur 1 pour un message de contrôle. Valeur 0x1A2B3C4D. Cette constante est utilisée comme test pour les paquets reçus. Control Message Type Valeur 14 pour indiquer le message Wan-Error-Notify. Reserved0 Ce champ doit être à 0. Peer's Call ID Call ID assigné par le client. Reserved0 Ce champ doit être à 1. CRC Errors Nombre de trames PPP reçues avec erreur CRC depuis le début de la session. Framing Errors Nombre d'erreurs dans les paquets PPP. Hardware Overruns Nombre de buffer over-runs en reception depuis le début de la session. Buffer Overruns Nombre de buffer over-runs depuis le début de la session. Time-out Errors Nombre de time-outs depuis le début de la session. Alignment Errors Nombre d'erreurs d'alignement depuis le début de la session. Travail de diplôme Tutorial VPN Page 28

6.2.9.4 Messages de gestion de la session PPP Set-Link-Info Le message de Set-Link-Info est un message de contrôle envoyé par le client pour paramétrer les options de PPP. Puisque ces options peuvent changer à tout moment pendant la vie de l'appel, le serveur doit pouvoir mettre à jour sa configuration dynamiquement et exécuter la négociation de PPP sur une session active de PPP. 16 bit 16 bit PPTP Message Type Control Message Type Reserved0 Peer's Call ID Reserved1 Send ACCM Receive ACCM Figure 24 : message de contrôle Set-Link-Info Déscription des champs de la trame: Longueur totale en octets du message PPTP. L'entête est incluse. PPTP Message Type Valeur 1 pour un message de contrôle. Valeur 0x1A2B3C4D. Cette constante est utilisée comme test pour les paquets reçus. Control Message Type Valeur 15 pour indiquer le message Set-Link-Info. Reserved0 Ce champ doit être à 0. Peer's Call ID Call ID assigné par le client. Reserved0 Ce champ doit être à 0. Send ACCM Valeur utilisé par le client pour traiter les paquets PPP sortants. La valeur par défaut est 0XFFFFFFFF. Receive ACCM Valeur utilisé par le client pour traiter les paquets PPP entrants. La valeur par défaut est 0XFFFFFFFF. Codes d'erreur généraux. Les codes d'erreurs généraux concernent des types d'erreurs qui ne sont pas spécifiques dans aucune requête particulière de PPTP, mais plutôt des erreurs de format de protocole ou de message. Si une réponse PPTP indique qu'une erreur générale s'est produite, la valeur générale d'erreur devrait être examinée. Les codes d'erreur généraux actuels définis et leurs significations sont: 0 (None) Aucune erreur générale 1 (Not-Connected) Connexion de contrôle inexistante 2 (Bad-Format) Longueur ou incorrects 3 (Bad-Value) Champs réservés non à 0, ou valeur incorrecte dans un champ 4 (No-Resource) Ressources insuffisantes pour exécuter l'opération 5 (Bad-Call ID) Identificateur d'appel Call ID incorrect 6 (Server-Error) Erreur générique dans le serveur Travail de diplôme Tutorial VPN Page 29

Les messages de contrôle sont envoyés dans des paquets TCP (port 1723). Une fois que la connexion est créée entre le client et le serveur, cette connexion de contrôle est utilisée pour l'échange de messages de contrôle Chaque datagramme contient une entête PPP, une entête TCP, un message de contrôle PPTP et des conteneurs appropriés. La figure suivante montre un datagramme PPTP avec des messages de contrôle. PPTP Control Message TCP IP Header PPP Delivery Header Figure 25 : Datagramme PPTP avec message de contrôle. L'échange de messages entre le client et le serveur PPTP à travers la connexion TCP est utilisé pour la création et le maintient du tunnel PPTP. Dans le cas que le client distant n'est pas habilité à l'usage de PPTP, mais par contre il utilise un ISP qui en est habilité, l'isp sera le client. Ceci dit, la connexion de contrôle se fera directement entre lui et le serveur. Toutefois, il faudra s'assurer que la connexion entre le vrai client et l'isp est sécurisée. Par exemple, lorsqu'on se connecte à travers une ligne téléphonique, l'on pourra dire que la connexion est déjà sécurisée, car on utilise un média non partagé. Par contre, dans le cas où l'on se connecterait en utilisant le CATV (Community Antenna TV), on ne pourra pas exclure la probabilité que personne nous espionne, compte tenu du type de média utilisé; le câble coaxial étant un média partagé. 6.2.10 Transmission de données PPTP Une fois que le tunnel PPTP est établi, les données de l'utilisateur sont transmises depuis le client vers le serveur PPTP. Ces données sont transmises dans des paquets PPP contenus dans des datagrammes IP. Les datagrammes IP sont générés à l'aide d'une version modifié du protocole GRE (Internet Generic Routing Encapsulation). 6.2.10.1 GRE IP 47 GRE (Internet Generic Routing Encapsulation) est un protocole générique pour l'encapsulation. La version utilisée par PPTP est légèrement différente par rapport au protocole GRE défini dans les RFC 1701 et 1702. La différence principale comporte la définition d'un nouveau champ d'accusé de réception, employée pour déterminer si un paquet de GRE ou un ensemble particulier de paquets est arrivé à l'extrémité distante du tunnel. Cette capacité d'accusé de réception n'est pas utilisée avec une retransmission des paquets de données utilisateur. Elle est employée pour déterminer la cadence à laquelle les paquets utiles doivent être transmis dans le tunnel pour une session donnée. L'entête IP donne les informations nécessaires à l'acheminement des datagrammes à travers Internet. L'entête GRE est utilisée pour encapsuler le paquet PPP dans le datagramme IP. A noter que le paquet PPP est un bloc non intelligible, car il est encrypté. Travail de diplôme Tutorial VPN Page 30

Le datagramme IP GRE créée par PPTP est montré par l'image suivante. 16 bit 16 bit C R K S s Recur A Flags Ver Protocol Type Key (HW) Payload Key (LW) Call ID Sequence Number (Optional) Acknowledgment Number (Optional) Figure 26 : Datagramme GRE Déscription des champs de la trame: C (bit 0) Checksum présent. Ce champ doit être à 0. R (bit 1) Routage présent. Ce champ doit être à 0. K (bit 2) Clé présente. Ce champ doit être à 1. S (bit 3) Numéro de séquence. Ce champ doit être à 1.si un paquet utile (données) est présent. Ce champ doit être à 0. si la charge utile n'est pas présente (le paquet de GRE est un accusé de réception seulement). S (bit 4) Routage de source présent. Ce champ doit être à 0. Recur (bits 5-7) Commande de récursivité. Ces champs doivent être à 0. A (bit 8) Numéro de séquence d'accusé de réception. Ce champ doit être à 1si le paquet contient le nombre d'accusé de réception. À utiliser pour reconnaître des données précédemment transmises. Flags (bits 9-12) Ces champs doivent être à 0. Ver (bits 13-15) Ce champ doit être à 1 (GRE avancé). Protocol Type Ce champ doit être à 0x0880B. Key Payload Taille des données utiles. L'entête GRE n'est pas incluse. Key Call ID Contient l'identificateur de l'appel pour cette session. Sequence Number Contient le numéro de sequence des données. Il est présent si le bit S (bit 3) est à 1. Acknowledgment Number Contient le numéro de séquence du paquet GRE reçu par le pair pour cette session d'utilisateur. Présent si le bit A (bit 8) est à 1. La figure suivante montre les différentes encapsulations des données utiles dans le cas de PPTP: Data TCP Header IP Header PPP Header GRE Header IP Header PPP Delivery Header Figure 27 : Encapsulation des données dans GRE dans le cas de PPTP. Travail de diplôme Tutorial VPN Page 31

6.2.11 Exemple de connexion Après avoir vu les différents types de messages dans le chapitre 6.2.9.1 on va donner l'exemple d'une connexion d'un client à un serveur PPTP, afin d'en montrer les différents échanges. Pour simplifier, on a pris le cas d'un client et d'un serveur se trouvant dans le même réseau. Dans la figure suivante sont montrés les échanges de ces messages. Start-Control-Request TCP 1723 Outgoing-Call-Request Start-Control-Reply Outgoing-Call-Reply GRE - IP 47 TCP 1723 Echo-Request Echo-Reply GRE - IP 47 TCP 1723 Clear-Call-Request Disconnect-Notify Figure 28 : Exemple d'ouverture, maintient et fermeture d'une connexion PPTP Travail de diplôme Tutorial VPN Page 32

6.2.12 La sécurité de PPTP 6.2.12.1 Authentification Une authentification initiale peut être exigée par le serveur d'accès réseau NAS de l'isp. Si cette authentification est exigée, elle doit être gérée par le serveur d'accès réseau de l'isp. Il faut vérifier avec l'isp les conditions d'authentification. La deuxième authentification est faite par le serveur PPTP même. C'est lui qui donne tout accès au réseau privé. C'est-à-dire, le serveur de PPTP est la passerelle du réseau privé. Tous les clients PPTP doivent fournir un nom et un mot de passe utilisateur. L'authentification des clients PPTP distants est faite en utilisant les mêmes méthodes d'authentification de PPP employées par n'importe quel client NAS. L'implémentation de Microsoft (et de Linux) du service d'accès à distance (NAS) supporte le protocole d'authentification CHAP (Challenge Handshake Authentication Protocol), le protocole d'authentification MS-CHAP (Microsoft Challenge Handshake Authentication Protocol) et protocole d'authentification PAP (Password Authentication Protocol). Les voilà de manière plus détaillée. PAP (Password Authentication Protocol) est un simple schéma d'authentification de texte en clair. Le NAS (Network Acces Server) demande le nom et le mot de passe d'utilisateur, et le PAP les envoie en clair (non codé). Evidemment ce schéma d'authentification n'est pas sûr, car un tiers pourrait capturer le nom et le mot de passe de l'utilisateur et l'employer pour obtenir un accès au NAS et à toutes les ressources fournies par le NAS. Une fois que le mot de passe de l'utilisateur est compromis, le PAP n'assure aucune protection contre les attaques d'usurpation d'identité. CHAP (Challenge Handshake Authentication Protocol) est un mécanisme d'authentification crypté qui évite la transmission du mot de passe en clair sur la connexion. Le NAS envoie au client distant une épreuve, qui se compose d'un identificateur de session et d'une chaîne de caractères générée aléatoirement. Le client distant doit employer l'algorithme de hachage MD5 à sens unique, pour renvoyer un chiffrement de l'épreuve, de l'identificateur de session, et du mot de passe du client. Le nom de l'utilisateur est envoyé en clair. Figure 29 : Processus CHAP. Le CHAP se présente en tant qu'une amélioration du PAP, car le mot de passe n'est pas envoyé en clair. Ceci dit, le mot de passe est employé, afin de créer un code de hachage de l'épreuve initiale. Le serveur connaît le mot de passe du client (en clair) et il doit faire, de son côté, la même opération de hachage. Ensuite, il compare le résultat au mot de passe introduit dans la réponse du client. Si les deux codes de hachage correspondent, l'utilisateur est authentifié. Le CHAP se protège contre les attaques d'usurpation d'identité à l'aide d'une chaîne de caractères d'épreuve. Chaîne générée aléatoirement pour chaque tentative d'authentification. Le CHAP se protège contre ces attaques en envoyant de manière imprévisible des épreuves répétées au client distant pendant toute la durée de la connexion. Travail de diplôme Tutorial VPN Page 33

MS-CHAP (Microsoft Challenge Handshake Authentication Protocol) est un mécanisme d'authentification chiffré, très semblable au CHAP. Comme dans CHAP, le serveur NAS envoie une épreuve au client. L'épreuve se compose d'un identificateur de session et d'une chaîne de caractères aléatoire. Le client distant emploie l'algorithme de hachage MD4 à sens unique, afin de renvoyer un chiffrement de l'épreuve, de l'identificateur de session, et du mot de passe du client. Cette conception, qui manipule les codes de hachage du mot de passe, fournit un niveau supplémentaire de sécurité. Le serveur possède les codes de hachage des mots de passe seulement, au lieu des mots de passe en clair. MS-CHAP fournit des codes d'erreur supplémentaires également, y compris un code pour les mots de passe expirés, et des messages chiffrés supplémentaires permettant à des utilisateurs de changer leurs mots de passe. Dans MS-CHAP, le client et le NAS produisent, chacun de leur côté, une première clé pour un chiffrement ultérieur par MPPE (Microsoft Point-to- Point Encryption). Par conséquent, l'authentification de MS-CHAP est exigée, afin de permettre le chiffrement de données basé sur MPPE. L'encryptage MPPE sera décrit dans le chapitre 6.2.14.1. Une gestion soigneuse des comptes d'utilisateur est nécessaire pour réduire les risques de sécurité. Avoir un modèle sûr de la structure des mots de passe est critique pour le bon déploiement de PPTP. Ceci, car les connexions Internet sont plus susceptibles d'être attaquées : des crackers pourraient essayer des milliers de combinaisons de mot de passe et de nom d'utilisateur, afin de s'introduire dans le réseau privé. La seule façon de réduire au minimum ce type d'attaque est de choisir une politique de mot de passe sûre. Par exemple, une bonne politique consisterait à exiger l'usage de mots de passe contenant un mélange de lettres majuscules, minuscules, ainsi que de nombres, et de caractères spéciaux. 6.2.13 Contrôle d'accès Après l'authentification, tout accès au réseau local privé continue à utiliser le modèle de sécurité interne. Par exemple, si on utilise un sous-réseau utilisant des serveurs WinNT, les accès aux ressources NTFS partagées continueront à exiger les permissions appropriées, même pour les accès des clients PPTP. 6.2.14 Le chiffrement de données Pour le chiffrement de données, PPTP utilise le procédé de chiffrement "shared-secret", ou secret partagé, du NAS. Il est désigné sous le nom de secret partagé, car les deux bouts de la connexion partagent la même clé de chiffrement. Dans l'implémentation de Microsoft, le secret partagé est le mot de passe de l'utilisateur. D'autres méthodes de chiffrement se basent sur des clés publiques; cette deuxième méthode de chiffrement est connue en tant que chiffrement par clé publique. PPTP utilise les mêmes schémas de chiffrement et de compression que PPP. Le CCP (Compression Control Protocol) employé par PPP est utilisé pour négocier le type d'encryption. Le nom d'utilisateur et le mot de passe du client de PPTP sont disponibles au serveur de PPTP et sont fournis par le client de PPTP. Une clé d'encryption est dérivée par les mots de passe hachés, qui se trouvent enregistrés sur le client et le serveur. Le standard RSA RC4 est utilisé pour la création de cette clé de session de 40-bit ou de 128-bit. La clé étant basée sur le mot de passe du client. Cette clé est employée pour le chiffrement de toutes les données qui traversent le tunnel PPTP; ceci assure une connexion privée et sûre. Les données dans les paquets PPP sont chiffrées. Le paquet PPP contenant un bloc de données encryptées est encapsulé dans un datagramme IP pour le routage à travers Internet du paquet à destination du serveur PPTP. Si un intrus interceptait votre datagramme IP, il trouverait seulement les entêtes IP, et le paquet PPP contenant le bloc de données encryptées, qui se présenterait indéchiffrable. Travail de diplôme Tutorial VPN Page 34

6.2.14.1 Cryptage MPPE PPTP hérite le chiffrement MPPE, qui utilise le chiffrage RC4 de RSA (Rivest-Shamir-Adleman). MPPE est seulement disponible quand MS-CHAP (version 1 ou version 2) est utilisé. MPPE peut utiliser 40 bit, 56 bit ou des clés de chiffrement de 128 bit. La clé 40 bit fournit la compatibilité avec des clients utilisant des anciennes versions de Windows. Par défaut, la clé la plus grande supportée par le client VPN et le serveur VPN est négociée pendant le processus d'établissement de connexion. Si le serveur VPN exige une clé plus résistante que celle supporté par le client, la tentative de connexion est rejetée. MPPE a été initialement conçu pour le chiffrement avec un lien point à point, où les paquets arrivent dans la même ordre dans laquelle ils ont été envoyés. Dans cet environnement, le déchiffrage de chaque paquet dépend du déchiffrage du paquet précédent. Pour les VPN, cependant, les datagrammes IP envoyés à travers Internet arrivent dans un ordre différent de celle dans laquelle ils ont été envoyés, et une partie des paquets peut être détruite. Par conséquent MPPE change la clé de chiffrement pour chaque paquet. Le déchiffrage de chaque paquet est indépendant du paquet précédent. MPPE inclut un numéro de séquence dans son entête. Si des paquets sont détruits ou ont des erreurs, les clés de chiffrement sont changées relativement au numéro de séquence. 6.2.14.2 Filtrage de paquet PPP Les activités malveillantes peuvent être limitées en activant le filtrage sur le serveur PPTP. Quand le filtrage PPTP est activé, le serveur reçoit et route seulement les paquets des utilisateurs authentifiés. Ceci empêche à tous les autres paquets d'entrer dans le réseau privé. Avec le chiffrement de PPP, ceci assure que seulement les données chiffrées autorisées entrent ou sortent du réseau privé. 6.2.15 Usage de PPTP avec des firewalls PPTP utilise le port 1723 de TCP, et le protocole IP 47, en tant qu'assigné par le IANA (Internet Assigned Numbers Authority). PPTP peut être utilisé avec la plupart des firewalls en permettant le trafic destiné au port TCP 1723 d'être routé à travers le firewall ou le routeur. Les firewalls assurent la sécurité du réseau en filtrant les données qui le traversent. Une organisation peut mettre son serveur PPTP derrière un firewall. Le serveur PPTP reçoit les paquets de PPTP passés par le firewall et extrait les paquets PPP à partir du datagramme IP, déchiffre le paquet, et expédie le paquet à l'ordinateur sur le réseau privé. Figure 30: Serveur PPTP derrière un firewall. Travail de diplôme Tutorial VPN Page 35

6.3 L2TP Layer 2 Tunneling Protocol PPP (RFC1661. Voir CD annexe) définit un mécanisme d'encapsulation multiprotocole pour le transport des paquets à travers des connexions de la couche 2 (L2). Typiquement, un utilisateur obtient une connexion L2 à un serveur d'accès réseau (NAS) en utilisant par exemple une ligne analogique, une ligne RNIS, ADSL, etc. et crée alors un tunnel PPP à travers cette connexion. Dans une telle configuration, le point de terminaison de L2 et le point final de la session PPP résident dans le même dispositif physique. L2TP étend le modèle PPP, permettant ainsi aux points finaux de la connexion L2 et PPP de résider sur des dispositifs différents interconnectés par un réseau de commutation de paquets. Avec L2TP, un utilisateur a une connexion L2 avec un concentrateur d'accès (par exemple, un modem, ADSL, etc.), et le concentrateur envoie dans le tunnel les différentes trames PPP à destination du NAS. Ceci permet au traitement des paquets PPP d'être séparés de la terminaison du circuit L2. Un avantage évident d'une telle séparation est qu'à la place d'exiger la terminaison de la connexion L2 au NAS (qui peut exiger un appel long distance coûteux), la connexion peut se terminer au concentrateur de circuit local, lequel étend la session PPP logique au-dessus d'une infrastructure partagée telle que Frame Relay ou Internet. Du point de vu de l'utilisateur, il n'y a aucune différence fonctionnelle entre avoir directement la terminaison du circuit L2 au NAS ou en utilisant L2TP. 6.3.1 Vue d'ensemble du protocole L2TP utilise deux types des messages: des messages de contrôle et de messages de données. Les messages de contrôle sont utilisés dans l'établissement, l'entretien et l'effacement des tunnels et des appels. Les messages de données sont utilisés pour l'encapsulation des trames PPP dans le tunnel. Les messages de contrôle utilisent un canal fiable pour en garantir la livraison. Les messages de données ne sont pas retransmis quand un erreur survient. PPP Frames L2TP Data Messages L2TP Control Messages L2TP Data Channel L2TP Control Channel (unreliable) (reliable) Packet Transport (UDP, FR, ATM, etc.) Figure 31 : Structure du protocole L2TP La figure précédente montre le rapport des trames PPP et des messages de contrôle au-dessus des canaux de contrôle et de données de L2TP. Les trames PPP sont envoyées dans un canal de données, encapsulés d'abord par une entête L2TP et puis dans un paquet de transport tel que UDP, Frame Relay, ATM, etc. Les messages de contrôle sont envoyés dans un canal fiable L2TP qui transmet des paquets inband au-dessus du même paquet de transport. Les numéros de séquence sont exigés dans tous les messages de contrôle et sont employés pour fournir une livraison fiable dans le canal. Les messages de données peuvent employer des numéros de séquence pour demander à nouveau des paquets et pour détecter les paquets perdus. Toutes les valeurs sont placées dans leurs champs respectifs et introduites dans la commande (octets d'ordre supérieur d'abord). Travail de diplôme Tutorial VPN Page 36

6.3.2 Format de l'entête L2TP Les paquets L2TP pour le canal de contrôle et des données partagent un format commun d'entête. Dans tous les cas où un champ est facultatif et marqué comme non présent, son espace n'est pas utilisé dans le message. À noter que les champs, Ns et Nr. Fields marqués comme facultatifs pour des messages de données, sont requis pour tous les messages de contrôle. 16 bit 16 bit T L x x S x O P x x x x Ver (opt) Tunnel ID Session ID Ns (opt) Nr (opt) Offset Size (opt) Offset pad... (opt) Figure 32 : Entête L2TP. Déscription des champs de la trame:: Type (T) (L) x Sequence (S) Offset (O) Priority (P) Ver Tunnel ID Session ID Ns Indique le type du message. Il peut avoir les valeurs suivantes: 0 Message de données 1 Message de contrôle Si à 1, le champ existe. Ce bit doit être à 1 pour tous les messages de contrôle. Les bits 'x' sont réservés pour des extension futures du protocole. Ces bits doivent être à 0 pour les messages sortant et ignorés pour les messages entrants. Si à 1, le champ Ns et Nr existent. Ce bit doit être à 1 pour tous les messages de contrôle. Si à 1, le champ Offset existe. Ce bit doit être à 1 pour tous les messages de contrôle. Si à 1, le traitement de ce message de données doit être prioritaire dans la queue locale et dans la transmission. Les echo-requests utilisés pour maintenir la connexion doivent être envoyés avec ce bit à 1, sinon peut arriver une congestion temporaire et une perte de données. Cette fonctionnalité est utilisée seulement avec des messages de données. Ce bit doit être à 0 pour tous les messages de contrôle. Ce champ doit valoir 2. Il indique la version de l'entête L2TP pour des paquets de données. Ce champ indique la longueur du message en octets. Indique l'identificateur pour la connexion de contrôle. Les tunnels L2TP sont nommés par des identificateurs qui ont une signification locale seulement. C'est-à-dire, pour le même tunnel sera donné un ID différent pour chaque extrémité du tunnel. Indique l'identificateur pour une session dans un tunnel. Les sessions L2TP sont nommées d identificateurs qui ont une signification locale seulement. C'est-à-dire, pour la même session sera donnée un ID différent pour chaque extrémité de la session. Indique le numéro de séquence pour ce message de données ou de contrôle, commençant à 0 et incrémentant par un (modulo 2 16 ) pour chaque message envoyé. Travail de diplôme Tutorial VPN Page 37

Nr Offset Size Indique le numéro de séquence prévu pour le prochain message de contrôle reçu. Ainsi, Nr est placé au NS du dernier message de contrôle reçu plus un (modulo 2 16 ). Dans les messages de données, Nr est réservé et, si présent (comme indiqué par le bit S), il doit être ignoré à la réception. Si présente, indique le nombre d'octets après l'entête L2TP à partir desquels on s'attend le début des données utiles. 6.3.3 Connexion de contrôle L2TP Le protocole L2TP défini une série de messages de contrôle échangés entre le client et le serveur L2TP. Ces commandes établissent, maintiennent et terminent le tunnel L2TP. La liste suivante représente les messages utilisés pour établir et maintenir le tunnel. Messages de gestion de la connexion: START_CONTROL_CONNECTION_REQUEST START_CONTROL_CONNECTION_REPLY START_CONTROL_CONNECTION_CONNECTED STOP_CONTROL_CONNECTION_NOTIFICATION HELLO Demande de début de session Réponse à la demande de début de session Confirmation à la demande de début de session Fin de session Demande de maintient la session de contrôle Messages de gestion du tunnel: OUTGOING_CALL_REQUEST OUTGOING_CALL_REPLY OUTGOING_CALL_CONNECTED INCOMING_CALL_REQUEST INCOMING_CALL_REPLY INCOMING_CALL_CONNECTED DISCONNECT_CALL_NOTIFY Demande de création du tunnel de la part du client Réponse à la demande de création du tunnel de la part du client Tunnel en sortie crée Demande de création du tunnel de la part du serveur Réponse à la demande de création du tunnel de la part du serveur Tunnel en entrée crée Réponse à la demande de terminaison et fin de la session PPTP Messages d'erreurs: WAN_ERROR_NOTIFY Erreur dans la connexion PPP Messages de gestion de la session PPP: SET_LINK_INFO Configure la connexion entre le client et le serveur Travail de diplôme Tutorial VPN Page 38

6.4 IPSec IP Security Protocol Créé par l'ietf 3, le protocole IPSec est conceptuellement unique, car il permet de sécuriser le réseau même, et ne pas les applications l'exploitant. Le protocole IPSec garantit la sécurité pour chaque application utilisant le réseau. IPSec permet donc la réalisation de VPN très sûres. On doit forcement utiliser IP 4 pour le transport des données, afin de pouvoir sécuriser un réseau avec IPSec. La force fondamentale de cette approche est son fonctionnement à des couches de bas niveau. Comme IP est transparent aux utilisateurs, IPSec l'est aussi en rajoutant une couche qui permet d'assurer la sécurité et l'intégrité des communications. 6.4.1 Architecture de IPSec Pour assurer la sécurité dans un environnement réseau, il faut s'assurer: Que la personne avec laquelle on communique est réellement cette personne et pas quelqu'un d'autre! Que personne ne peut écouter la communication! Que les données reçues n'ont pas étés modifiés pendant la transmission! Ces trois besoins sont traduits en: Authentification; Confidentialité; Intégrité. Malheureusement, l'architecture des réseaux basée sur IP, permettent difficilement d'assurer ces besoins. IPSec offres trois technologies, qui combinées entre elles permettent de se protéger des différentes attaques à la sécurité: Authentication header (AH) Entête qui attache les données de chaque paquet à une signature qui vous permet de vérifier l'identité de la personne envoyant les données et que les données n'ont pas été modifiées. Encapsulating Security Payload (ESP) Embrouille les données (et même certaines adresses IP sensibles) de chaque paquet en utilisant le chiffrement dur de noyau - ainsi un renifleur quelque part sur le réseau n'obtiendra rien d'utilisable. Internet Key Exchange (IKE) Un protocole puissant flexible de négociation qui permet à des utilisateurs de convenir sur des méthodes d'authentification, les méthodes de chiffrement, les clés d'utilisation, le temps d'utilisation des clés avant de les changer, et qui permet l'échange intelligent et sûr des clés. Le document de référence RFC 2401 (voir CD annexe) décrit les bases de l'architecture IPSec. Il définit les services de sécurité, la structure des paquets de ces services et quand ils peuvent être utilisés. 3 Internet Engineering Task Force 4 IPSec peut être utilisé avec le standard existant IPv.4 et celui mandataire IPv.6 Travail de diplôme Tutorial VPN Page 39

IPSec implémente deux protocoles : le AH et le ESP. Ces protocoles permettent à IPSec de travailler selon deux modes distincts. Si on veut sécuriser tant les données que toute la couche IP, on utilisera le mode Tunnel, tandis que si on veut sécuriser seulement les données on préférera le mode Transport. Le mode Transport est utilisé pour l'acheminement direct des données protégées par IPSec. Il sert donc pour des configurations Host-to-Host. Dans ce mode, les protocoles AH et ESP protègent la couche transport en interceptant les paquets provenant de la couche transport dans la couche réseau. Application Application TCP UDP TCP UDP IPSec IPSec IP IP Figure 33 : Mode transport d'ipsec. Dans le mode Tunnel, utilisé en général pour des configurations LAN-to-LAN, le trafic non protégé est envoyé vers une passerelle implémentant IPSec. Comme le montre la figure suivante, le gateway encapsule tout le paquet IP, entête comprise, avec l'encryptage de IPSec. Il rajoute ensuite une nouvelle entête IP et envoie ce nouveau paquet à travers le réseau public vers le gateway destinataire. Là, les paquets sont ensuite déchiffrés et envoyés sous forme originale àsa propre déstination. Application Application Données Données TCP UDP protégées protégées TCP UDP IP IP IPSec IP Gateway IPSec Figure 34 : Mode tunnel d'ipsec. IPSec IP Gateway IPSec Une option importante de IPSec dans le domaine des VPN est la gestion des clés de chiffrage et d'authentification. Cette gestion peut être manuelle ou automatique avec le protocole IKE. Ce dernier aspect fera l'objet d'une présentation plus détaillé dans le chapitre 6.4.4. Pour pouvoir encapsuler et désencapsuler les paquets IPSec, on doit pouvoir en déterminer le sens de transmission. Ceci, afin de pouvoir associer les différents services de sécurité et les clés avec le trafic unidirectionnel. Une telle construction est appelée SA (Security Association). Une SA est identifiée par : Un Security Parameter Index (SPI); Le protocole IPSec utilisé; L'adresse de destination. La SA peut être créée de façon dynamique (dans le cas d'utilisation de IKE), soit manuellement (gestion des clés manuelles). Le temps de vie d'une SA (SA life time) dépend des paramètres choisis lors de sa création. Dans le cas d'une génération manuelle, son temps de vie est infini, jusqu'à quand la modification d'un paramètre interviendra. Tandis que dans le cas d'une génération dynamique, son temps de vie est généralement définit par les deux extrémités lors de la phase de négociation des paramètres (IKE). Travail de diplôme Tutorial VPN Page 40

6.4.2 AH (Authentication Header) Ce protocole implémente les services d'authentification mais non ceux de confidentialité. Il permet donc d'assurer la garantie de l'origine des paquets et l'intégrité des données. L'anti-replay est facultatif et peut être choisi par le récepteur, lors de l'établissement de la SA. Bien que I'expéditeur incrémente le numéro de séquence utilisé pour l'anti-replay, le service se relève pertinent uniquement si le récepteur le contrôle. Pour autant que possible, AH procure l'authentification de l'entête IP et de ses données. En effet, dans l'entête IP se trouvent des champs comme le Type of Service, Flags, Fragment Offset, Time to live et Header Checksum qui peuvent changer en cours de transfert. La valeur de ces derniers n'est donc pas prévisible par l'expéditeur. Les valeurs de ces champs ne peuvent ainsi pas être protégées par AH. Ceci dit, la protection assurée par AH n'est que partielle. Le protocole AH peut être appliqué seul (mode transport), en combinaison avec ESP, ou en mode tunnel. Il peut être utilisé pour des communications Host-to-Host, LAN-to-LAN, soit Host-to-LAN. ESP peut être utilisé pour fournir les mêmes services d'authentification, il fournit également un service de confidentialité avec chiffrement. La différence entre l'authentification fournie par ESP et AH réside dans la portion des données sécurisées. ESP ne protège aucun champ d'entête IP, à moins que ESP soit utilisé en mode tunnel (v. chapitre 6.4.3). Aucune encryption des données est effectué par le protocole AH, toutefois il définit la méthode de protection, le placement de l'entête, la portion couverte par l'authentification et les règles de traitement des données entrantes et sortantes. Cependant, il ne définit pas l'algorithme d'authentification à utiliser. Actuellement deux algorithmes sont utilisés : HMAC-MD5 et HMAC-SHA. 6.4.2.1 Format de l'entête AH Dans le cas de AH, le champ Protocol type du paquet IP vaut 51. Ceci dit, si ce champ IP vaut 51, cela signifie que le protocole de couche supérieur sera AH. AH reste toujours placé après l'entête ESP, lorsque AH et ESP protègent le même paquet. La figure suivante montre le format de l'entête AH : 16 bit 16 bit Next Header Payload Reseved Security Parameters Index (SPI) Sequence number Authentication data Figure 35 : Entête du protocole AH. Déscription des champs de la trame : Next header Payload length Reserved SPI Ce champ indique le protocole de couche supérieur. En mode transport, ce champ indique la première entête protégée (TCP ou UDP), tandis qu'en mode tunnel, il vaut 4, ce qui correspond à l'identificateur pour le protocole IP. Taille de l'entête. N'est pas utilisé et il est réservé pour des applications futures. Ce champ doit être à 0. Le SPI correspond à une valeur de 32 bits arbitraire qui, en alliance avec l'adresse IP de destination et du protocole de sécurité (AH) identifie la SA qui doit être utilisé pour authentifier ce paquet. Elle est d'habitude choisie par Ie système destinataire, lors de l'établissement de la SA. Travail de diplôme Tutorial VPN Page 41

Sequence number Authentication data Numéro de séquence de 32 bits auto incrémenté, employé pour se protéger d'une retransmission du paquet (fonction d' anti-replay). Ce champ est obligatoire et toujours présent même si le récepteur désactive la fonction d'anti-replay. La longueur de ce champ dépend de I'algorithme d'authentification utilisé. II contient le résultant du calcul de l'intégrité du message ICV (Integrity Check Value) suivi d'un remplissage avec des 0, pour que le champ soit multiple de 32 bits. 6.4.2.2 Emplacement de I' entête d'authentification AH peut être utilisé tant en mode transport qu'en mode tunnel, comme ESP. Le mode transport s'applique seulement aux applications Host-to-Host et il assure la protection des protocoles des couches supérieures, ainsi que des champs non modifiables de l'entête IP. AH s'insère à la suite de l'entête IP et avant les protocoles de couches supérieurs comme par exemple TCP, UDP, ICMP ou préalablement à tous les autres entêtes IPSec qui ont déjà été insérées. La figure suivante montre l'entête AH dans le mode transport: Original IP Header Next Header Payload Reserved Security Parameters Index (SPI) Sequence Number Authentication data IP Payload Authentifié Figure 36 : AH en mode Transport En mode tunnel, l'entête IP originale est placée à la suite de AH et inclut les adresses de source et de destination finales, alors que la nouvelle entête IP, placée antérieurement à AH, comporte les adresses des gateways. AH protège l'entête IP originale et ses données de même que les champs non modifiables de la nouvelle entête IP. La figure suivante montre l'entête AH en mode tunnel. New IP Header Next Header Payload Reserved Security Parameters Index (SPI) Sequence Number Authentication data Original IP Header IP Payload Figure 37 : AH en mode Tunnel. Authentifié Travail de diplôme Tutorial VPN Page 42

6.4.2.3 Traitement des paquets sortants Le protocole AH, pour les paquets sortants, est utilisé seulement si configuré préalablement dans l'implémentation IPSec utilisé. La génération du numéro de séquence est réalisée comme suit : Lorsque la SA est établie, le compteur de l'expéditeur et le compteur du récepteur sont initialisés à 0. L'émetteur incrémente le numéro de séquence pour sa propre association et annonce la nouvelle valeur dans le champ du numéro de séquence. Ceci dit, le premier paquet envoyé en utilisant la SA donnée vaudra 1. Le numéro de séquence transmis ne doit jamais faire un cycle complet. Si l'anti-replay est autorisé, l'expéditeur contrôle la valeur du numéro de séquence, afin de s'assurer que le compteur n'aurait pas fait un cycle complet avant d'insérer celle-ci dans le champ prévu. Cela dit, l'ordinateur de l'expéditeur et le compteur du récepteur doivent être remis à l'état initial en établissant nouvelle SA et ainsi une nouvelle clé, sauf si gestion manuelle, avant la transmission du paquet 2 32 de la SA en cours. Les autres champs de l'entête sont ensuite mis à jour : le champ SPI aura donc la valeur définie par la SA, le champ next header aura la valeur du protocole suivant AH, le champ payload length sera calculé et le champ authentication data sera mis à 0. Enfin les bits restants de l'entête seront mis à 0, afin d'avoir l'entête multiple de 32 bit. Le champ ICV (lntegrity Check Value) est calculé avec l'algorithme d'authentification définit par la SA et utilisant comme paramètres la clé d'authentification et le datagramme IP, entête AH incluse. Les champs modifiables, n'étant pas pris en compte dans le calcul de l'icv, doivent être mis à 0 avant ce calcul. Ensuite la valeur résultante est placée dans le champ de l'entête AH et les champs modifiables reprennent leurs valeurs. Le traitement est maintenant terminé et le datagramme peut être envoyé. Le datagramme peut être fragmenté, en fonction de la taille du paquet. 6.4.2.4 Traitement des paquets entrants Si les datagrammes IP ont été fragmentés, ils doivent être réassemblés avant leur traitement. La première opération à effectuer consiste à identifier la SA utilisée, afin de protéger le paquet entrant. Cette identification est faite à l'aide de l'adresse de destination, du protocole utilisé (dans le cas de AH, le protocole IP 51) et le SPI. Si aucune SA n'est identifiée, le paquet est ignoré. Une fois la SA reconnue, on procède par la vérification du numéro de séquence. Cette étape est optionnelle, en fonction de l'activation de l'anti-replay. Cette vérification détermine s'il s'agit d'un nouveau ou d'un ancien paquet qui a été déjà reçu. Si ce contrôle révèle la présence d'un paquet déjà reçu, celui-ci est ignoré. Ceci dit, le contrôle de l'icv peut être effectué. L'ICV reçu est mémorisé et son champ est mis à 0, de même que tous les champs modifiables. Ensuite l'algorithme d'authentification est appliqué au paquet IP pour le calcul d'un nouvel ICV. Si le paquet correspond à celui sauvegardé précédemment, il est authentifié, autrement rejeté. La vérification étant terminée, le paquet peut être transmis à la couche supérieure. Travail de diplôme Tutorial VPN Page 43

6.4.3 ESP (Encapsulating Security Payload) Le protocole ESP (Encapsulating Security Payload) est utilisé, afin de garantir : La confidentialité des données; L'authentification de l'origine des données; La protection d'anti-replay; L'intégrité des données (sans connexion, par paquet). La grande différence entre l'authentification fournie par AH et celle fournie par ESP se trouve dans le protocole ESP. Avec ce protocole les données contenues dans l'entête IP ne sont pas authentifiées. De même que pour AH, le service d'anti-replay est optionnel. La décision d'activer ce service est à la charge du destinataire du paquet. ESP fournit le service de la confidentialité avec un algorithme de cryptage et l'intégrité des données avec un algorithme d'authentification. Ces algorithmes doivent absolument être les mêmes pour les deux extrémités de la SA utilisant ESP. 6.4.3.1 Format de l'entête ESP Dans le cas de ESP, le champ Protocol type du paquet IP vaut 50. Ceci dit, si ce champ IP vaut 50, cela signifie que le protocole de couche supérieur seraesp. La figure suivante montre le format de l'entête ESP : 16 bit 16 bit Security Parameters Index (SPI) Sequence number Initialization vector Protected data Padding Pad Authentication data Figure 38 : Entête du protocole ESP. Next Header Description des champs de la trame : SPI Sequence number Protected data Le SPI correspond à une valeur de 32 bits arbitraire qui, en alliance avec l'adresse IP de destination et du protocole de sécurité (AH) identifie la SA qui doit être utilisé pour authentifier ce paquet. Elle est d'habitude choisie par Ie système destinataire, lors de l'établissement de la SA.. Ce champ est authentifié, mais pas encrypté. Numéro de séquence de 32 bits auto incrémenté, employé pour se protéger d'une retransmission du paquet (fonction d' anti-replay). Ce champ est obligatoire et toujours présent même si le récepteur désactive la fonction d'anti-replay. Le traitement de ce champ est fait uniquement par le récepteur et l'expéditeur doit toujours le transmettre. Ce champ est également authentifié, mais pas encrypté pour la faciliter la détection des répétitions des paquets. Ce champ contient les données chiffrées, de même que le vecteur d'initialisation. Ce dernier est utilisé avec l'algorithme d'encryption, afin de Travail de diplôme Tutorial VPN Page 44

Padding Padding length Next header Authentication data produire la confidentialité des données. Ce champ est également authentifié, toutefois pas encrypté. Généralement, il est placé dans les huit premiers bytes du champ protected data. Ce champ sert d'alignement pour le protocole ESP. Certains algorithmes de cryptage nécessitent que la longueur du datagramme soit un multiple exact d'un nombre fixe de bytes. En fonction de l'algorithme employé, ce champ sera rempli par des 0 jusqu'à l'obtention du multiple désiré. Ce champ donne la longueur du champ padding. Ce champ indique le protocole de couche supérieur. En mode transport, ce champ indique la première entête protégée (TCP ou UDP), tandis qu'en mode tunnel, il vaut 4, qui correspond à la valeur pour le protocole IP. La longueur de ce champ dépend de I'algorithme d'authentification utilisé. II contient le résultant du calcul de l'intégrité du message ICV (Integrity Check Value) suivi d'un remplissage avec des 0, pour que le champ soit multiple de 32 bits. 6.4.3.2 Emplacement de l'entête ESP Comme AH, ESP peut être utilisé tant en mode transport qu'en mode tunnel. En mode transport, ESP s'inséré à la suite de l'entête IP et avant les protocoles de couche supérieurs comme par exemple TCP, UDP, ICMP ou préalablement à tous les autres entêtes IPSec qui ont déjà été insérées. La figure suivante montre l'entête ESP dans le mode transport: Encrypté Original IP Header Security Parameters Index (SPI) Sequence Number Initialization vector IP Payload Padding Pad Next Header Authentication data Figure 39 : ESP en mode Transport Authentifié En mode tunnel, l'entête IP originale est placée à la suite de ESP et elle inclut les adresses de source et de destination finales, alors que la nouvelle entête IP, placée antérieurement à ESP, comporte les adresses des gateways. ESP protège l'entête IP originale et ses. La figure suivante montre l'entête ESP en mode tunnel. Encrypté New IP Header Security Parameters Index (SPI) Sequence Number Initialization vector Original IP Header IP Payload Padding Pad Next Header Authentication data Figure 40 : ESP en mode Tunnel. Authentifié Travail de diplôme Tutorial VPN Page 45

6.4.3.3 Traitement des paquets sortants Le protocole ESP, pour les paquets sortants, est utilisé seulement si configuré préalablement dans l'implémentation IPSec utilisé. Dans le mode transport, I'entête ESP est insérée dans le paquet sortant immédiatement après l'entête IP. Le champ protocol type de l'entête IP est copié dans le champ next header de ESP et il est remplacé par la valeur 50 qui correspond au protocole ESP. Dans le mode tunnel, l'entête ESP est insérée avant I'entête IP. Le champ next header ESP prend la valeur 4 (qui correspond au protocole IP). Les autres champs de l'entête sont ensuite mis à jour: Le champ SPI aura donc la valeur définie par la SA,. le champ sequence number prend la valeur du prochain numéro de séquence (soit 0 s'il s'agit du premier paquet émis par la SA). Enfin les champs padding et padding length seront calculés et afféctés. La suite des opérations est indépendante du mode utilisé. Le paquet est encrypté avec l'algorithme définit par la SA. Cet encryptage commence au début des données utiles jusqu'à la fin du champ next header. Ensuite, le paquet est authentifié par I'algorithme définit par la SA depuis le début de l'entête ESP jusqu'à la fin du champ next header. Le résultat de l'algorithme d'authentification est inséré dans le champ authentication data. La dernière étape à effectuer avant d'envoyer le paquet est de recalculer le checksum de I'entête IP qui précède ESP. Le traitement est maintenant terminé et le datagramme peut être envoyé. 6.4.3.4 Traitement des paquets entrants Lorsque le récepteur reçoit un paquet ESP, il ne connaît pas le mode d'encapsulation utilisé. Pour savoir si le mode employé était celui de transport ou de tunnel, il doit se baser uniquement sur les informations de la SA associée. En fait, avant que le paquet soit décrypté, il n'y a aucun moyen pratique de connaître le mode employé. Ceci, pour se protéger des personnes malintentionnées qui pourraient analyser le réseau en cherche de ces informations. La première opération à effectuer consiste à identifier la SA utilisée, afin de protéger le paquet entrant. Cette identification est faite à l'aide de l'adresse de destination, du protocole utilisé (dans le cas de ESP, le protocole IP 50) et le SPI. Si aucune SA n'est identifiée, le paquet est ignoré. Une fois la SA reconnue, on procède par la vérification du numéro de séquence. Si ce dernier est valide, cela signifie qu'il n'a jamais été utilisé et qu'il doit être en séquence avec la fenêtre contenue dans la SA. Ceci dit, le contrôle de l'icv peut être effectué. L'ICV reçu est mémorisé et son champ est mis à 0, de même que tous les champs modifiables. Ensuite l'algorithme d'authentification est appliqué au paquet IP pour le calcul d'un nouvel ICV. Si le paquet correspond à celui sauvegardé précédemment, il est authentifié, autrement rejeté. La vérification étant terminée, le paquet peut être transmis à la couche supérieure. La seconde étape corresponde à l'authentification du paquet. L'algorithme d'authentification est appliqué à toute la trame sauf au champ authentication data, pour le calcul d'un nouvel ICV. Si le paquet correspond à celui du champ authentication data, il est authentifié, autrement rejeté. Le paquet ESP est ensuite décrypté à I'aide de la clé et de I ' algorithme défini par la SA depuis le début des données utiles jusqu'à la fin du champ next header. Une fois le paquet authentifié et décrypté, il peut être envoyé à la couche supérieure s'il s'agit du mode transport (le poste ayant effectué ces opérations étant le destinataire du message) ou envoyé au vrai destinataire s'il s'agit du mode tunnel (le destinataire du message n'étant pas le même dispositif). Travail de diplôme Tutorial VPN Page 46

6.4.4 IKE (Internet Key Exchange) Avant que les paquets puissent être sécurisés par IPSec, une association de sécurité SA doit exister. Elle peut être créée manuellement ou dynamiquement. Le protocole IKE (Internet Key Exchange) est utilisé pour la création dynamique de la SA. Le protocole IKE, qui est décrit par décrit par le document RFC 2409 (voir CD annexe), est un protocole hybride. II est basé sur le protocole ISAKMP (Internet Security Association and Key Management Protocol) et il implémente une partie des protocoles de gestion des clés. Ces protocoles sont Oakley et SKEME. Il utilise les bases d'isakmp, les modes de Oakley (RFC 2412. Voir Cd annexe) et les techniques de partage des clés de SKEME. 6.4.4.1 ISAKMP ISAKMP permet la définition de la communication entre deux pairs, comment sont construit les messages qu'ils utilisent dans cette communication, et les différentes étapes qu'ils doivent passer pour la sécuriser. ISAKMP donne les éléments nécessaires à I'authentification d'un pair, à I'échange d'informations pour l'échange des clés et à la négociation des services de sécurité. Les messages transmis dans un échange ISAKMP sont structurés sous forme d'une chaîne de données utiles attachés à une entête d'isakmp, comme montré par la figure suivante. Next Payload 16 bit 16 bit Initiator cookie Responder cookie Major Version Minor Version Message ID Message Figure 41 : Entête ISAKMP. Exchange Type Flags Description des champs de la trame : Initiator cookie (8 bytes) Cookie du dispositif qui a initié l'établissement, la modification ou la suppression de la SA. Responder cookie (8 bytes) Cookie de l'entité qui a répondu à la demande d'initiation de I'établissement, la modification ou la suppression de la SA. Next payload Indique le type des premières données utiles contenues dans le message. Major/Minor version Indique la version d'isakmp utilisé. Exchange type Indique le type d'échange utilisé et défini I'ordre des messages et des données utiles de I'échange ISAKMP. Flags Indiquent les différentes options contenues dans le message. Ces options peuvent être: Encryption, Commit ou Authentication only. Message ID Identificateur unique du message. Message length Longueur totale du message. La structure des données définies par ISAKMP est toujours la même et elle est montré par la figure suivante : 16 bit 16 bit Next Header Reserved Payload Figure 42 : Entête générique de ISAKMP. Travail de diplôme Tutorial VPN Page 47

Certains de ces messages dépendent les un des autres. Par exemple, le security association payload encapsule un proposal payload, qui lui-même contient un transform payload. Les messages définis dans ISAKMP sont : Hash payload : il contient le message condensé d'une fonction de hachage particulière; Signature payload : il contient la signature numérique; Nonce payload : il contient certaines informations pseudo aléatoires nécessaires à I'échange; Vendor ID payload : c'est l'identificateur du fournisseur. Chaque fournisseur y place les informations qu'il souhaite; Key exchange payload : il contient les informations nécessaires pour effectuer I'échange des clés; security association payload; Certificate payload; Identification payload; Proposal payload : il contient une simple proposition pour la SA et un/des transform payload; Transform payload : il contient un certain nombre d'attributs permettant de mettre en oeuvre la proposition contenue dans le proposal payload. La structure d'un message SA pourrait être la suivante : Security Association payload Next payload: NONE (0) : 52 Domain of interpretation: IPSEC (1) Situation: IDENTITY (1) Proposal payload Next payload: NONE (0) : 40 Proposal number: 1 Protocol ID: ISAKMP (1) SPI size: 0 Number of transforms: 1 Transform payload Next payload: NONE (0) : 32 Transform number: 1 Transform ID: KEY_IKE (1) Encryption-Algorithm (1): 3DES-CBC (5) Hash-Algorithm (2): MD5 (1) Group-Description (4): Group-Value (1) Authentication-Method (3): PSK (1) Life-Type (11): Seconds (1) Life-Duration (12): Duration-Value (18000) Bad Offset: 122 La figure ci-dessous montre un chaînage possible dans un message ISAKMP. Travail de diplôme Tutorial VPN Page 48

Initiator Cookie Responder Cookie KE Version Exchange Flags Message ID Message Nonce 0 KE Payload KE Payload Data 0 0 Nonce Payload Nonce Payload Data ISAKMP Header Key Exchange Payload Nonce Payload Figure 43 : Chaînage possible d'un message ISAKMP. 6.4.4.1.1 Echanges et phases ISAKMP définit deux phases lors de la négociation des paramètres. La première phase concerne l'authentification des deux pairs et la sécurisation du canal entre eux. La deuxième phase utilise le canal sécurisé pour négocier les paramètres de sécurité des différents protocoles IPSec. ISAKMP définit cinq types d'échange, dont : Base exchange; Identity protection exchange; Authentication only exchange; Agressive exchange; Informational exchange. 6.4.4.2 IKE ISAKMP ne définissant pas d'échange de clés, c'est le rôle d'autres protocoles de définir ces échanges. IPSec utilise pour cet effet le protocole IKE, qui lui utilise le support d'lsakmp pour définir l'échange des clés. IKE définit plusieurs types de messages et d'options applicables à ces échanges; leur but est celui de créer l'association de sécurité SA dans les deux pairs à l'aide des deux phases d'lsakmp. La première est utilisée pour créer une SA IKE et la deuxième pour négocier les paramètres nécessaires à la création de la SA IPSec. Pour la première phase de I'échange, IKE utilise les échanges identity protect exchange et aggressive exchange d'isakmp et les appels main mode et aggressive mode. Pour la deuxième phase, IKE définit un quick mode exchange. Ce dernier négocie les différents paramètres des protocoles IPSec autre que IKE (AH et ESP). 6.4.4.2.1 Main Mode Exchange Pour l'établissement de la SA IKE, sont utilisés six messages, trois requêtes et trois réponses, pour établire la SA IKE. Ces messages font partie de trois étapes : Échange des paramètres Diffie-HeIIman, tel que le group; Échange d'un payload nonce; Authentification des deux pairs. Ces échanges sont montrés par la figure suivante : Travail de diplôme Tutorial VPN Page 49

Pair 1 Pair 2 Header + SA Header + SA Header + KE + Nonce Header + KE + Nonce Header + Idi + Hash Header + Idi + Hash Figure 44 : Main mode exchange de IKE. Le premier échange sert à la négociation des paramètres nécessaires à la mise en place de la SA d'ike. Le deuxième échange sert à la négociation des valeurs publiques de I'algorithme Diffie-Hellman et des valeurs pseudo-aléatoires contenues dans le nonce payload. Lors du dernier échange les deux pairs s'envoient leur identité respective et le hash digest nécessaire à I'authentification. 6.4.4.2.2 Aggressive Mode Exchange Les données échangées en mode agressive mode exchange sont les mêmes que celles pour le main mode exchange. La seule différence existante entre ces deux modes réside dans le nombre de paquets échangés passe de six à trois. En réduisant le nombre de paquets échangés, I'aggressive mode exchange limite sa puissance de négociation. 6.4.4.2.3 Quick Mode Exchange Une fois la SA IKE établie avec le main mode ou I'aggressive mode, le quick mode peut être utilisé pour établir une SA pour un autre protocole de sécurité, tel que AH et ESP. Le quick mode est effectué sous la protection de la SA IKE précédemment établie. Dans un échange en quick mode, les deux pairs négocient les caractéristiques de la SA IPSec à établir, et génèrent les clés correspondantes. La SA IKE protège ces échanges en chiffrant et en authentifiant les messages transmis. Cet échange est montré par la figure suivante : Pair 1 Pair 2 Travail de diplôme Tutorial VPN Page 50 Header + Hash + SA + Nonce [KE, Idci, Idcr] Header + Hash + SA +

Figure 45 : Quick Mode Exchange. En plus de l'entête ISAKMP, du Hash, de la SA, du Nonce et des paramètres optionnels de Diffie-Hellman, les deux pairs peuvent s'échanger des informations concernant leur identité tel que leur adresse IP. 7. Conclusions Ce document a permis à l'auteur de bien se familiariser avec la problématique des réseaux privés virtuels, notamment les problèmes liés aux protocoles étudiés. Le tutorial donne un vaste aperçu des protocoles le plus souvent utilisés, comme PPTP, L2TP et IPSec. Les sujets traités sont mis en pratique dans le laboratoire annexe intitulé Laboratoire sur les VPN. Travail de diplôme Tutorial VPN Page 51

8. Bibliographie 8.1 Ouvrages [SLACKWARE] [IPSECRFC00] Slackware Linux Unleashed Authors : Bao Ha, Tina Nguyen 1999 Sams Edition Big Book of IPSec RFCs Compiled by: Pete Loshin 2000 Morgan Kaufmann 8.2 Articles et documents du web (annexés) [CISCO1] What is a VPN? - White Paper Authors : Paul Ferguson, Geoff Huston April 1998 Cisco [MICROSOFT1] [RFC2401] [RFC2402] [RFC2403] [RFC2404] [RFC2405] [RFC2406] [RFC2407] [RFC2408] [RFC2409] [RFC2410] [RFC2411] [RFC2412] Virtual Private Networking: An Overview - White Paper 1999 Microsoft Corporation Security Architecture for the Internet Protocol IP Authentication Header The Use of HMAC-MD5-96 within ESP and AH The Use of HMAC-SHA-1-96 within ESP and AH The ESP DES-CBC Cipher Algorithm With Explicit IV IP Encapsulating Security Payload (ESP) The Internet IP Security Domain of Interpretation for ISAKMP Internet Security Association and Key Management Protocol (ISAKMP) The Internet Key Exchange (IKE) The NULL Encryption Algorithm and Its Use With IPSec IP Security Document Roadmap The OAKLEY Key Determination Protocol 8.3 Compléments (annexés) [TUTORIAL1] [CONFIG0] [CONFIG1] Tutorial VPN C.Tettamanti 2000 TCOM EiVD Installation de Linux Slackware pour des solutions VPN C.Tettamanti 2000 TCOM - EiVD Configuration d un VPN PPTP et IPSec C.Tettamanti 2000 TCOM - EiVD Travail de diplôme Tutorial VPN Page 52