Tutorial

VPN

Ecole dingnieurs du Canton de Vaud Institut de Tlcommunications

Tutorial sur les VPN, destin aux tudiants; rdig dans le cadre du travail de diplme. Tutorial VPN Complment au laboratoire sur les VPN Auteur: Christian Tettamanti

Principales abrviations

Christian Tettamanti

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 diplme Tutorial VPN

Page 2

Christian Tettamanti

1. Table des matires

1. 2. 3. 4. Table des matires.................................................................................................................................3 Introduction ............................................................................................................................................5 Dfinition de VPN (Virtual Private Networks) .........................................................................................5 Motivations pour le choix d'une solution VPN ........................................................................................7 4.1 Utilisations communes des VPN ...................................................................................................9 4.1.1 Accs distance travers Internet (Host to LAN)....................................................................9 4.1.2 Connexion entre plusieurs rseaux travers Internet (LAN to LAN)........................................9 4.1.3 Rseau priv entre deux ordinateurs (Host to Host)...............................................................10 Exigences de base des VPN................................................................................................................10 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 Prambule...............................................................................................................................12 6.2.2 PPTP et les VPN.....................................................................................................................12 6.2.3 Scnario PPTP typique...........................................................................................................13 6.2.4 Clients PPTP...........................................................................................................................14 6.2.5 Serveur d'accs rseau 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 contrle PPTP..................................................................................................16 6.2.10 Transmission de donnes PPTP ........................................................................................30 6.2.11 Exemple de connexion .......................................................................................................32 6.2.12 La scurit de PPTP...........................................................................................................33 6.2.13 Contrle d'accs.................................................................................................................34 6.2.14 Le chiffrement de donnes .................................................................................................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'entte L2TP .........................................................................................................37 6.3.3 Connexion de contrle 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 Conclusions..........................................................................................................................................51 Bibliographie ........................................................................................................................................52 8.1 Ouvrages.....................................................................................................................................52 8.2 Articles et documents du web (annexs) ....................................................................................52 8.3 Complments (annexs) .............................................................................................................52

5. 6.

7. 8.

Travail de diplme Tutorial VPN

Page 3

Christian Tettamanti

Table des illustrations

Figure 1 : Exemple de VPN. ...........................................................................................................................6 Figure 2 : Rseau priv virtuel construit sur Internet. .....................................................................................7 Figure 3 : Plusieurs communications dans le mme mdia............................................................................8 Figure 4 : Communications utilisant chacune un mdia indpendant.............................................................8 Figure 5 : Utilisation d'un VPN pour connecter un client distant un rseau priv. .......................................9 Figure 6 : Connexions LAN to LAN...............................................................................................................10 Figure 7 : VPN entre deux htes. .................................................................................................................10 Figure 8 : Tunneling......................................................................................................................................11 Figure 9 : Tunnel PPTP. ...............................................................................................................................13 Figure 10 : Connexion distance entre un client PPTP et un rseau priv. ................................................14 Figure 11 : message de contrle Start-Control-Connection-Request...........................................................17 Figure 12 : message de contrle Start-Control-Connection-Reply ...............................................................18 Figure 13 : message de contrle Stop-Control-Connection-Request ...........................................................19 Figure 14 : message de contrle Echo-Request ..........................................................................................20 Figure 15 : message de contrle Echo-Reply...............................................................................................20 Figure 16 : message de contrle Outgoing-Call-Request.............................................................................21 Figure 17 : message de contrle Outgoing-Call-Reply.................................................................................22 Figure 18 : message de contrle Incoming-Call-Request.............................................................................23 Figure 19 : message de contrle Incoming-Call-Reply.................................................................................24 Figure 20 : message de contrle Incoming-Call-Connected.........................................................................25 Figure 21 : message de contrle Call-Clear-Request...................................................................................26 Figure 22 : message de contrle Call-Disconnect-Notify..............................................................................27 Figure 23 : message de contrle WAN-Error-Notify .....................................................................................28 Figure 24 : message de contrle Set-Link-Info.............................................................................................29 Figure 25 : Datagramme PPTP avec message de contrle..........................................................................30 Figure 26 : Datagramme GRE ......................................................................................................................31 Figure 27 : Encapsulation des donnes 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 derrire un firewall. ..............................................................................................35 Figure 31 : Structure du protocole L2TP.......................................................................................................36 Figure 32 : Entte L2TP................................................................................................................................37 Figure 33 : Mode transport d'IPSec. .............................................................................................................40 Figure 34 : Mode tunnel d'IPSec...................................................................................................................40 Figure 35 : Entte du protocole AH. .............................................................................................................41 Figure 36 : AH en mode Transport ...............................................................................................................42 Figure 37 : AH en mode Tunnel....................................................................................................................42 Figure 38 : Entte du protocole ESP. ...........................................................................................................44 Figure 39 : ESP en mode Transport .............................................................................................................45 Figure 40 : ESP en mode Tunnel. ................................................................................................................45 Figure 41 : Entte ISAKMP...........................................................................................................................47 Figure 42 : Entte gnrique de ISAKMP.....................................................................................................47 Figure 43 : Chanage possible d'un message ISAKMP. ...............................................................................49 Figure 44 : Main mode exchange de IKE. ....................................................................................................50 Figure 45 : Quick Mode Exchange. ..............................................................................................................51

Travail de diplme Tutorial VPN

Page 4

Christian Tettamanti

2. Introduction
Ce document est suppos tre un complment au laboratoire 'Configuration d'un VPN'. Il explique les bases thoriques pour pouvoir bien comprendre la manipulation pratique. Ceci dit, le tutorial devrait tre connu pralablement la manipulation pratique.

3. Dfinition de VPN (Virtual Private Networks)

Lorsquon aborde pour la premire fois le sujet des rseaux privs virtuels, on saperoit que le nombre de dfinitions dun VPN est trs lev. Ceci dit, il nest pas possible de donner une seule dfinition. La faon la plus simple de trouver une dfinition commune pourrait tre celle danalyser, individuellement, chaque mot de lacronyme VPN. Ceci permet de regrouper les diffrentes analyses et donner ainsi une dfinition correcte de sens commun. La difficult d'analyse motive le choix de classement suivant: network : Ce mot est sans autre le plus facile analyser et comprendre; sa dfinition est commune et accepte par lindustrie. Un "rseau" (network) consiste en un nombre de dispositifs pouvant communiquer entre eux l'aide de mthodes arbitraires. Ces dispositifs peuvent tre de nature diffrente : les ordinateurs, les imprimantes, les routeurs, etc., y sont inclus. Gographiquement, ils peuvent se trouver dans diffrents sites. Les mthodes avec lesquelles ces dispositifs peuvent communiquer sont trs nombreuses, car elles dpendent du niveau dapplication. Des spcifications pour le niveau physique, liaison, transport et application devront donc tre nonces. En conclusion, un rseau est une collection de dispositifs qui peuvent communiquer entre eux et donc schanger des donnes. Le terme "priv" (private) est assez correct et il est li au concept de virtualisation dans la dfinition des VPN. La dfinition la plus simple de "priv" indique que la communication entre deux ou plusieurs dispositifs est secrte. Les dispositifs n'tant pas concerns par la communication de nature prive, ne pourront pas lire le contenu des messages privs. Ceci dit, ils ignorent tout de la relation entre les dispositifs concerns. La confidentialit des donnes et la scurit (intgrit) sont des aspects importants dont il faut tenir compte lorsqu'on considre un type particulier d'implmentation VPN. La dfinition "priv" peut tre exprime l'aide de la dfinition de son antonyme "public". Un service public est accessible ouvertement et contrl dans les limites et les contraintes d'une ressource publique commune, souvent par l'intermdiaire d'une entit administrative publique. Au contraire, un service priv est accessible uniquement par un groupe d'entits dfinies. Des tiers ne pourront pas en avoir accs. En gnral, la ressource prive est gre par des entits qui ont un droit exclusif d'accs. Des exemples de ce type de rseau priv peuvent tre trouvs dans des rseaux d'organisation qui ne sont pas connects Internet. Ces rseaux sont privs, car aucune connexion externe, et donc aucune communication de rseau avec l'extrieur, est prsente. Un autre aspect important de la confidentialit dans les VPN, est donn travers son implmentation technique. Laquelle dcrit la confidentialit des systmes d'adressage et de routage. L'adressage, utilis dans une communaut VPN d'intrts, est spar par rapport celui du rseau partag et des autres communauts VPN. Le schma d'adressage et de routage d'un VPN devrait tre indpendant de chaque communaut VPN.

private :

Travail de diplme Tutorial VPN

Page 5

Christian Tettamanti

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 dfini par : simul, qui excute des fonctions d'un objet non rel. L'aspect de virtualisation est similaire la dfinition de "priv" qu'on vient de dcrire, bien que le scnario soit un peu modifi. La communication prive est tablie sur une infrastructure de rseau partage par plus qu'une organisation. De cette faon, la ressource prive est construite en se basant sur un partitionnement logique de la ressource partag la place d'utiliser des connexions de circuits physiques. Le rseau priv est une cration 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 concernes par la communication n'ont pas la possibilit de percevoir des donnes. Ceci dit, elles sont incapables de dterminer la relation entre les machines concernes. L'infrastructure du rseau partag peut tre par exemple reprsente par le rseau global Internet et un nombre d'organisations utilisant des rseaux virtuels. Ces dernires peuvent tre des centaines, des milliers, voir des millions!

La combinaison de ces termes produit VPN un rseau priv dont la confidentialit est introduite par des moyens de virtualisation. Un VPN peut tre cr entre deux systmes, entre deux organisations, entre plusieurs systmes et une organisation ou entre plusieurs organisations rpandues dans Internet, soit encore entre des applications individuelles ou une combinaison des ces possibilits. La dfinition, la plus utilise, qui caractrise un VPN est la suivante: Un VPN est un environnement de communication dans lequel l'accs est contrl, afin de permettre des connections entre une communaut d'intrts seulement. Un VPN est construit avec un partitionnement d'un mdia de communication commun qui offre des services de faon non exclusive. Voil une autre dfinition, plus simple et approximative: Un VPN est un rseau priv construit sur l'infrastructure d'un rseau public, comme l'est Internet. On peut noter qu'une solution exhaustive de VPN fournit un support pour l'accs via modem, pour l'accs avec des lignes ddies, et la possibilit de supporter des connexions depuis le rseau global Internet.

Figure 1 : Exemple de VPN.

Travail de diplme Tutorial VPN

Page 6

Christian Tettamanti

On a vu qu'un VPN permet de crer un rseau priv travers un rseau public comme Internet; voil un exemple de VPN construit sur Internet:

Figure 2 : Rseau 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 prservant les avantages d'une infrastructure commune. La motivation principale pour choisir une solution VPN couvre les aspects conomiques des communications. Les systmes de communications ont aujourd'hui la caractristique d'avoir un prix constant et lev avec des petits cots variables qui changent selon la capacit de transport ou la bande passante du systme. Dans cet environnement, il est financirement plus attractif de runir un nombre de communications discrtes dans une plate-forme de communication de grande capacit, permettant ainsi l'amortissement des prix levs des composants par un grand nombre de clients, la place d'utiliser une ligne ddie pour chaque communication. Ainsi, une collection de VPN implments sur un seul mdia physique commun, est moins cher qu'une collection quivalente de petits mdias discrets, chacun reliant un seul client rseau.

Travail de diplme Tutorial VPN

Page 7

Christian Tettamanti

Les figures suivantes montrent les concepts noncs.

Figure 3 : Plusieurs communications dans le mme mdia.

Figure 4 : Communications utilisant chacune un mdia indpendant.

