1. Introduction
PPTP permet de séparer les fonctions existantes du serveur d'accès réseau (Network Access Server, NAS) en utilisant une architecture client-serveur. Traditionnellement, les fonctions suivantes sont implémentées par un NAS :
-
Interface physique native avec PSTN ou ISDN et contrôle des modems externes ou adaptateurs de terminal
Un NAS peut s'interfacer directement à un circuit analogique ou numérique de télécommunication ou se connecter via un modem externe ou un adaptateur de terminal. Le contrôle d'une connexion à commutation de circuit est réalisé soit par contrôle de modem, soit par les protocoles de contrôle d'appel DSS1 ISDN.
Le NAS, en conjonction avec le modem ou les adaptateurs de terminal, peut effectuer l'adaptation de débit, la conversion analogique vers numérique, la conversion synchrone vers asynchrone ou un certain nombre d'autres modifications des flux de données.
-
Terminaison logique d'une session de protocole de contrôle de liaison (Link Control Protocol, LCP) du protocole point à point (Point-to-Point Protocol, PPP)
-
Participation aux protocoles d'authentification PPP [3,9,10]
-
Agrégation de canaux et gestion de faisceau pour le protocole PPP multilink (Multilink Protocol)
-
Terminaison logique de divers protocoles de contrôle réseau (Network Control Protocol, NCP) PPP
-
Routage multiprotocole et pontage entre les interfaces NAS
PPTP répartit ces fonctions entre le PAC et le PNS. Le PAC est responsable des fonctions 1, 2 et éventuellement 3. Le PNS peut être responsable de la fonction 3 et est responsable des fonctions 4, 5 et 6. Le protocole utilisé pour transporter les unités de données de protocole (Protocol Data Unit, PDU) PPP entre le PAC et le PNS, ainsi que le contrôle d'appel et la gestion sont traités par PPTP.
Le découplage des fonctions NAS offre ces avantages :
Gestion flexible des adresses IP. Les utilisateurs d'accès distant peuvent maintenir une seule adresse IP lorsqu'ils se connectent à différents PAC tant qu'ils sont servis par un PNS commun. Si un réseau d'entreprise utilise des adresses non enregistrées, un PNS associé à l'entreprise attribue des adresses significatives pour le réseau privé.
Support de protocoles non-IP pour les réseaux d'accès distant derrière des réseaux IP. Cela permet, par exemple, de tunneliser AppleTalk et IPX à travers un fournisseur IP uniquement. Le PAC n'a pas besoin d'être capable de traiter ces protocoles.
Solution au problème de « fractionnement du groupe de chasse multilink ». Le PPP multilink (Multilink PPP), généralement utilisé pour agréger les canaux B ISDN, exige que tous les canaux composant un faisceau multilink soient regroupés sur un seul NAS. Puisqu'un faisceau PPP multilink peut être géré par un seul PNS, les canaux composant le faisceau peuvent être répartis sur plusieurs PAC.
1.1. Objectifs et hypothèses du protocole (Protocol Goals and Assumptions)
Le protocole PPTP est implémenté uniquement par le PAC et le PNS. Aucun autre système n'a besoin d'être conscient de PPTP. Les réseaux d'accès distant peuvent être connectés à un PAC sans être conscients de PPTP. Les logiciels clients PPP standard devraient (SHOULD) continuer à fonctionner sur des liaisons PPP tunnelisées.
PPTP peut également être utilisé pour tunneliser une session PPP sur un réseau IP. Dans cette configuration, le tunnel PPTP et la session PPP s'exécutent entre les deux mêmes machines, l'appelant agissant comme un PNS.
Il est envisagé qu'il y aura une relation plusieurs-à-plusieurs entre les PAC et les PNS. Un PAC peut fournir un service à de nombreux PNS. Par exemple, un fournisseur de services Internet peut choisir de prendre en charge PPTP pour un certain nombre de clients de réseau privé et de créer des VPN pour eux. Chaque réseau privé peut exploiter un ou plusieurs PNS. Un seul PNS peut s'associer à de nombreux PAC pour concentrer le trafic provenant d'un grand nombre de sites géographiquement dispersés.
PPTP utilise une version étendue de GRE pour transporter les paquets PPP utilisateur. Ces améliorations permettent de fournir un contrôle de flux et de congestion de bas niveau sur les tunnels utilisés pour transporter les données utilisateur entre PAC et PNS. Ce mécanisme permet une utilisation efficace de la bande passante disponible pour les tunnels et évite les retransmissions inutiles et les débordements de tampon. PPTP ne dicte pas les algorithmes particuliers à utiliser pour ce contrôle de bas niveau, mais il définit les paramètres qui doivent être communiqués afin de permettre à ces algorithmes de fonctionner. Les algorithmes suggérés sont inclus dans la section 4.
1.2. Terminologie (Terminology)
Canal analogique (Analog Channel)
Un chemin de communication à commutation de circuit destiné à transporter de l'audio 3.1 kHz dans chaque direction.
Canal numérique (Digital Channel)
Un chemin de communication à commutation de circuit destiné à transporter des informations numériques dans chaque direction.
Appel (Call)
Une connexion ou tentative de connexion entre deux points terminaux sur un PSTN ou ISDN, par exemple un appel téléphonique entre deux modems.
Connexion de contrôle (Control Connection)
Une connexion de contrôle est créée pour chaque paire PAC-PNS et fonctionne sur TCP. La connexion de contrôle régit les aspects du tunnel et des sessions assignées au tunnel.
Utilisateur d'accès distant (Dial User)
Un système terminal ou routeur connecté à un PSTN ou ISDN à la demande, qui est soit l'initiateur soit le destinataire d'un appel.
Serveur d'accès réseau (Network Access Server, NAS)
Un dispositif fournissant un accès réseau temporaire et à la demande aux utilisateurs. Cet accès est point à point en utilisant des lignes PSTN ou ISDN.
Concentrateur d'accès PPTP (PPTP Access Concentrator, PAC)
Un dispositif connecté à une ou plusieurs lignes PSTN ou ISDN capable d'opération PPP et de gestion du protocole PPTP. Le PAC doit seulement implémenter TCP/IP pour transmettre le trafic à un ou plusieurs PNS. Il peut également tunneliser des protocoles non-IP.
Serveur réseau PPTP (PPTP Network Server, PNS)
Un PNS est conçu pour fonctionner sur des plateformes informatiques/serveurs à usage général. Le PNS gère le côté serveur du protocole PPTP. Puisque PPTP repose entièrement sur TCP/IP et est indépendant du matériel d'interface, le PNS peut utiliser n'importe quelle combinaison de matériel d'interface IP, y compris les dispositifs LAN et WAN.
Session
PPTP est orienté connexion. Le PNS et le PAC maintiennent l'état pour chaque utilisateur connecté à un PAC. Une session est créée lorsqu'une connexion PPP de bout en bout est tentée entre un utilisateur d'accès distant et le PNS. Les datagrammes liés à une session sont envoyés à travers le tunnel entre le PAC et le PNS.
Tunnel
Un tunnel est défini par une paire PNS-PAC. Le protocole de tunnel est défini par une version modifiée de GRE. Le tunnel transporte les datagrammes PPP entre le PAC et le PNS. Plusieurs sessions sont multiplexées sur un seul tunnel. Une connexion de contrôle fonctionnant sur TCP contrôle l'établissement, la libération et la maintenance des sessions et du tunnel lui-même.
1.3. Vue d'ensemble du protocole (Protocol Overview)
PPTP comporte deux composants parallèles : 1) une connexion de contrôle entre chaque paire PAC-PNS fonctionnant sur TCP et 2) un tunnel IP fonctionnant entre la même paire PAC-PNS, utilisé pour transporter des paquets PPP encapsulés GRE pour les sessions utilisateur entre la paire.
1.3.1. Vue d'ensemble de la connexion de contrôle (Control Connection Overview)
Avant que le tunnelage PPP puisse se produire entre un PAC et un PNS, une connexion de contrôle doit être établie entre eux. La connexion de contrôle est une session TCP standard sur laquelle les informations de contrôle et de gestion des appels PPTP sont transmises. La session de contrôle est logiquement associée, mais séparée, des sessions tunnelisées à travers un tunnel PPTP. Pour chaque paire PAC-PNS, un tunnel et une connexion de contrôle existent. La connexion de contrôle est responsable de l'établissement, de la gestion et de la libération des sessions transportées à travers le tunnel. C'est le moyen par lequel un PNS est informé d'un appel entrant sur un PAC associé, ainsi que le moyen par lequel un PAC reçoit l'instruction de passer un appel sortant.
Une connexion de contrôle peut être établie soit par le PNS soit par le PAC. Suite à l'établissement de la connexion TCP requise, le PNS et le PAC établissent la connexion de contrôle en utilisant les messages Start-Control-Connection-Request et -Reply. Ces messages sont également utilisés pour échanger des informations sur les capacités opérationnelles de base du PAC et du PNS. Une fois la connexion de contrôle établie, le PAC ou le PNS peut initier des sessions en demandant des appels sortants ou en répondant à des demandes entrantes. La connexion de contrôle peut communiquer des changements dans les caractéristiques opérationnelles d'une session utilisateur individuelle avec un message Set-Link-Info. Les sessions individuelles peuvent être libérées soit par le PAC soit par le PNS, également via les messages de connexion de contrôle.
La connexion de contrôle elle-même est maintenue par des messages d'écho keep-alive. Cela garantit qu'une défaillance de connectivité entre le PNS et le PAC peut être détectée en temps opportun. D'autres défaillances peuvent être signalées via le message Wan-Error-Notify, également sur la connexion de contrôle.
Il est prévu que la connexion de contrôle transportera également des messages liés à la gestion à l'avenir, tels qu'un message permettant au PNS de demander l'état d'un PAC donné ; ces types de messages n'ont pas encore été définis.
1.3.2. Vue d'ensemble du protocole de tunnel (Tunnel Protocol Overview)
PPTP nécessite l'établissement d'un tunnel pour chaque paire PNS-PAC communicante. Ce tunnel est utilisé pour transporter tous les paquets PPP de session utilisateur pour les sessions impliquant une paire PNS-PAC donnée. Une clé présente dans l'en-tête GRE indique à quelle session appartient un paquet PPP particulier.
De cette manière, les paquets PPP sont multiplexés et démultiplexés sur un seul tunnel entre une paire PNS-PAC donnée. La valeur à utiliser dans le champ de clé est établie par la procédure d'établissement d'appel qui a lieu sur la connexion de contrôle.
L'en-tête GRE contient également des informations d'accusé de réception et de séquençage qui sont utilisées pour effectuer un certain niveau de contrôle de congestion et de détection d'erreurs sur le tunnel. Encore une fois, la connexion de contrôle est utilisée pour déterminer les paramètres de débit et de mise en mémoire tampon utilisés pour réguler le flux de paquets PPP pour une session particulière sur le tunnel. PPTP ne spécifie pas les algorithmes particuliers à utiliser pour le contrôle de congestion et le contrôle de flux. Des algorithmes suggérés pour la détermination des délais d'expiration adaptatifs pour récupérer des données perdues ou des accusés de réception sur le tunnel sont inclus dans la section 4.4 de ce document.
1.4. Format de message et extensibilité du protocole (Message Format and Protocol Extensibility)
PPTP définit un ensemble de messages envoyés sous forme de données TCP sur la connexion de contrôle entre un PNS et un PAC donné. La session TCP pour la connexion de contrôle est établie en initiant une connexion TCP vers le port 1723. Le port source est attribué à n'importe quel numéro de port inutilisé.
Chaque message de connexion de contrôle PPTP commence par une portion d'en-tête fixe de 8 octets. Cet en-tête fixe contient les éléments suivants : la longueur totale du message, l'indicateur de type de message PPTP et un « Magic Cookie ».
Deux types de messages de connexion de contrôle sont indiqués par le champ Type de message PPTP :
- 1 - Message de contrôle (Control Message)
- 2 - Message de gestion (Management Message)
Les messages de gestion ne sont actuellement pas définis.
Le Magic Cookie est toujours envoyé comme la constante 0x1A2B3C4D. Son objectif principal est de permettre au récepteur de s'assurer qu'il est correctement synchronisé avec le flux de données TCP. Il ne doit pas (SHOULD NOT) être utilisé comme moyen de resynchroniser le flux de données TCP dans le cas où un émetteur émet un message mal formaté. La perte de synchronisation doit (MUST) entraîner la fermeture immédiate de la session TCP de la connexion de contrôle.
Pour plus de clarté, tous les modèles de messages de connexion de contrôle dans la section suivante incluent l'en-tête complet du message de connexion de contrôle PPTP. Les nombres précédés de 0x sont des valeurs hexadécimales.
Les messages de contrôle actuellement définis, regroupés par fonction, sont :
Gestion de la connexion de contrôle (Control Connection Management)
- Start-Control-Connection-Request (1)
- Start-Control-Connection-Reply (2)
- Stop-Control-Connection-Request (3)
- Stop-Control-Connection-Reply (4)
- Echo-Request (5)
- Echo-Reply (6)
Gestion des appels (Call Management)
- Outgoing-Call-Request (7)
- Outgoing-Call-Reply (8)
- Incoming-Call-Request (9)
- Incoming-Call-Reply (10)
- Incoming-Call-Connected (11)
- Call-Clear-Request (12)
- Call-Disconnect-Notify (13)
Rapport d'erreurs (Error Reporting)
- WAN-Error-Notify (14)
Contrôle de session PPP (PPP Session Control)
- Set-Link-Info (15)
Les messages Start-Control-Connection-Request et -Reply déterminent quelle version du protocole de connexion de contrôle sera utilisée. Le champ de numéro de version transporté dans ces messages se compose d'un numéro de version dans l'octet de poids fort et d'un numéro de révision dans l'octet de poids faible. La gestion des versions est décrite dans la section 2. La valeur actuelle du champ de numéro de version est 0x0100 pour la version 1, révision 0.
L'utilisation de l'en-tête de type GRE pour l'encapsulation des paquets utilisateur PPP est spécifiée dans la section 4.1.
Le MTU pour les paquets de données utilisateur encapsulés dans GRE est de 1532 octets, sans inclure les en-têtes IP et GRE.