Une autre motivation concerne la confidentialit des communications. Les caractristiques et l'intgrit des services de communications isols diffrent des autres environnements qui partagent un mdia commun. Le niveau de confidentialit dpend de la politique de l'organisation. Si le besoin de confidentialit est bas, la simple abstraction de discrtion pourra suffire. Tandis que si le besoin en confidentialit est grand, il y a un fort besoin de scuriser les accs et les donnes passant dans le mdia commun.

Travail de diplme Tutorial VPN

Page 8

Christian Tettamanti

4.1 Utilisations communes des VPN Cette section dcrit brivement les solutions VPN les plus souvent utilises.

4.1.1 Accs distance travers Internet (Host to LAN)

Un VPN permet aux utilisateurs loigns de se connecter un rseau priv tout en maintenant la confidentialit. La figure suivante montre un utilisateur VPN connect un rseau d'entreprise travers Internet. Au lieu d'effectuer un appel tlphonique longue distance destination de l'entreprise, l'utilisateur se connecte simplement Internet et ensuite il cre une connexion VPN jusqu'au rseau de l'entreprise.

Figure 5 : Utilisation d'un VPN pour connecter un client distant un rseau priv.

L'utilisateur distant sera connect logiquement au rseau LAN de l'entreprise comme s'il l'tait physiquement.

4.1.2 Connexion entre plusieurs rseaux travers Internet (LAN to LAN)

Il y a deux mthodes pour connecter des rseaux locaux entre eux avec un VPN: 1. En utilisant des lignes ddies Au lieu d'utiliser des lignes loues trs coteuses longue distance entre deux LAN, on utilise une ligne ddie locale pour se connecter un ISP pour permettre des connexions Internet. Le rseau priv virtuel sera donc cr l'aide des connexions locales l'ISP et l'aide du rseau public Internet. 2. l'aide d'une liaison tlphonique Au lieu d'utiliser des lignes ddies pour se connecter l'ISP, il suffit d'avoir une liaison tlphonique permettant l'appel de son propre ISP. Comme pour la solution prcdente, le rseau priv virtuel sera cr l'aide des connexions locales l'ISP et l'aide du rseau public Internet.

Travail de diplme Tutorial VPN

Page 9

Christian Tettamanti

Ces deux solutions diffrent uniquement dans la faon de se connecter son propre ISP. L'image suivante montre ces solutions.

Figure 6 : Connexions LAN to LAN.

4.1.3 Rseau 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 cre donc un VPN entre eux, et toutes les donnes y transmises sont encryptes et comprhensibles que par les deux paires correspondantes. La figure suivante montre cet exemple.

Figure 7 : VPN entre deux htes.

5. Exigences de base des VPN

Lorsqu'on veut crer des VPN, l'entreprise ncessite d'un contrle d'accs facilit aux ressources et aux informations partages. La solution doit permettre aux utilisateurs distants de se connecter aux ressources du rseau LAN local (solution Host-to-LAN). La solution doit aussi permettre des rseaux distants de pouvoir se connecter au rseau LAN, afin de partager les ressources et les informations (solution LAN-toLAN). De plus la solution doit assurer la confidentialit et l'intgrit des donnes travers Internet. Le mme concept doit tre appliqu des donnes sensibles traversant le rseau d'entreprise. En consquence une solution VPN doit offrir au minimum les fonctions suivantes : Authentification de l'utilisateur : la solution doit vrifier l'identit de l'utilisateur et limiter l'accs VPN seulement aux utilisateurs autoriss. Il doit de mme pouvoir enregistrer les accs, afin de permettre ensuite de dterminer qui s'est connect et quand il s'est connect. Administration des adresses : la solution doit assigner une adresse du rseau priv chaque client et assurer que les adresses prives restent en tant que prives. Encryption des donnes : les donnes circulants dans le rseau public (Internet) doivent tre illisibles aux clients non autoriss. Administration des cls : la solution doit gnrer et mettre jour les cls pour l'encryption des donnes pour le client et le serveur. Support multiprotocoles : la solution doit permettre l'utilisation de protocoles communs utiliss dans le rseau public. IP, IPX, etc. sont inclus.

Travail de diplme Tutorial VPN

Page 10

Christian Tettamanti

Une solution VPN peut tre base 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 donnes d'un rseau un autre en utilisant une infrastructure d'inter rseau. Les donnes transfrer (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 implmente le tunnel encapsule la trame dans une en-tte supplmentaire. L'en-tte supplmentaire fournit des informations de routage de sorte que la charge utile encapsule puisse traverser le rseau intermdiaire. Les paquets encapsuls sont alors conduits entre les points finaux du tunnel travers le rseau intermdiaire. Le chemin d'accs logique, par lequel les paquets encapsuls traversent l'inter rseau, s'appelle tunnel. Une fois que les trames encapsules atteignent leur destination, la trame est dcapsule et expdie sa destination finale. Le tunneling inclut l'entier processus : encapsulation, transmission, et dcapsulation des paquets.

Figure 8 : Tunneling.

Pour la cration d'un tunnel, tant le client que le serveur doivent implmenter le mme protocole. Les technologies utilisant le tunneling peuvent tre bases sur des protocoles de niveau 2 ou 3. Ces niveaux correspondent aux diffrentes couches du modle de rfrence 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 rseau intermdiaire. Les protocoles de niveau 3 correspondent des protocoles de couche rseau. Le mode tunnel de IPSec (IP Security) reprsente 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 rseau intermdiaire 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 mdia 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 rseau intermdiaire IP, comme Internet.

Ces protocoles feront respectivement l'objet d'une prsentation dans les chapitres 6.2, 6.3 et 6.4.
Travail de diplme Tutorial VPN

Page 11

Christian Tettamanti

6.1.1 Types de tunnel

Les tunnels peuvent tre crs selon des manires diffrentes. Tunnel volontaire : un client peut mettre une demande de cration de VPN, afin de configurer et de crer 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 implmentant le tunneling pour crer une connexion virtuelle avec le serveur destinataire. Les VPN n'exigent pas une connexion commute. C'est une tape prliminaire en vue de crer un tunnel et n'est pas une partie du protocole de tunnel elle-mme. Ils exigent seulement la gestion du rseau IP. Tunnel d'office : un serveur d'accs rseau implmemtant un protocole VPN configure et cre 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'accs 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. PPTP Point-to-Point Tunneling Protocol

6.2

6.2.1 Prambule
PPTP (Point-to-Point Tunnelling Protocol) est un protocole rseau permettant le transfert scuris de donnes entre un client distant et un serveur priv. Ceci est possible par la cration d'un VPN utilisant TCP/IP. PPTP supporte les VPN la demande multiprotocole sur des rseaux publics comme Internet. La technologie utilise par PPTP est une extension du protocole permettant l'accs distance PPP (Pointto-Point Protocol) dfini 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 rseau public bas sur TCP/IP. PPTP peut tre de mme 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 cration de VPN sur demande travers des rseaux bass sur TCP/IP. Il peut de mme tre utilis pour crer un VPN entre deux ordinateurs dans le mme rseau local. Une caractristique importante de PPTP est son support pour la cration de rseaux privs virtuels en utilisant le rseau tlphonique public (PSTN). PPTP simplifie et rduits les cots d'une solution pour l'accs longue distance par les utilisateurs distants mobiles. Ceci, car il permet des communications encryptes sres travers les liaisons tlphoniques et l'Internet. Gnralement, l'usage de PPTP implique: - un client PPTP; - un serveur d'accs rseau (Network Access Server NAS); - un serveur PPTP.
Travail de diplme Tutorial VPN

Page 12

Christian Tettamanti

L'usage d'un serveur d'accs rseau pour la cration d'un tunnel PPTP entre deux dispositifs sur le mme LAN n'est pas ncessaire. Ceci, en raison du fait que les dispositifs se trouvent dj sur le mme rseau. Le sous-chapitre suivant dcrira un scnario typique de l'usage de PPTP entre deux ordinateurs et en expliquera la relation.

6.2.3 Scnario 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 rseau 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'accs (NAS)1 de l'ISP. Une fois connect le client peut envoyer et recevoir des paquets depuis Internet et utiliser TCP/IP. Aprs que le client ait cr la connexion PPP initiale avec l'ISP une seconde connexion PPP est faite sur l'existante. Les donnes envoyes travers la deuxime connexion sont sous la forme de datagrammes IP contenants des paquets PPP; ces paquets PPP sont en fait des paquets PPP encapsuls. Cette deuxime connexion cre la liaison VPN avec le serveur PPTP de l'entreprise et elle est appele "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 rseau priv, en faisant un routage des paquets sur d'autres rseaux, comme Internet, est appel "Tunneling". Les routeurs des autres rseaux ne peuvent pas accder l'ordinateur qui se trouve dans le rseau priv. Toutefois, le tunneling permet au rseau public de transmettre les paquets un dispositif intermdiaire, comme un serveur PPTP, qui est connect, tant au rseau public qu'au rseau priv. Le client et le serveur PPTP utilisent le tunnel pour router les paquets vers un ordinateur situ dans le rseau priv en utilisant des routeurs qui connaissent seulement l'adresse publique du serveur intermdiaire qui fait office de passerelle. Lorsque le serveur PPTP reoit des paquets provenant du rseau public, il les envoie l'ordinateur destinataire qui se trouve dans le rseau priv. Le serveur PPTP fait cela aprs 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 rseau priv en utilisant les protocoles du rseau priv, il est capable de comprendre les paquets de plusieurs protocoles.

1 NAS Network Acces Server : Les serveurs d'accs-rseau sont rfrencs de mme en tant que FEPs (Front End Processors). Les serveurs Dial-in comme POP (Point-Of-Presence servers).

Travail de diplme Tutorial VPN

Page 13

Christian Tettamanti

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 rseau local.

Figure 10 : Connexion distance entre un client PPTP et un rseau priv.

PPTP encapsule les paquets PPP crypts et compresss dans un datagramme IP pour la transmission sur Internet. Ces datagrammes sont routs travers Internet jusqu'au serveur PPTP qui est connect tant au rseau public qu'au rseau priv. Ensuite le serveur PPTP dsassemble ces datagrammes dans des paquets PPP et encode ces paquets dans le protocole utilis dans le rseau 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 manires diffrentes : Soit en utilisant l'accs 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'accs d'un ISP doit tre dot d'un modem et d'un dispositif VPN2; qui permettent respectivement la connexion l'ISP et au serveur PPTP. Comme vu dans le chapitre prcdent le tunnel PPTP est cr partir de deux connexions. La premire connexion est une connexion PPP par modem destination des fournisseurs d'accs Internet. La deuxime est une connexion VPN PPTP utilisant la premire connexion pour crer un tunnel travers Internet vers un dispositif VPN sur le serveur PPTP. La deuxime connexion ncessite de la premire, car le tunnel entre les deux dispositifs VPN est tabli en utilisant le modem et la connexion PPP vers Internet. Une autre possibilit consiste crer un rseau priv virtuel entre deux ordinateurs connects physiquement au rseau LAN priv. Dans ce scnario, le client PPTP est dj connect au rseau et il a seulement besoin du dispositif VPN pour la connexion un serveur PPTP dans le LAN. Les paquets d'un client distant (accs par modem) et d'un client local (LAN) sont traits diffremment. Un paquet PPTP provenant d'un client distant est plac dans le mdia physique du dispositif de tlcommunication (modem) qui peut tre une ligne tlphonique ou le tlrseau, etc.. Tandis qu'un paquet PPTP provenant d'un client reli physiquement au rseau local est plac dans l'adaptateur du mdia physique, comme par exemple une carte Ethernet.

En pratique, le dispositif VPN est un module sur Linux ou une carte VPN fictive sur Windows.

Travail de diplme Tutorial VPN

Page 14

Christian Tettamanti

6.2.5 Serveur d'accs rseau de l'ISP

Les fournisseurs d'Internet utilisent des serveurs d'accs (NAS) pour permettre ces propres clients d'accder 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'accs de l'ISP sont paramtrs et configurs pour permettre un grand nombre d'appels entrants de la part des clients. Certains NAS supportent eux-mmes 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 rseau priv en crant un tunnel entre l'ISP et le serveur PPTP.

6.2.6 Serveur PPTP

Les serveurs PPTP sont des serveurs qui ont des capacits de routage et sont connects tant au rseau priv qu' Internet. Un serveur PPTP peut tre implment par un ordinateur tournant Linux et le daemon pptpd ou par un ordinateur ayant Window NT. Dans le cas de WinNT, PPTP est dfini comme un protocole rseau. Pendant l'installation, PPTP est configur en rajoutant le dispositif virtuel VPNs (Virtual Private Networks) l'accs distance.

6.2.7 Architecture PPTP

Comme vu prcdemment PPTP a t conu, afin d'obtenir une mthode sre pour rejoindre un rseau priv travers Internet. Par les prochains chapitres, on examinera : Le protocole PPP; La connexion de contrle PPTP; Le Tunnel PPTP.

6.2.8 Vue d'ensemble de l'architecture PPTP

La cration d'un VPN l'aide de PPTP implique typiquement trois processus; chacun ayant besoin la terminaison correcte du processus prcdent. Voici les processus impliqus. Connexion et communication PPTP : un client PPTP utilise PPP pour se connecter son ISP l'aide d'une ligne tlphonique analogique ou RNIS. Cette connexion utilise le protocole PPP pour tablir la connexion et encrypter les paquets. Connexion de contrle PPTP : en utilisant la connexion Internet tablie par PPP, le protocole PPTP cre une connexion de contrle 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 cre des datagrammes IP contenants des paquets PPP encrypts, lesquels sont ensuite envoys travers le tunnel PPTP au serveur. Le serveur dsassemble les datagrammes IP, les dcrypte et les redirige vers le rseau LAN priv. Protocole PPP : PPP est un protocole pour l'accs distance utilis par PPTP pour l'envoi de donnes travers les rseaux bass sur TCP/IP. PPP encapsule les paquets IP, IPX ou NetBEUI dans des trames. Ces trames sont envoyes en crant un lien point point entre l'ordinateur metteur et celui rcepteur. La plupart des sessions PPTP sont dmarres par un client appelant un serveur d'accs d'un ISP. Le protocole PPP est utilis pour la cration de la connexion entre le client et le serveur d'accs rseau. PPP offre ces trois options : Etablir et former la connexion physique : le protocole PPP utilise la squence dfinie dans le document de rfrence (RFC 1662, v. CD en annexe) pour la cration, le maintien et la fermeture de la connexion. Authentifier les utilisateurs : les clients PPTP sont authentifis par le protocole PPP. L'authentification peut tre faite par l'envoi de cls en clair ou encryptes. Crer des datagrammes PPP contenants des paquets IPX, NetBEUI, soit TCP/IP : PPP cre des datagrammes contentant un ou plusieurs paquets TCP/IP, IPX soit NetBEUI. Vu que tous les
Travail de diplme Tutorial VPN

Page 15

Christian Tettamanti

paquets sont encrypts, le trafic entre un client PPP et un serveur d'accs peut tre considr comme sr.

6.2.9 Connexion de contrle PPTP

Le protocole PPTP dfini une srie de messages de contrle changs entre le client et le serveur PPTP. Ces commandes tablissent, maintiennent et terminent le tunnel PPTP. La liste suivante reprsente les messages utiliss 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 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 Messages d'erreurs: WAN_ERROR_NOTIFY Messages de gestion de la session PPP: SET_LINK_INFO Configure la connexion entre le client et le serveur Erreur dans la connexion PPP Demande de cration du tunnel de la part du client Rponse la demande de cration du tunnel de la part du client Demande de cration du tunnel de la part du serveur Rponse la demande de cration du tunnel de la part du serveur Tunnel en entre cre Demande de terminaison de la session PPTP Rponse la demande de terminaison et fin de la session PPTP Demande de dbut de session Rponse la demande de dbut de session Demande de fin de session Rponse la demande de fin de session Demande de maintient la session de contrle Rponse la demande de maintient

6.2.9.1 Messages de gestion de la connexion Ces messages sont utiliss pour tablir et terminer une session d'utilisateur. Ces messages sont envoys
Travail de diplme Tutorial VPN

Page 16

Christian Tettamanti

comme donnes 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 contrle PPTP employ pour tablir la connexion de contrle entre un client et un serveur. Une connexion de contrle doit tre cre pour chaque paire client-serveur. Une connexion de contrle doit tre tablie avant que tous les autres messages de contrle PPTP puissent tre mis.
16 bit PPTP Message Type Magic Cookie 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 contrle Start-Control-Connection-Request

16 bit Length

Dscription des champs de la trame: Length PPTP Message Type Magic Cookie Control Message Type Reserved0 Protocol Version Reserved1 Framing Capabilities Bearer Capabilities Maximum Channels Firmware Revision Host Name Vendor Name Longueur totale en octets du message PPTP. L'entte est incluse. Valeur 1 pour un message de contrle. Valeur 0x1A2B3C4D. Cette constante est utilise comme test pour les paquets reus. Valeur 1 pour indiquer le message Start-Control-Connection-Request. Ce champ doit tre 0. Indique la version de PPTP utilise. Ce champ doit tre 0. Indique le type des trames. Deux valeurs sont possibles: 1 - Asynchronous Framing 2 - Synchronous Framing Indique le type d'accs. Deux valeurs sont possibles: 1 - Accs analogique support 2 - Accs numrique support 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. Ce champ contient la version du firmware Indique le nom du client ou du serveur. Ce champ est de 64 octets. 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 rponse au message Start-Control-Connection-Request. Il contient le

Travail de diplme Tutorial VPN

Page 17

Christian Tettamanti

rsultat de la demande de connexion.

16 bit PPTP Message Type Magic Cookie 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 contrle Start-Control-Connection-Reply

16 bit Length

Dscription des champs de la trame: Length PPTP Message Type Magic Cookie Control Message Type Reserved0 Protocol Version Result Code Longueur totale en octets du message PPTP. L'entte est incluse. Valeur 1 pour un message de contrle. Valeur 0x1A2B3C4D. Cette constante est utilise comme test pour les paquets reus. Valeur 2 pour indiquer le message Start-Control-Connection-Reply. Ce champ doit tre 0. Indique la version de PPTP utilise. Indique le rsultat de la tentative de connexion. Les valeurs possibles sont: 1 - Connexion tablie avec succs 2 - Erreur gnrale. Si dfini, il est spcifi dans le champ Error Code 3 - La connexion de contrle existe dj 4 - Le client n'est pas autoris crer la connexion de contrle. 5 - La version du protocole n'est pas supporte Tant qu'il n'y a pas d'erreur gnrale, ce champ vaut 0. Sinon il indique le type d'erreur. Indique le type des trames. Deux valeurs sont possibles: 1 - Asynchronous Framing 2 - Synchronous Framing Indique le type d'accs. Deux valeurs sont possibles: 1 - Accs analogique support 2 - Accs numrique support 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. Ce champ contient la version du firmware Indique le nom du client ou du serveur. Ce champ est de 64 octets. Indique le nom du constructeur du client ou du serveur. Ce champ est de 64 octets.

Error Code Framing Capabilities Bearer Capabilities Maximum Channels Firmware Revision Host Name Vendor Name

Stop-Control-Connection-Request Le Stop-Control-Connection-Request est un message de contrle envoy par un pair de la connexion afin
Travail de diplme Tutorial VPN

Page 18

Christian Tettamanti

d'informer l'autre que la connexion de contrle devrait tre ferme. En plus de fermer la connexion, tous les appels d'utilisateur actifs sont implicitement effacs. La raison de l'mission de cette demande est indique dans le champ Reason.
16 bit PPTP Message Type Magic Cookie Control Message Type Reserved0 Reason Reserved1 Reserved2
Figure 13 : message de contrle Stop-Control-Connection-Request

16 bit Length

Dscription des champs de la trame: Length PPTP Message Type Magic Cookie Control Message Type Reserved0 Reason Longueur totale en octets du message PPTP. L'entte est incluse. Valeur 1 pour un message de contrle. Valeur 0x1A2B3C4D. Cette constante est utilise comme test pour les paquets reus. Valeur 3 pour indiquer le message Stop-Control-Connection-Request. Ce champ doit tre 0. Indique la raison pour la fermeture de la connexion. Che champs peut avoir les valeurs: 1 - (None) Requte gnrale pour la fermeture de la connexion 2 - (Stop-Protocol) Version de protocole non supporte 3 - (Stop-Local-Shutdown) Arrt de l'ordinateur qui fait la requte Ce champ doit tre 0.

Reserved1, Reserved2

Stop-Control-Connection-Reply Le Stop-Control-Connection-Reply est un message de contrle envoy par un pair d'une connexion de contrle la rception d'un message Control-Connection-Request de l'autre pair.
16 bit PPTP Message Type Magic Cookie Control Message Type Reserved0 Result Code Error Code Reserved1 16 bit Length

Dscription des champs de la trame: Length PPTP Message Type Magic Cookie Control Message Type Reserved0 Result Code sont: Longueur totale en octets du message PPTP. L'entte est incluse. Valeur 1 pour un message de contrle. Valeur 0x1A2B3C4D. Cette constante est utilise comme test pour les paquets reus. Valeur 4 pour indiquer le message Stop-Control-Connection-Reply. Ce champ doit tre 0. Indique le resultat de la demande de dconnexion. Les valeurs possibles 1 (OK) - Connexion de contrle freme. 2 (General Error) - Connexion de contrle pas ferme cause de Error Code
Page 19

Travail de diplme Tutorial VPN

Christian Tettamanti

Error Code Reserved1

Tant qu'il n'y a pas d'erreur gnrale, ce champ vaut 0. Sinon il indique le type d'erreur. Ce champ doit tre 0.

Echo-Request L'Echo-Request est un message de contrle envoy par l'un ou l'autre pair d'une connexion de contrle. Ce message est utilis comme test d'existance de la connexion de contrle. Le pair de rception met un Echo-Reply chaque Echo-Request reu. Si l'expditeur ne reoit pas un Echo-Reply en rponse un Echo-Request, il peut fermer la connexion.
16 bit PPTP Message Type Magic Cookie Control Message Type Reserved0 Identifier
Figure 14 : message de contrle Echo-Request

16 bit Length

Dscription des champs de la trame: Length PPTP Message Type Magic Cookie Longueur totale en octets du message PPTP. L'entte est incluse. Valeur 1 pour un message de contrle. Valeur 0x1A2B3C4D. Cette constante est utilise comme test pour les paquets reus. 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 contrle envoy par l'un ou l'autre pair d'une connexion de contrle en rponse la rception d'une demande d'cho.
16 bit PPTP Message Type Magic Cookie Control Message Type Reserved0 Identifier Result Code Error Code Reserved1
Figure 15 : message de contrle Echo-Reply

16 bit Length

Dscription des champs de la trame: Length PPTP Message Type Magic Cookie Control Message Type Reserved0 Identifier Longueur totale en octets du message PPTP. L'entte est incluse. Valeur 1 pour un message de contrle. Valeur 0x1A2B3C4D. Cette constante est utilise comme test pour les paquets reus. Valeur 6 pour indiquer le message Echo-Reply. Ce champ doit tre 0. Valeur choisit par l'metteur pour la correspondance avec le message EchoRequest. La valeur est celle reue dans le champ Identifier du message Echo-Request.
Page 20

Travail de diplme Tutorial VPN

Christian Tettamanti

Result Code Error Code Reserved1

Indique le rsultat de la requte Echo-Request. Les valeurs possibles sont: 1 (OK) - Requte valide 2 (General Error) - Requte Echo-Request non accepte Tant qu'il n'y a pas d'erreur gnrale, ce champ vaut 0. Sinon il indique le type d'erreur. 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 donnes doit tre tabli. Cette demande fournit au serveur des informations qui permettent la rgulation de la transmission des donnes.
16 bit PPTP Message Type Magic Cookie 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 Length Reserved1 Phone Number (64 octets) Subaddress (64 octets)
Figure 16 : message de contrle Outgoing-Call-Request

16 bit Length

Dscription des champs de la trame: Length PPTP Message Type Magic Cookie Control Message Type Reserved0 Call ID Call Serial Number Longueur totale en octets du message PPTP. L'entte est incluse. Valeur 1 pour un message de contrle. Valeur 0x1A2B3C4D. Cette constante est utilise comme test pour les paquets reus. Valeur 7 pour indiquer le message Outgoing-Call-Request. Ce champ doit tre 0. Un identificateur unique assign par le client cette session. Elle est employe pour multiplexer et dmultiplexer des donnes envoyes dans le tunnel. Un identificateur assign par le client cette. la diffrence de l'identification d'appel, le client et le serveur associent le mme numro d'appel une session donne. La combinaison du numro de srie et de l'adresse IP et d'appel devrait tre unique. Vitesse de ligne minimale (in bits/sec) pour cette session. Vitesse de ligne maximale (in bits/sec) pour cette session. Indique le type d'accs. Deux valeurs sont possibles: 1 - Accs analogique support
Page 21

Minimum BPS Maximum BPS Bearer Capabilities

Travail de diplme Tutorial VPN

Christian Tettamanti

2 - Accs numrique support 3 - Tous les types d'accs sont supports Framing Capabilities Indique le type des trames. Deux valeurs sont possibles: 1 - Asynchronous Framing 2 - Synchronous Framing 3 - Tous les types sont supports Packet Recv. Window Size Le nombre de paquets de donnes reus que le client protgera pour cette session. Packet Processing Delay Une mesure du retard de traitement de paquet qui pourrait tre impos aux donnes a envoy au client. Cette valeur est indique dans les units de 1/10 de secondes. Pour le client ce nombre devrait tre trs petit. Phone Number Length Le nombre rel de chiffres valides dans le domaine de numro de tlphone. Reserved1 Ce champ doit tre 0. Phone Number Le nombre composer pour tablir la session sortante. Pour des appels numriques et analogiques cette zone est une chane de caractres ascii. Si le numro de tlphone 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 supplmentaire. Outgoing-Call-Reply L'Outgoing-Call-Reply est un message de contrle du serveur en rponse un message Outgoing-CallRequest. La rponse indique le rsultat de la tentative d'appel sortant. Elle fournit galement des informations au client au sujet des paramtres particuliers utiliss pour l'appel.
16 bit PPTP Message Type Magic Cookie 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 contrle Outgoing-Call-Reply

16 bit Length

Dscription des champs de la trame: Length PPTP Message Type Magic Cookie Control Message Type Reserved0 Call ID Peer's Call ID Longueur totale en octets du message PPTP. L'entte est incluse. Valeur 1 pour un message de contrle. Valeur 0x1A2B3C4D. Cette constante est utilise comme test pour les paquets reus. Valeur 8 pour indiquer le message Outgoing-Call-Reply. Ce champ doit tre 0. Un identificateur unique assign par le serveur cette session. Elle est employe pour multiplexer et dmultiplexer des donnes envoyes dans le tunnel. Dans ce champ se trouve la valeur reue dans le domaine d'identification d'appel du message prcedent d'Outgoing-Call-Request. Elle est employe par le client pour comparer l'Outgoing-Call-Reply avec l'Outgoing-CallRequest qu'il a mis.
Page 22

Travail de diplme Tutorial VPN

Christian Tettamanti

Result Code

Indique le rsultat de la requte Outgoing-Call-Request. Les valeurs possibles sont: 1 - Connexion tablie avec succs 2 - Erreur gnrale. Si dfini, il est spcifi dans le champ Error Code 3 (No Carrier) - Aucune porteuse dtecte 4 (Busy) - Ligne occupe 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 gnrale, ce champ vaut 0. Sinon il indique le type d'erreur. Cause Code Ce champ fournit l'information supplmentaire de panne. Sa valeur peut changer dpendance du type d'appel. Connect Speed La vitesse relle de connexion utilise, en bits/sec. Packet Recv. Window Size Le nombre de paquets de donnes reus que le serveur protgera pour cette session. Packet Processing Delay Une mesure du retard de traitement de paquet qui pourrait tre impos aux donnes a envoy au serveur. Cette valeur est indique dans les units de 1/10 de secondes. Pour le client ce nombre devrait tre trs petit. Physical Channel ID Ce champ est configur par le serveur avec le numro 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 contrle envoy par le serveur pour indiquer qu'un tunnel doit tre tabli. Le serveur ne peut pas le crer jusqu' ce qu'elle ait reu un Incoming-Call-Reply du client, indiquant que l'appel peut tre tabli. Ce mcanisme permet au client d'obtenir des informations suffisantes sur le tunnel avant qu'on lui rponde pour dterminer si l'appel doit tre rpondu ou pas.
16 bit PPTP Message Type Magic Cookie Control Message Type Reserved0 Call ID Call Serial Number Call Bearer Type Physical Channel ID Dialed Number Length Dialing Number Length Dialed Number (64 octets) Dialing Number (64 octets) Subaddress (64 octets)
Figure 18 : message de contrle Incoming-Call-Request

16 bit Length

Dscription des champs de la trame: Length PPTP Message Type

Travail de diplme Tutorial VPN

Longueur totale en octets du message PPTP. L'entte est incluse. Valeur 1 pour un message de contrle.
Page 23

Christian Tettamanti

Magic Cookie Control Message Type Reserved0 Call ID Call Serial Number

Bearer Type

Physical Channel ID Dialed Number Length Dialing Number Length Dialed Number

Dialing Number

Subaddress

Valeur 0x1A2B3C4D. Cette constante est utilise comme test pour les paquets reus. Valeur 9 pour indiquer le message Incoming-Call-Request. Ce champ doit tre 0. Un identificateur unique assign par le serveur cette session. Elle est employe pour multiplexer et dmultiplexer des donnes envoyes dans le tunnel. Un identificateur assign par le serveur cette. la diffrence de l'identification d'appel, le client et le serveur associent le mme numro d'appel une session donne. La combinaison du numro de srie et de l'adresse IP et d'appel devrait tre unique. 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 Ce champ est configur par le serveur avec le numro de canal physique employ pour cet appel. Il est utilis pour des buts d'enregistrements seulement. Le nombre rel de chiffres valides dans le champ du nombre compos. Le nombre rel de chiffres valides dans le champ du nombre composer. Le numro qui a t compos par l'appelant. Pour des appels de numriques et analogiques ce champ est une chane de caractres ascii. Si le numro compos est moins de 64 octets de longueur, le reste de ces champs est rempli d'octets de valeur 0. Le numro qui est composer. Pour des appels de numriques et analogiques ce champ est une chane de caractres ascii. Si le numro compos est moins de 64 octets de longueur, le reste de ce champs est rempli d'octets de valeur 0. Une zone de 64 octets indiquant de l'information supplmentaire.

Incoming-Call-Reply L'Incoming-Call-Reply est un message envoy par le client en rponse un message d'Incoming-CallRequest. La rponse indique le rsultat de la tentative d'appel d'arrive. Elle fournit galement des informations pour permettre au client de rgler la transmission de donnes. Il indique au serveur si l'appel doit tre rpondu ou pas.
16 bit PPTP Message Type Magic Cookie 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 contrle Incoming-Call-Reply

16 bit Length

Dscription des champs de la trame: Length PPTP Message Type

Travail de diplme Tutorial VPN

Longueur totale en octets du message PPTP. L'entte est incluse. Valeur 1 pour un message de contrle.
Page 24

Christian Tettamanti

Magic Cookie

Valeur 0x1A2B3C4D. Cette constante est utilise comme test pour les paquets reus. 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 employe pour multiplexer et dmultiplexer des donnes envoyes dans le tunnel. Peer's Call ID Dans ce champ se trouve la valeur reue dans le champ d'identification d'appel du message Incoming-Call-Request. Elle est employe par le serveur pour comparer l'Incoming-Call-Reply avec l'Incoming-Call-Request qu'il a mis. Result Code Indique le rsultat de la requte Incoming-Call-Request. Les valeurs possibles sont: 1 - Connexion tablie avec succs 2 - Erreur gnrale. Si dfini, il est spcifi dans le champ Error Code 3 - (Do Not Accept) Le serveur n'accepte pas la requte. Il doit accrocher ou envoyer un signal d'occupation Error Code Tant qu'il n'y a pas d'erreur gnrale, ce champ vaut 0. Sinon il indique le type d'erreur. Packet Recv. Window Size Le nombre de paquets de donnes reus que le serveur protgera pour cette session. Packet Transmit Delay Une mesure du retard de traitement de paquet qui pourrait tre impos aux donnes a envoy au serveur. Cette valeur est indique dans les units de 1/10 de secondes. Pour le client ce nombre devrait tre trs petit. Reserved1 Ce champ doit tre 0. Incoming-Call-Connected Le message d'Incoming-Call-Connected est un message envoy par le serveur en rponse un IncomingCall-Reply reu. Il fournit des informations au client au sujet des paramtres particuliers utiliss pour l'appel. Il fournit un mcanisme pour donner au client des informations supplmentaires sur l'appel qui ne peut pas, en gnral, tre obtenu lorsque l'Incoming-Call-Request est mis par le serveur.
16 bit PPTP Message Type Magic Cookie Control Message Type Reserved0 Peer's Call ID Reserved1 Connect Speed Packet Recv. Window Size Packet Transmit Delay Framing Type
Figure 20 : message de contrle Incoming-Call-Connected

16 bit Length

Dscription des champs de la trame: Length PPTP Message Type Magic Cookie Control Message Type Reserved0
Travail de diplme Tutorial VPN

Longueur totale en octets du message PPTP. L'entte est incluse. Valeur 1 pour un message de contrle. Valeur 0x1A2B3C4D. Cette constante est utilise comme test pour les paquets reus. Valeur 11 pour indiquer le message Incoming-Call-Connected. Ce champ doit tre 0.
Page 25

Christian Tettamanti

Peer's Call ID

Dans ce champ se trouve la valeur reue dans le champ d'identification d'appel du message Incoming-Call-Reply. Elle est employe par le client pour comparer l'Incoming-Call-Connected avec l'Incoming-Call-Reply qu'il a mis. Connect Speed La vitesse relle de connexion utilise, en bits/sec. Packet Recv. Window Size Le nombre de paquets de donnes reus que le serveur protgera pour cette session. Packet Transmit Delay Une mesure du retard de traitement de paquet qui pourrait tre impos aux donnes a envoy au serveur. Cette valeur est indique dans les units de 1/10 de secondes. Pour le client ce nombre devrait tre trs 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 contrle 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 rpond ce message avec un Call-Disconnect-Notify.
16 bit PPTP Message Type Magic Cookie Control Message Type Reserved0 Call ID Reserved1 Framing Type
Figure 21 : message de contrle Call-Clear-Request

16 bit Length

Dscription des champs de la trame: Length PPTP Message Type Magic Cookie Control Message Type Reserved0 Call ID Reserved1 Longueur totale en octets du message PPTP. L'entte est incluse. Valeur 1 pour un message de contrle. Valeur 0x1A2B3C4D. Cette constante est utilise comme test pour les paquets reus. Valeur 12 pour indiquer le message Call-Clear-Request. Ce champ doit tre 0. Le numro d'authentification assign par le client cet appel. Ce champ doit tre 0.

Call-Disconnect-Notify

Travail de diplme Tutorial VPN

Page 26

Christian Tettamanti

Le message de Call-Disconnect-Notify est un contrle envoy par le serveur. Il est mis toutes les fois qu'un tunnel est ferm, en raison de la rception 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 PPTP Message Type Magic Cookie Control Message Type Reserved0 Call ID Result Code Error Code Cause Code Reserved1 Call Statistics (128 octets)
Figure 22 : message de contrle Call-Disconnect-Notify

16 bit Length

Dscription des champs de la trame: Length PPTP Message Type Magic Cookie Longueur totale en octets du message PPTP. L'entte est incluse. Valeur 1 pour un message de contrle. Valeur 0x1A2B3C4D. Cette constante est utilise comme test pour les paquets reus. Control Message Type Valeur 13 pour indiquer le message Call-Disconnect-Notify. Reserved0 Ce champ doit tre 0. Call ID Le numro d'authentification assign par le serveur cet appel. Result Code Indique la raison de la dconnexion. Les valeurs possibles sont: 1 (Lost Carrier) - Perte de la porteuse 2 (General Error) - Erreur gnrale 3 (Admin Shutdown) - Dconnect pour der raisons administratives 4 (Request) - Dconnect a cause d'une requte Call-Clear-Request Tant qu'il n'y a pas d'erreur gnrale, ce champ vaut 0. Sinon il indique le type d'erreur. Ce champ fournit l'information supplmentaire de panne. Sa valeur peut changer dpendance du type d'appel. Ce champ contient un texte ascii contenant des statistiques d'appel et qui peuvent tre enregistrs pour des diagnostiques. Si la longueur de ce texte est infrieure 128, les bit restants sont mis 0.

Error Code Cause Code Call Statistics

Travail de diplme Tutorial VPN

Page 27

Christian Tettamanti

6.2.9.3

Messages d'erreurs

WAN-Error-Notify Le message WAN-Error-Notify est un message de contrle 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 PPTP Message Type Magic Cookie 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 contrle WAN-Error-Notify

16 bit Length

Dscription des champs de la trame: Length PPTP Message Type Magic Cookie Control Message Type Reserved0 Peer's Call ID Reserved0 CRC Errors session. Framing Errors Hardware Overruns Buffer Overruns Time-out Errors Alignment Errors Longueur totale en octets du message PPTP. L'entte est incluse. Valeur 1 pour un message de contrle. Valeur 0x1A2B3C4D. Cette constante est utilise comme test pour les paquets reus. Valeur 14 pour indiquer le message Wan-Error-Notify. Ce champ doit tre 0. Call ID assign par le client. Ce champ doit tre 1. Nombre de trames PPP reues avec erreur CRC depuis le dbut de la Nombre d'erreurs dans les paquets PPP. Nombre de buffer over-runs en reception depuis le dbut de la session. Nombre de buffer over-runs depuis le dbut de la session. Nombre de time-outs depuis le dbut de la session. Nombre d'erreurs d'alignement depuis le dbut de la session.

Travail de diplme Tutorial VPN

Page 28

Christian Tettamanti

6.2.9.4

Messages de gestion de la session PPP

Set-Link-Info Le message de Set-Link-Info est un message de contrle envoy par le client pour paramtrer 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 excuter la ngociation de PPP sur une session active de PPP.
16 bit PPTP Message Type Magic Cookie Control Message Type Reserved0 Peer's Call ID Reserved1 Send ACCM Receive ACCM
Figure 24 : message de contrle Set-Link-Info

16 bit Length

Dscription des champs de la trame: Length PPTP Message Type Magic Cookie Control Message Type Reserved0 Peer's Call ID Reserved0 Send ACCM Receive ACCM Longueur totale en octets du message PPTP. L'entte est incluse. Valeur 1 pour un message de contrle. Valeur 0x1A2B3C4D. Cette constante est utilise comme test pour les paquets reus. Valeur 15 pour indiquer le message Set-Link-Info. Ce champ doit tre 0. Call ID assign par le client. Ce champ doit tre 0. Valeur utilis par le client pour traiter les paquets PPP sortants. La valeur par dfaut est 0XFFFFFFFF. Valeur utilis par le client pour traiter les paquets PPP entrants. La valeur par dfaut est 0XFFFFFFFF.

Codes d'erreur gnraux. Les codes d'erreurs gnraux concernent des types d'erreurs qui ne sont pas spcifiques dans aucune requte particulire de PPTP, mais plutt des erreurs de format de protocole ou de message. Si une rponse PPTP indique qu'une erreur gnrale s'est produite, la valeur gnrale d'erreur devrait tre examine. Les codes d'erreur gnraux actuels dfinis et leurs significations sont: 0 (None) 1 (Not-Connected) 2 (Bad-Format) 3 (Bad-Value) 4 (No-Resource) 5 (Bad-Call ID) 6 (Server-Error) Aucune erreur gnrale Connexion de contrle inexistante Longueur ou Magic Cookie incorrects Champs rservs non 0, ou valeur incorrecte dans un champ Ressources insuffisantes pour excuter l'opration Identificateur d'appel Call ID incorrect Erreur gnrique dans le serveur

Travail de diplme Tutorial VPN

Page 29

Christian Tettamanti

Les messages de contrle sont envoys dans des paquets TCP (port 1723). Une fois que la connexion est cre entre le client et le serveur, cette connexion de contrle est utilise pour l'change de messages de contrle Chaque datagramme contient une entte PPP, une entte TCP, un message de contrle PPTP et des conteneurs appropris. La figure suivante montre un datagramme PPTP avec des messages de contrle.
PPTP Control Message TCP IP Header PPP Delivery Header
Figure 25 : Datagramme PPTP avec message de contrle.

L'change de messages entre le client et le serveur PPTP travers la connexion TCP est utilis pour la cration 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 contrle se fera directement entre lui et le serveur. Toutefois, il faudra s'assurer que la connexion entre le vrai client et l'ISP est scurise. Par exemple, lorsqu'on se connecte travers une ligne tlphonique, l'on pourra dire que la connexion est dj scurise, car on utilise un mdia 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 mdia utilis; le cble coaxial tant un mdia partag.

6.2.10 Transmission de donnes PPTP

Une fois que le tunnel PPTP est tabli, les donnes de l'utilisateur sont transmises depuis le client vers le serveur PPTP. Ces donnes sont transmises dans des paquets PPP contenus dans des datagrammes IP. Les datagrammes IP sont gnrs 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 gnrique pour l'encapsulation. La version utilise par PPTP est lgrement diffrente par rapport au protocole GRE dfini dans les RFC 1701 et 1702. La diffrence principale comporte la dfinition d'un nouveau champ d'accus de rception, employe pour dterminer si un paquet de GRE ou un ensemble particulier de paquets est arriv l'extrmit distante du tunnel. Cette capacit d'accus de rception n'est pas utilise avec une retransmission des paquets de donnes utilisateur. Elle est employe pour dterminer la cadence laquelle les paquets utiles doivent tre transmis dans le tunnel pour une session donne. L'entte IP donne les informations ncessaires l'acheminement des datagrammes travers Internet. L'entte GRE est utilise 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 diplme Tutorial VPN

Page 30

Christian Tettamanti

Le datagramme IP GRE cre 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 Length Key (LW) Call ID Sequence Number (Optional) Acknowledgment Number (Optional)
Figure 26 : Datagramme GRE

Dscription des champs de la trame: C (bit 0) R (bit 1) K (bit 2) S (bit 3) S (bit 4) Recur (bits 5-7) A (bit 8) Flags (bits 9-12) Ver (bits 13-15) Protocol Type Key Payload Length Key Call ID Sequence Number Acknowledgment Number Checksum prsent. Ce champ doit tre 0. Routage prsent. Ce champ doit tre 0. Cl prsente. Ce champ doit tre 1. Numro de squence. Ce champ doit tre 1.si un paquet utile (donnes) est prsent. Ce champ doit tre 0. si la charge utile n'est pas prsente (le paquet de GRE est un accus de rception seulement). Routage de source prsent. Ce champ doit tre 0. Commande de rcursivit. Ces champs doivent tre 0. Numro de squence d'accus de rception. Ce champ doit tre 1si le paquet contient le nombre d'accus de rception. utiliser pour reconnatre des donnes prcdemment transmises. Ces champs doivent tre 0. Ce champ doit tre 1 (GRE avanc). Ce champ doit tre 0x0880B. Taille des donnes utiles. L'entte GRE n'est pas incluse. Contient l'identificateur de l'appel pour cette session. Contient le numro de sequence des donnes. Il est prsent si le bit S (bit 3) est 1. Contient le numro de squence du paquet GRE reu par le pair pour cette session d'utilisateur. Prsent si le bit A (bit 8) est 1.

La figure suivante montre les diffrentes encapsulations des donnes utiles dans le cas de PPTP:
Data TCP Header IP Header PPP Header GRE Header IP Header PPP Delivery Header
Figure 27 : Encapsulation des donnes dans GRE dans le cas de PPTP.

Travail de diplme Tutorial VPN

Page 31

Christian Tettamanti

6.2.11 Exemple de connexion

Aprs avoir vu les diffrents 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 diffrents changes. Pour simplifier, on a pris le cas d'un client et d'un serveur se trouvant dans le mme rseau. Dans la figure suivante sont montrs les changes de ces messages.

Start-Control-Request Start-Control-Reply Outgoing-Call-Request Outgoing-Call-Reply

TCP 1723

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 diplme Tutorial VPN

Page 32

Christian Tettamanti

6.2.12 La scurit de PPTP

6.2.12.1 Authentification Une authentification initiale peut tre exige par le serveur d'accs rseau NAS de l'ISP. Si cette authentification est exige, elle doit tre gre par le serveur d'accs rseau de l'ISP. Il faut vrifier avec l'ISP les conditions d'authentification. La deuxime authentification est faite par le serveur PPTP mme. C'est lui qui donne tout accs au rseau priv. C'est--dire, le serveur de PPTP est la passerelle du rseau 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 mmes mthodes d'authentification de PPP employes par n'importe quel client NAS. L'implmentation de Microsoft (et de Linux) du service d'accs 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 manire plus dtaille. PAP (Password Authentication Protocol) est un simple schma 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 schma d'authentification n'est pas sr, car un tiers pourrait capturer le nom et le mot de passe de l'utilisateur et l'employer pour obtenir un accs 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 mcanisme 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 chane de caractres gnre alatoirement. 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 prsente en tant qu'une amlioration du PAP, car le mot de passe n'est pas envoy en clair. Ceci dit, le mot de passe est employ, afin de crer un code de hachage de l'preuve initiale. Le serveur connat le mot de passe du client (en clair) et il doit faire, de son ct, la mme opration de hachage. Ensuite, il compare le rsultat au mot de passe introduit dans la rponse du client. Si les deux codes de hachage correspondent, l'utilisateur est authentifi. Le CHAP se protge contre les attaques d'usurpation d'identit l'aide d'une chane de caractres d'preuve. Chane gnre alatoirement pour chaque tentative d'authentification. Le CHAP se protge contre ces attaques en envoyant de manire imprvisible des preuves rptes au client distant pendant toute la dure de la connexion.

Travail de diplme Tutorial VPN

Page 33

Christian Tettamanti

MS-CHAP (Microsoft Challenge Handshake Authentication Protocol) est un mcanisme d'authentification chiffr, trs 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 chane de caractres alatoire. 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 supplmentaire de scurit. Le serveur possde les codes de hachage des mots de passe seulement, au lieu des mots de passe en clair. MS-CHAP fournit des codes d'erreur supplmentaires galement, y compris un code pour les mots de passe expirs, et des messages chiffrs supplmentaires permettant des utilisateurs de changer leurs mots de passe. Dans MS-CHAP, le client et le NAS produisent, chacun de leur ct, une premire cl pour un chiffrement ultrieur par MPPE (Microsoft Point-toPoint Encryption). Par consquent, l'authentification de MS-CHAP est exige, afin de permettre le chiffrement de donnes bas sur MPPE. L'encryptage MPPE sera dcrit dans le chapitre 6.2.14.1.

Une gestion soigneuse des comptes d'utilisateur est ncessaire pour rduire les risques de scurit. Avoir un modle sr de la structure des mots de passe est critique pour le bon dploiement de PPTP. Ceci, car les connexions Internet sont plus susceptibles d'tre attaques : des crackers pourraient essayer des milliers de combinaisons de mot de passe et de nom d'utilisateur, afin de s'introduire dans le rseau priv. La seule faon de rduire au minimum ce type d'attaque est de choisir une politique de mot de passe sre. Par exemple, une bonne politique consisterait exiger l'usage de mots de passe contenant un mlange de lettres majuscules, minuscules, ainsi que de nombres, et de caractres spciaux.

6.2.13 Contrle d'accs

Aprs l'authentification, tout accs au rseau local priv continue utiliser le modle de scurit interne. Par exemple, si on utilise un sous-rseau utilisant des serveurs WinNT, les accs aux ressources NTFS partages continueront exiger les permissions appropries, mme pour les accs des clients PPTP.

6.2.14 Le chiffrement de donnes

Pour le chiffrement de donnes, PPTP utilise le procd de chiffrement "shared-secret", ou secret partag, du NAS. Il est dsign sous le nom de secret partag, car les deux bouts de la connexion partagent la mme cl de chiffrement. Dans l'implmentation de Microsoft, le secret partag est le mot de passe de l'utilisateur. D'autres mthodes de chiffrement se basent sur des cls publiques; cette deuxime mthode de chiffrement est connue en tant que chiffrement par cl publique. PPTP utilise les mmes schmas de chiffrement et de compression que PPP. Le CCP (Compression Control Protocol) employ par PPP est utilis pour ngocier 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 drive par les mots de passe hachs, qui se trouvent enregistrs sur le client et le serveur. Le standard RSA RC4 est utilis pour la cration de cette cl de session de 40-bit ou de 128-bit. La cl tant base sur le mot de passe du client. Cette cl est employe pour le chiffrement de toutes les donnes qui traversent le tunnel PPTP; ceci assure une connexion prive et sre. Les donnes dans les paquets PPP sont chiffres. Le paquet PPP contenant un bloc de donnes encryptes 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 enttes IP, et le paquet PPP contenant le bloc de donnes encryptes, qui se prsenterait indchiffrable.

Travail de diplme Tutorial VPN

Page 34

Christian Tettamanti

6.2.14.1 Cryptage MPPE PPTP hrite 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 cls de chiffrement de 128 bit. La cl 40 bit fournit la compatibilit avec des clients utilisant des anciennes versions de Windows. Par dfaut, la cl la plus grande supporte par le client VPN et le serveur VPN est ngocie pendant le processus d'tablissement de connexion. Si le serveur VPN exige une cl plus rsistante que celle support par le client, la tentative de connexion est rejete. MPPE a t initialement conu pour le chiffrement avec un lien point point, o les paquets arrivent dans la mme ordre dans laquelle ils ont t envoys. Dans cet environnement, le dchiffrage de chaque paquet dpend du dchiffrage du paquet prcdent. Pour les VPN, cependant, les datagrammes IP envoys travers Internet arrivent dans un ordre diffrent de celle dans laquelle ils ont t envoys, et une partie des paquets peut tre dtruite. Par consquent MPPE change la cl de chiffrement pour chaque paquet. Le dchiffrage de chaque paquet est indpendant du paquet prcdent. MPPE inclut un numro de squence dans son entte. Si des paquets sont dtruits ou ont des erreurs, les cls de chiffrement sont changes relativement au numro de squence. 6.2.14.2 Filtrage de paquet PPP Les activits malveillantes peuvent tre limites en activant le filtrage sur le serveur PPTP. Quand le filtrage PPTP est activ, le serveur reoit et route seulement les paquets des utilisateurs authentifis. Ceci empche tous les autres paquets d'entrer dans le rseau priv. Avec le chiffrement de PPP, ceci assure que seulement les donnes chiffres autorises entrent ou sortent du rseau 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 scurit du rseau en filtrant les donnes qui le traversent. Une organisation peut mettre son serveur PPTP derrire un firewall. Le serveur PPTP reoit les paquets de PPTP passs par le firewall et extrait les paquets PPP partir du datagramme IP, dchiffre le paquet, et expdie le paquet l'ordinateur sur le rseau priv.

Figure 30: Serveur PPTP derrire un firewall.

Travail de diplme Tutorial VPN

Page 35

Christian Tettamanti

6.3 L2TP Layer 2 Tunneling Protocol PPP (RFC1661. Voir CD annexe) dfinit un mcanisme 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'accs rseau (NAS) en utilisant par exemple une ligne analogique, une ligne RNIS, ADSL, etc. et cre 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 rsident dans le mme dispositif physique. L2TP tend le modle PPP, permettant ainsi aux points finaux de la connexion L2 et PPP de rsider sur des dispositifs diffrents interconnects par un rseau de commutation de paquets. Avec L2TP, un utilisateur a une connexion L2 avec un concentrateur d'accs (par exemple, un modem, ADSL, etc.), et le concentrateur envoie dans le tunnel les diffrentes trames PPP destination du NAS. Ceci permet au traitement des paquets PPP d'tre spars de la terminaison du circuit L2. Un avantage vident d'une telle sparation est qu' la place d'exiger la terminaison de la connexion L2 au NAS (qui peut exiger un appel long distance coteux), la connexion peut se terminer au concentrateur de circuit local, lequel tend la session PPP logique au-dessus d'une infrastructure partage telle que Frame Relay ou Internet. Du point de vu de l'utilisateur, il n'y a aucune diffrence 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 contrle et de messages de donnes. Les messages de contrle sont utiliss dans l'tablissement, l'entretien et l'effacement des tunnels et des appels. Les messages de donnes sont utiliss pour l'encapsulation des trames PPP dans le tunnel. Les messages de contrle utilisent un canal fiable pour en garantir la livraison. Les messages de donnes ne sont pas retransmis quand un erreur survient.
PPP Frames
L2TP Data Messages L2TP Data Channel L2TP Control Messages L2TP Control Channel

(unreliable)

(reliable)

Packet Transport (UDP, FR, ATM, etc.) Figure 31 : Structure du protocole L2TP

La figure prcdente montre le rapport des trames PPP et des messages de contrle au-dessus des canaux de contrle et de donnes de L2TP. Les trames PPP sont envoyes dans un canal de donnes, encapsuls d'abord par une entte L2TP et puis dans un paquet de transport tel que UDP, Frame Relay, ATM, etc. Les messages de contrle sont envoys dans un canal fiable L2TP qui transmet des paquets inband au-dessus du mme paquet de transport. Les numros de squence sont exigs dans tous les messages de contrle et sont employs pour fournir une livraison fiable dans le canal. Les messages de donnes peuvent employer des numros de squence pour demander nouveau des paquets et pour dtecter les paquets perdus. Toutes les valeurs sont places dans leurs champs respectifs et introduites dans la commande (octets d'ordre suprieur d'abord).

Travail de diplme Tutorial VPN

Page 36

Christian Tettamanti

6.3.2 Format de l'entte L2TP

Les paquets L2TP pour le canal de contrle et des donnes partagent un format commun d'entte. Dans tous les cas o un champ est facultatif et marqu comme non prsent, son espace n'est pas utilis dans le message. noter que les champs Length, Ns et Nr. Fields marqus comme facultatifs pour des messages de donnes, sont requis pour tous les messages de contrle.
16 bit

T L x x S x O P x x x x
Tunnel ID Ns (opt) Offset Size (opt)

Ver

16 bit Length (opt) Session ID Nr (opt) Offset pad... (opt)

Figure 32 : Entte L2TP.

Dscription des champs de la trame:: Type (T) Length (L) x Sequence (S) Offset (O) Priority (P) Indique le type du message. Il peut avoir les valeurs suivantes: 0 Message de donnes 1 Message de contrle Si 1, le champ Length existe. Ce bit doit tre 1 pour tous les messages de contrle. Les bits 'x' sont rservs pour des extension futures du protocole. Ces bits doivent tre 0 pour les messages sortant et ignors pour les messages entrants. Si 1, le champ Ns et Nr existent. Ce bit doit tre 1 pour tous les messages de contrle. Si 1, le champ Offset existe. Ce bit doit tre 1 pour tous les messages de contrle. Si 1, le traitement de ce message de donnes doit tre prioritaire dans la queue locale et dans la transmission. Les echo-requests utiliss pour maintenir la connexion doivent tre envoys avec ce bit 1, sinon peut arriver une congestion temporaire et une perte de donnes. Cette fonctionnalit est utilise seulement avec des messages de donnes. Ce bit doit tre 0 pour tous les messages de contrle. Ce champ doit valoir 2. Il indique la version de l'entte L2TP pour des paquets de donnes. Ce champ indique la longueur du message en octets. Indique l'identificateur pour la connexion de contrle. Les tunnels L2TP sont nomms par des identificateurs qui ont une signification locale seulement. C'est--dire, pour le mme tunnel sera donn un ID diffrent pour chaque extrmit du tunnel. Indique l'identificateur pour une session dans un tunnel. Les sessions L2TP sont nommes d identificateurs qui ont une signification locale seulement. C'est--dire, pour la mme session sera donne un ID diffrent pour chaque extrmit de la session. Indique le numro de squence pour ce message de donnes ou de contrle, commenant 0 et incrmentant par un (modulo 216) pour chaque message envoy.

Ver Length Tunnel ID

Session ID

Ns

Travail de diplme Tutorial VPN

Page 37

Christian Tettamanti

Nr

Offset Size

Indique le numro de squence prvu pour le prochain message de contrle reu. Ainsi, Nr est plac au NS du dernier message de contrle reu plus un (modulo 216). Dans les messages de donnes, Nr est rserv et, si prsent (comme indiqu par le bit S), il doit tre ignor la rception. Si prsente, indique le nombre d'octets aprs l'entte L2TP partir desquels on s'attend le dbut des donnes utiles.

6.3.3 Connexion de contrle L2TP

Le protocole L2TP dfini une srie de messages de contrle changs entre le client et le serveur L2TP. Ces commandes tablissent, maintiennent et terminent le tunnel L2TP. La liste suivante reprsente les messages utiliss 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 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 Messages d'erreurs: WAN_ERROR_NOTIFY Messages de gestion de la session PPP: SET_LINK_INFO Configure la connexion entre le client et le serveur Erreur dans la connexion PPP Demande de cration du tunnel de la part du client Rponse la demande de cration du tunnel de la part du client Tunnel en sortie cre Demande de cration du tunnel de la part du serveur Rponse la demande de cration du tunnel de la part du serveur Tunnel en entre cre Rponse la demande de terminaison et fin de la session PPTP Demande de dbut de session Rponse la demande de dbut de session Confirmation la demande de dbut de session Fin de session Demande de maintient la session de contrle

Travail de diplme Tutorial VPN

Page 38

Christian Tettamanti

6.4 IPSec IP Security Protocol Cr par l'IETF3, le protocole IPSec est conceptuellement unique, car il permet de scuriser le rseau mme, et ne pas les applications l'exploitant. Le protocole IPSec garantit la scurit pour chaque application utilisant le rseau. IPSec permet donc la ralisation de VPN trs sres. On doit forcement utiliser IP4 pour le transport des donnes, afin de pouvoir scuriser un rseau 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 scurit et l'intgrit des communications.

6.4.1 Architecture de IPSec

Pour assurer la scurit dans un environnement rseau, il faut s'assurer: Que la personne avec laquelle on communique est rellement cette personne et pas quelqu'un d'autre ! Que personne ne peut couter la communication ! Que les donnes reues n'ont pas ts modifis pendant la transmission !

Ces trois besoins sont traduits en: Authentification; Confidentialit; Intgrit.

Malheureusement, l'architecture des rseaux base sur IP, permettent difficilement d'assurer ces besoins. IPSec offres trois technologies, qui combines entre elles permettent de se protger des diffrentes attaques la scurit: Authentication header (AH) Entte qui attache les donnes de chaque paquet une signature qui vous permet de vrifier l'identit de la personne envoyant les donnes et que les donnes n'ont pas t modifies. Encapsulating Security Payload (ESP) Embrouille les donnes (et mme certaines adresses IP sensibles) de chaque paquet en utilisant le chiffrement dur de noyau - ainsi un renifleur quelque part sur le rseau n'obtiendra rien d'utilisable. Internet Key Exchange (IKE) Un protocole puissant flexible de ngociation qui permet des utilisateurs de convenir sur des mthodes d'authentification, les mthodes de chiffrement, les cls d'utilisation, le temps d'utilisation des cls avant de les changer, et qui permet l'change intelligent et sr des cls.

Le document de rfrence RFC 2401 (voir CD annexe) dcrit les bases de l'architecture IPSec. Il dfinit les services de scurit, la structure des paquets de ces services et quand ils peuvent tre utiliss.

3 4

Internet Engineering Task Force IPSec peut tre utilis avec le standard existant IPv.4 et celui mandataire IPv.6

Travail de diplme Tutorial VPN

Page 39

Christian Tettamanti

IPSec implmente deux protocoles : le AH et le ESP. Ces protocoles permettent IPSec de travailler selon deux modes distincts. Si on veut scuriser tant les donnes que toute la couche IP, on utilisera le mode Tunnel, tandis que si on veut scuriser seulement les donnes on prfrera le mode Transport. Le mode Transport est utilis pour l'acheminement direct des donnes protges par IPSec. Il sert donc pour des configurations Host-to-Host. Dans ce mode, les protocoles AH et ESP protgent la couche transport en interceptant les paquets provenant de la couche transport dans la couche rseau.
Application TCP UDP IPSec IP
Figure 33 : Mode transport d'IPSec.

Application TCP UDP IPSec IP

Dans le mode Tunnel, utilis en gnral pour des configurations LAN-to-LAN, le trafic non protg est envoy vers une passerelle implmentant IPSec. Comme le montre la figure suivante, le gateway encapsule tout le paquet IP, entte comprise, avec l'encryptage de IPSec. Il rajoute ensuite une nouvelle entte IP et envoie ce nouveau paquet travers le rseau public vers le gateway destinataire. L, les paquets sont ensuite dchiffrs et envoys sous forme originale sa propre dstination.
Application TCP UDP IP Donnes protges IPSec IP Gateway IPSec Donnes protges IPSec IP Gateway IPSec Application TCP UDP IP

Figure 34 : Mode tunnel d'IPSec.

Une option importante de IPSec dans le domaine des VPN est la gestion des cls de chiffrage et d'authentification. Cette gestion peut tre manuelle ou automatique avec le protocole IKE. Ce dernier aspect fera l'objet d'une prsentation plus dtaill dans le chapitre 6.4.4. Pour pouvoir encapsuler et dsencapsuler les paquets IPSec, on doit pouvoir en dterminer le sens de transmission. Ceci, afin de pouvoir associer les diffrents services de scurit et les cls avec le trafic unidirectionnel. Une telle construction est appele SA (Security Association). Une SA est identifie par : Un Security Parameter Index (SPI); Le protocole IPSec utilis; L'adresse de destination.

La SA peut tre cre de faon dynamique (dans le cas d'utilisation de IKE), soit manuellement (gestion des cls manuelles). Le temps de vie d'une SA (SA life time) dpend des paramtres choisis lors de sa cration. Dans le cas d'une gnration manuelle, son temps de vie est infini, jusqu' quand la modification d'un paramtre interviendra. Tandis que dans le cas d'une gnration dynamique, son temps de vie est gnralement dfinit par les deux extrmits lors de la phase de ngociation des paramtres (IKE).

Travail de diplme Tutorial VPN

Page 40

Christian Tettamanti

6.4.2 AH (Authentication Header)

Ce protocole implmente les services d'authentification mais non ceux de confidentialit. Il permet donc d'assurer la garantie de l'origine des paquets et l'intgrit des donnes. L'anti-replay est facultatif et peut tre choisi par le rcepteur, lors de l'tablissement de la SA. Bien que I'expditeur incrmente le numro de squence utilis pour l'anti-replay, le service se relve pertinent uniquement si le rcepteur le contrle. Pour autant que possible, AH procure l'authentification de l'entte IP et de ses donnes. En effet, dans l'entte 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 prvisible par l'expditeur. Les valeurs de ces champs ne peuvent ainsi pas tre protges par AH. Ceci dit, la protection assure 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 mmes services d'authentification, il fournit galement un service de confidentialit avec chiffrement. La diffrence entre l'authentification fournie par ESP et AH rside dans la portion des donnes scurises. ESP ne protge aucun champ d'entte IP, moins que ESP soit utilis en mode tunnel (v. chapitre 6.4.3). Aucune encryption des donnes est effectu par le protocole AH, toutefois il dfinit la mthode de protection, le placement de l'entte, la portion couverte par l'authentification et les rgles de traitement des donnes entrantes et sortantes. Cependant, il ne dfinit pas l'algorithme d'authentification utiliser. Actuellement deux algorithmes sont utiliss : HMAC-MD5 et HMAC-SHA. 6.4.2.1 Format de l'entte 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 suprieur sera AH. AH reste toujours plac aprs l'entte ESP, lorsque AH et ESP protgent le mme paquet. La figure suivante montre le format de l'entte AH :
16 bit 16 bit Payload Length Next Header Reseved Security Parameters Index (SPI) Sequence number Authentication data
Figure 35 : Entte du protocole AH.

Dscription des champs de la trame : Next header Payload length Reserved SPI Ce champ indique le protocole de couche suprieur. En mode transport, ce champ indique la premire entte protge (TCP ou UDP), tandis qu'en mode tunnel, il vaut 4, ce qui correspond l'identificateur pour le protocole IP. Taille de l'entte. N'est pas utilis et il est rserv 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 scurit (AH) identifie la SA qui doit tre utilis pour authentifier ce paquet. Elle est d'habitude choisie par Ie systme destinataire, lors de l'tablissement de la SA.
Page 41

Travail de diplme Tutorial VPN

Christian Tettamanti

Sequence number

Authentication data

Numro de squence de 32 bits auto incrment, employ pour se protger d'une retransmission du paquet (fonction d' anti-replay). Ce champ est obligatoire et toujours prsent mme si le rcepteur dsactive la fonction d'anti-replay. La longueur de ce champ dpend de I'algorithme d'authentification utilis. II contient le rsultant du calcul de l'intgrit 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' entte 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 suprieures, ainsi que des champs non modifiables de l'entte IP. AH s'insre la suite de l'entte IP et avant les protocoles de couches suprieurs comme par exemple TCP, UDP, ICMP ou pralablement tous les autres enttes IPSec qui ont dj t insres. La figure suivante montre l'entte AH dans le mode transport:
Original IP Header Next Header Payload Length Reserved Security Parameters Index (SPI) Sequence Number Authentication data IP Payload
Figure 36 : AH en mode Transport

Authentifi

En mode tunnel, l'entte IP originale est place la suite de AH et inclut les adresses de source et de destination finales, alors que la nouvelle entte IP, place antrieurement AH, comporte les adresses des gateways. AH protge l'entte IP originale et ses donnes de mme que les champs non modifiables de la nouvelle entte IP. La figure suivante montre l'entte AH en mode tunnel.
New IP Header Next Header Payload Length Reserved Security Parameters Index (SPI) Sequence Number Authentication data Original IP Header IP Payload
Figure 37 : AH en mode Tunnel.

Authentifi

Travail de diplme Tutorial VPN

Page 42

Christian Tettamanti

6.4.2.3 Traitement des paquets sortants Le protocole AH, pour les paquets sortants, est utilis seulement si configur pralablement dans l'implmentation IPSec utilis. La gnration du numro de squence est ralise comme suit : Lorsque la SA est tablie, le compteur de l'expditeur et le compteur du rcepteur sont initialiss 0. L'metteur incrmente le numro de squence pour sa propre association et annonce la nouvelle valeur dans le champ du numro de squence. Ceci dit, le premier paquet envoy en utilisant la SA donne vaudra 1. Le numro de squence transmis ne doit jamais faire un cycle complet. Si l'anti-replay est autoris, l'expditeur contrle la valeur du numro de squence, afin de s'assurer que le compteur n'aurait pas fait un cycle complet avant d'insrer celle-ci dans le champ prvu. Cela dit, l'ordinateur de l'expditeur et le compteur du rcepteur doivent tre remis l'tat initial en tablissant nouvelle SA et ainsi une nouvelle cl, sauf si gestion manuelle, avant la transmission du paquet 232 de la SA en cours. Les autres champs de l'entte sont ensuite mis jour : le champ SPI aura donc la valeur dfinie 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'entte seront mis 0, afin d'avoir l'entte multiple de 32 bit. Le champ ICV (lntegrity Check Value) est calcul avec l'algorithme d'authentification dfinit par la SA et utilisant comme paramtres la cl d'authentification et le datagramme IP, entte 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 rsultante est place dans le champ de l'entte 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 fragments, ils doivent tre rassembls avant leur traitement. La premire opration effectuer consiste identifier la SA utilise, afin de protger 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 identifie, le paquet est ignor. Une fois la SA reconnue, on procde par la vrification du numro de squence. Cette tape est optionnelle, en fonction de l'activation de l'anti-replay. Cette vrification dtermine s'il s'agit d'un nouveau ou d'un ancien paquet qui a t dj reu. Si ce contrle rvle la prsence d'un paquet dj reu, celui-ci est ignor. Ceci dit, le contrle de l'ICV peut tre effectu. L'ICV reu est mmoris et son champ est mis 0, de mme 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 prcdemment, il est authentifi, autrement rejet. La vrification tant termine, le paquet peut tre transmis la couche suprieure.

Travail de diplme Tutorial VPN

Page 43

Christian Tettamanti

6.4.3 ESP (Encapsulating Security Payload)

Le protocole ESP (Encapsulating Security Payload) est utilis, afin de garantir : La confidentialit des donnes; L'authentification de l'origine des donnes; La protection d'anti-replay; L'intgrit des donnes (sans connexion, par paquet).

La grande diffrence entre l'authentification fournie par AH et celle fournie par ESP se trouve dans le protocole ESP. Avec ce protocole les donnes contenues dans l'entte IP ne sont pas authentifies. De mme que pour AH, le service d'anti-replay est optionnel. La dcision 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'intgrit des donnes avec un algorithme d'authentification. Ces algorithmes doivent absolument tre les mmes pour les deux extrmits de la SA utilisant ESP. 6.4.3.1 Format de l'entte 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 suprieur seraESP. La figure suivante montre le format de l'entte ESP :
16 bit 16 bit Security Parameters Index (SPI) Sequence number Initialization vector Protected data Padding Pad Length Authentication data
Figure 38 : Entte du protocole ESP.

Next Header

Description des champs de la trame : SPI Le SPI correspond une valeur de 32 bits arbitraire qui, en alliance avec l'adresse IP de destination et du protocole de scurit (AH) identifie la SA qui doit tre utilis pour authentifier ce paquet. Elle est d'habitude choisie par Ie systme destinataire, lors de l'tablissement de la SA.. Ce champ est authentifi, mais pas encrypt. Numro de squence de 32 bits auto incrment, employ pour se protger d'une retransmission du paquet (fonction d' anti-replay). Ce champ est obligatoire et toujours prsent mme si le rcepteur dsactive la fonction d'anti-replay. Le traitement de ce champ est fait uniquement par le rcepteur et l'expditeur doit toujours le transmettre. Ce champ est galement authentifi, mais pas encrypt pour la faciliter la dtection des rptitions des paquets. Ce champ contient les donnes chiffres, de mme que le vecteur d'initialisation. Ce dernier est utilis avec l'algorithme d'encryption, afin de
Page 44

Sequence number

Protected data

Travail de diplme Tutorial VPN

Christian Tettamanti

Padding

Padding length Next header Authentication data

produire la confidentialit des donnes. Ce champ est galement authentifi, toutefois pas encrypt. Gnralement, 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 ncessitent 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 dsir. Ce champ donne la longueur du champ padding. Ce champ indique le protocole de couche suprieur. En mode transport, ce champ indique la premire entte protge (TCP ou UDP), tandis qu'en mode tunnel, il vaut 4, qui correspond la valeur pour le protocole IP. La longueur de ce champ dpend de I'algorithme d'authentification utilis. II contient le rsultant du calcul de l'intgrit 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'entte ESP Comme AH, ESP peut tre utilis tant en mode transport qu'en mode tunnel. En mode transport, ESP s'insr la suite de l'entte IP et avant les protocoles de couche suprieurs comme par exemple TCP, UDP, ICMP ou pralablement tous les autres enttes IPSec qui ont dj t insres. La figure suivante montre l'entte ESP dans le mode transport:
Original IP Header Security Parameters Index (SPI) Sequence Number Initialization vector IP Payload Padding Pad Length Next Header Authentication data
Figure 39 : ESP en mode Transport

Encrypt

Authentifi

En mode tunnel, l'entte IP originale est place la suite de ESP et elle inclut les adresses de source et de destination finales, alors que la nouvelle entte IP, place antrieurement ESP, comporte les adresses des gateways. ESP protge l'entte IP originale et ses. La figure suivante montre l'entte ESP en mode tunnel.
New IP Header Security Parameters Index (SPI) Sequence Number Initialization vector Original IP Header IP Payload Padding Pad Length Next Header Authentication data
Figure 40 : ESP en mode Tunnel.

Encrypt

Authentifi

Travail de diplme Tutorial VPN

Page 45

Christian Tettamanti

6.4.3.3 Traitement des paquets sortants Le protocole ESP, pour les paquets sortants, est utilis seulement si configur pralablement dans l'implmentation IPSec utilis. Dans le mode transport, I'entte ESP est insre dans le paquet sortant immdiatement aprs l'entte IP. Le champ protocol type de l'entte 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'entte ESP est insre avant I'entte IP. Le champ next header ESP prend la valeur 4 (qui correspond au protocole IP). Les autres champs de l'entte sont ensuite mis jour: Le champ SPI aura donc la valeur dfinie par la SA,. le champ sequence number prend la valeur du prochain numro de squence (soit 0 s'il s'agit du premier paquet mis par la SA). Enfin les champs padding et padding length seront calculs et affcts. La suite des oprations est indpendante du mode utilis. Le paquet est encrypt avec l'algorithme dfinit par la SA. Cet encryptage commence au dbut des donnes utiles jusqu' la fin du champ next header. Ensuite, le paquet est authentifi par I'algorithme dfinit par la SA depuis le dbut de l'entte ESP jusqu' la fin du champ next header. Le rsultat de l'algorithme d'authentification est insr dans le champ authentication data. La dernire tape effectuer avant d'envoyer le paquet est de recalculer le checksum de I'entte IP qui prcde ESP. Le traitement est maintenant termin et le datagramme peut tre envoy. 6.4.3.4 Traitement des paquets entrants Lorsque le rcepteur reoit un paquet ESP, il ne connat 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 associe. En fait, avant que le paquet soit dcrypt, il n'y a aucun moyen pratique de connatre le mode employ. Ceci, pour se protger des personnes malintentionnes qui pourraient analyser le rseau en cherche de ces informations. La premire opration effectuer consiste identifier la SA utilise, afin de protger 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 identifie, le paquet est ignor. Une fois la SA reconnue, on procde par la vrification du numro de squence. Si ce dernier est valide, cela signifie qu'il n'a jamais t utilis et qu'il doit tre en squence avec la fentre contenue dans la SA. Ceci dit, le contrle de l'ICV peut tre effectu. L'ICV reu est mmoris et son champ est mis 0, de mme 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 prcdemment, il est authentifi, autrement rejet. La vrification tant termine, le paquet peut tre transmis la couche suprieure. 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 dcrypt I'aide de la cl et de I'algorithme dfini par la SA depuis le dbut des donnes utiles jusqu' la fin du champ next header. Une fois le paquet authentifi et dcrypt, il peut tre envoy la couche suprieure s'il s'agit du mode transport (le poste ayant effectu ces oprations 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 mme dispositif).

Travail de diplme Tutorial VPN

Page 46

Christian Tettamanti

6.4.4 IKE (Internet Key Exchange)

Avant que les paquets puissent tre scuriss par IPSec, une association de scurit SA doit exister. Elle peut tre cre manuellement ou dynamiquement. Le protocole IKE (Internet Key Exchange) est utilis pour la cration dynamique de la SA. Le protocole IKE, qui est dcrit par dcrit 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 implmente une partie des protocoles de gestion des cls. 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 cls de SKEME. 6.4.4.1 ISAKMP ISAKMP permet la dfinition de la communication entre deux pairs, comment sont construit les messages qu'ils utilisent dans cette communication, et les diffrentes tapes qu'ils doivent passer pour la scuriser. ISAKMP donne les lments ncessaires I'authentification d'un pair, I'change d'informations pour l'change des cls et la ngociation des services de scurit. Les messages transmis dans un change ISAKMP sont structurs sous forme d'une chane de donnes utiles attachs une entte d'ISAKMP, comme montr par la figure suivante.
16 bit Initiator cookie Responder cookie
Next Payload Major Version Minor Version Exchange Type Flags

16 bit

Message ID Message Length

Figure 41 : Entte ISAKMP.

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 rpondu la demande d'initiation de I'tablissement, la modification ou la suppression de la SA. Next payload Indique le type des premires donnes utiles contenues dans le message. Major/Minor version Indique la version d'ISAKMP utilis. Exchange type Indique le type d'change utilis et dfini I'ordre des messages et des donnes utiles de I'change ISAKMP. Flags Indiquent les diffrentes 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 donnes dfinies par ISAKMP est toujours la mme et elle est montr par la figure suivante :
16 bit Next Header Reserved 16 bit Payload Length

Figure 42 : Entte gnrique de ISAKMP.

Travail de diplme Tutorial VPN

Page 47

Christian Tettamanti

Certains de ces messages dpendent les un des autres. Par exemple, le security association payload encapsule un proposal payload, qui lui-mme contient un transform payload. Les messages dfinis dans ISAKMP sont : Hash payload : il contient le message condens d'une fonction de hachage particulire; Signature payload : il contient la signature numrique; Nonce payload : il contient certaines informations pseudo alatoires ncessaires 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 ncessaires pour effectuer I'change des cls; 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) Length: 52 Domain of interpretation: IPSEC (1) Situation: IDENTITY (1)

Proposal payload
Next payload: NONE (0) Length: 40 Proposal number: 1 Protocol ID: ISAKMP (1) SPI size: 0 Number of transforms: 1

Transform payload
Next payload: NONE (0) Length: 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 chanage possible dans un message ISAKMP.

Travail de diplme Tutorial VPN

Page 48

Christian Tettamanti

KE Nonce 0

Initiator Cookie Responder Cookie Version Exchange Flags Message ID Message Length 0 KE Payload Length KE Payload Data 0 Nonce Payload Length Nonce Payload Data
Figure 43 : Chanage possible d'un message ISAKMP.

ISAKMP Header

Key Exchange Payload Nonce Payload

6.4.4.1.1 Echanges et phases ISAKMP dfinit deux phases lors de la ngociation des paramtres. La premire phase concerne l'authentification des deux pairs et la scurisation du canal entre eux. La deuxime phase utilise le canal scuris pour ngocier les paramtres de scurit des diffrents protocoles IPSec. ISAKMP dfinit cinq types d'change, dont : Base exchange; Identity protection exchange; Authentication only exchange; Agressive exchange; Informational exchange.

6.4.4.2 IKE ISAKMP ne dfinissant pas d'change de cls, c'est le rle d'autres protocoles de dfinir ces changes. IPSec utilise pour cet effet le protocole IKE, qui lui utilise le support d'lSAKMP pour dfinir l'change des cls. IKE dfinit plusieurs types de messages et d'options applicables ces changes; leur but est celui de crer l'association de scurit SA dans les deux pairs l'aide des deux phases d'lSAKMP. La premire est utilise pour crer une SA IKE et la deuxime pour ngocier les paramtres ncessaires la cration de la SA IPSec. Pour la premire 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 deuxime phase, IKE dfinit un quick mode exchange. Ce dernier ngocie les diffrents paramtres 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 utiliss six messages, trois requtes et trois rponses, pour tablire la SA IKE. Ces messages font partie de trois tapes : change des paramtres Diffie-HeIIman, tel que le group; change d'un payload nonce; Authentification des deux pairs.

Ces changes sont montrs par la figure suivante :

Travail de diplme Tutorial VPN

Page 49

Christian Tettamanti

Pair 1 Header + SA

Pair 2

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 ngociation des paramtres ncessaires la mise en place de la SA d'IKE. Le deuxime change sert la ngociation des valeurs publiques de I'algorithme Diffie-Hellman et des valeurs pseudo-alatoires contenues dans le nonce payload. Lors du dernier change les deux pairs s'envoient leur identit respective et le hash digest ncessaire I'authentification. 6.4.4.2.2 Aggressive Mode Exchange Les donnes changes en mode agressive mode exchange sont les mmes que celles pour le main mode exchange. La seule diffrence existante entre ces deux modes rside dans le nombre de paquets changs passe de six trois. En rduisant le nombre de paquets changs, I'aggressive mode exchange limite sa puissance de ngociation. 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 scurit, tel que AH et ESP. Le quick mode est effectu sous la protection de la SA IKE prcdemment tablie. Dans un change en quick mode, les deux pairs ngocient les caractristiques de la SA IPSec tablir, et gnrent les cls correspondantes. La SA IKE protge ces changes en chiffrant et en authentifiant les messages transmis.

Cet change est montr par la figure suivante :

Pair 1
Travail de diplme Tutorial VPN

Pair 2 Page 50

Header + Hash + SA + Nonce [KE, Idci, Idcr] Header + Hash + SA +

Christian Tettamanti

Figure 45 : Quick Mode Exchange.

En plus de l'entte ISAKMP, du Hash, de la SA, du Nonce et des paramtres 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 problmatique des rseaux privs virtuels, notamment les problmes lis aux protocoles tudis. Le tutorial donne un vaste aperu des protocoles le plus souvent utiliss, comme PPTP, L2TP et IPSec. Les sujets traits sont mis en pratique dans le laboratoire annexe intitul Laboratoire sur les VPN.

Travail de diplme Tutorial VPN

Page 51

Christian Tettamanti

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 (annexs)

[CISCO1] What is a VPN? - White Paper Authors : Paul Ferguson, Geoff Huston April 1998 Cisco 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

[MICROSOFT1] [RFC2401] [RFC2402] [RFC2403] [RFC2404] [RFC2405] [RFC2406] [RFC2407] [RFC2408] [RFC2409] [RFC2410] [RFC2411] [RFC2412]

8.3

Complments (annexs)
[TUTORIAL1] Tutorial VPN C.Tettamanti 2000 TCOM EiVD Installation de Linux Slackware pour des solutions VPN C.Tettamanti 2000 TCOM - EiVD [CONFIG1] Configuration dun VPN PPTP et IPSec C.Tettamanti 2000 TCOM - EiVD

[CONFIG0]

Travail de diplme Tutorial VPN

Page 52