RFC 2637 - Protocole de tunnelisation point à point (PPTP)
- Statut: Informational
- Publié: July 1999
- Stream: IETF
- Errata: Pas d'errata
Résumé (Abstract)
Ce document spécifie un protocole qui permet au protocole point à point (Point-to-Point Protocol, PPP) d'être tunnelisé à travers un réseau IP. PPTP ne spécifie aucune modification au protocole PPP mais décrit plutôt un nouveau moyen de transport pour PPP. Une architecture client-serveur est définie afin de découpler les fonctions qui existent dans les serveurs d'accès réseau (Network Access Server, NAS) actuels et de prendre en charge les réseaux privés virtuels (Virtual Private Network, VPN). Le serveur réseau PPTP (PNS) est conçu pour fonctionner sur un système d'exploitation à usage général, tandis que le client, appelé concentrateur d'accès PPTP (PAC), fonctionne sur une plateforme d'accès commuté. PPTP spécifie un protocole de contrôle d'appel et de gestion qui permet au serveur de contrôler l'accès pour les appels commutés entrants provenant d'un PSTN ou ISDN, ou d'initier des connexions commutées sortantes. PPTP utilise un mécanisme GRE (Generic Routing Encapsulation) amélioré pour fournir un service de datagramme encapsulé avec contrôle de flux et de congestion pour le transport des paquets PPP.
Table des matières (Contents)
- 1. Introduction
- 1.1 Protocol Goals and Assumptions (Objectifs et hypothèses du protocole)
- 1.2 Terminology (Terminologie)
- 1.3 Protocol Overview (Vue d'ensemble du protocole)
- 1.4 Message Format and Protocol Extensibility (Format de message et extensibilité du protocole)
- 2. Control Connection Protocol Specification (Spécification du protocole de connexion de contrôle)
- 2.1-2.16 Définitions des types de messages
- 3. Control Connection Protocol Operation (Opération du protocole de connexion de contrôle)
- 3.1 Control Connection States (États de connexion de contrôle)
- 3.2 Call States (États d'appel)
- 4. Tunnel Protocol Operation (Opération du protocole de tunnel)
- 4.1 Enhanced GRE Header (En-tête GRE amélioré)
- 4.2 Sliding Window Protocol (Protocole à fenêtre glissante)
- 4.3 Out-of-sequence Packets (Paquets hors séquence)
- 4.4 Acknowledgment Time-Outs (Délais d'expiration d'accusé de réception)
- 5. Security Considerations (Considérations de sécurité)
- 6. Authors' Addresses (Adresses des auteurs)
- 7. References (Références)
- 8. Full Copyright Statement (Déclaration complète de droits d'auteur)
Ressources connexes
- Texte original officiel : RFC 2637
- Page officielle : RFC 2637 DataTracker
- Errata : RFC Editor Errata
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.
2. Spécification du protocole de connexion de contrôle (Control Connection Protocol Specification)
Les messages de connexion de contrôle sont utilisés pour établir et effacer les sessions utilisateur. Le premier ensemble de messages de connexion de contrôle est utilisé pour maintenir la connexion de contrôle elle-même. La connexion de contrôle est initiée soit par le PNS soit par le PAC après qu'ils aient établi la connexion TCP sous-jacente. La procédure et les informations de configuration nécessaires pour déterminer quelles connexions TCP sont établies ne sont pas couvertes par ce protocole.
Les messages de connexion de contrôle suivants sont tous envoyés en tant que données utilisateur sur la connexion TCP établie entre une paire PNS-PAC donnée. Notez qu'un soin particulier a été pris pour s'assurer que toutes les valeurs de mot (2 octets) et de mot long (4 octets) commencent sur des limites appropriées. Toutes les données sont envoyées dans l'ordre réseau (octets de poids fort en premier). Tous les champs « réservés » doivent (MUST) être envoyés comme valeurs 0 pour permettre l'extensibilité du protocole.
2.1. Start-Control-Connection-Request (Demande de démarrage de connexion de contrôle)
Le Start-Control-Connection-Request est un message de contrôle PPTP utilisé pour établir la connexion de contrôle entre un PNS et un PAC. Chaque paire PNS-PAC nécessite qu'une connexion de contrôle dédiée soit établie. Une connexion de contrôle doit (MUST) être établie avant que tout autre message PPTP puisse être émis. L'établissement de la connexion de contrôle peut être initié soit par le PNS soit par le PAC. Une procédure qui gère l'occurrence d'une collision entre les Start-Control-Connection-Request du PNS et du PAC est décrite dans la section 3.1.3.
Format du message
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | 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) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Description des champs
Length (Longueur)
Longueur totale en octets de ce message PPTP, y compris l'en-tête PPTP entier.
PPTP Message Type (Type de message PPTP)
1 pour message de contrôle.
Magic Cookie
0x1A2B3C4D. Cette valeur constante est utilisée comme vérification de cohérence sur les messages reçus (voir section 1.4).
Control Message Type (Type de message de contrôle)
1 pour Start-Control-Connection-Request.
Reserved0 (Réservé 0)
Ce champ doit (MUST) être 0.
Protocol Version (Version du protocole)
La version du protocole PPTP que l'expéditeur souhaite utiliser.
Reserved1 (Réservé 1)
Ce champ doit (MUST) être 0.
Framing Capabilities (Capacités de tramage)
Un ensemble de bits indiquant le type de tramage que l'expéditeur de ce message peut fournir. Les paramètres de bits actuellement définis sont :
- 1 - Tramage asynchrone pris en charge (Asynchronous Framing supported)
- 2 - Tramage synchrone pris en charge (Synchronous Framing supported)
Bearer Capabilities (Capacités de support)
Un ensemble de bits indiquant les capacités de support que l'expéditeur de ce message peut fournir. Les paramètres de bits actuellement définis sont :
- 1 - Accès analogique pris en charge (Analog access supported)
- 2 - Accès numérique pris en charge (Digital access supported)
Maximum Channels (Canaux maximum)
Le nombre total de sessions PPP individuelles que ce PAC peut prendre en charge. Dans les Start-Control-Connection-Request émises par le PNS, cette valeur devrait (SHOULD) être définie à 0. Elle doit (MUST) être ignorée par le PAC.
Firmware Revision (Révision du micrologiciel)
Lorsqu'il est émis par le PAC, ce champ contient le numéro de révision du micrologiciel du PAC émetteur. Lorsqu'il est émis par le PNS, il contient la version du pilote PPTP du PNS.
Host Name (Nom d'hôte)
Un champ de 64 octets contenant le nom DNS du PAC ou PNS émetteur. Si la longueur est inférieure à 64 octets, le reste de ce champ devrait (SHOULD) être rempli avec des octets de valeur 0.
Vendor Name (Nom du fournisseur)
Un champ de 64 octets contenant une chaîne spécifique au fournisseur décrivant le type de PAC utilisé, ou le type de logiciel PNS utilisé si cette demande est émise par le PNS. Si la longueur est inférieure à 64 octets, le reste de ce champ devrait (SHOULD) être rempli avec des octets de valeur 0.
2.2. Start-Control-Connection-Reply (Réponse de démarrage de connexion de contrôle)
Le Start-Control-Connection-Reply est un message de contrôle PPTP envoyé en réponse à un message Start-Control-Connection-Request reçu. Ce message contient un code de résultat indiquant le résultat de la tentative d'établissement de la connexion de contrôle.
Format du message
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | PPTP Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Message Type | Reserved0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol Version | Result Code | Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Framing Capability |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bearer Capability |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Channels | Firmware Revision |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Host Name (64 octets) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Vendor String (64 octets) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Description des champs
Length (Longueur)
Longueur totale en octets de ce message PPTP, y compris l'en-tête PPTP entier.
PPTP Message Type (Type de message PPTP)
1 pour message de contrôle.
Magic Cookie
0x1A2B3C4D.
Control Message Type (Type de message de contrôle)
2 pour Start-Control-Connection-Reply.
Reserved0 (Réservé 0)
Ce champ doit (MUST) être 0.
Protocol Version (Version du protocole)
La version du protocole PPTP que l'expéditeur souhaite utiliser.
Result Code (Code de résultat)
Indique le résultat de la tentative d'établissement du canal de commande. Les valeurs de code de résultat actuellement valides sont :
- 1 - Établissement de canal réussi
- 2 - Erreur générale -- Le code d'erreur indique le problème
- 3 - Le canal de commande existe déjà
- 4 - Le demandeur n'est pas autorisé à établir un canal de commande
- 5 - La version du protocole du demandeur n'est pas prise en charge
Error Code (Code d'erreur)
Ce champ est défini à 0 sauf si une « Erreur générale » existe, auquel cas le code de résultat est défini à 2 et ce champ est défini à la valeur correspondant à la condition d'erreur générale telle que spécifiée dans la section 2.2.
Framing Capabilities (Capacités de tramage)
Un ensemble de bits indiquant le type de tramage que l'expéditeur de ce message peut fournir. Les paramètres de bits actuellement définis sont :
- 1 - Tramage asynchrone pris en charge
- 2 - Tramage synchrone pris en charge
Bearer Capabilities (Capacités de support)
Un ensemble de bits indiquant les capacités de support que l'expéditeur de ce message peut fournir. Les paramètres de bits actuellement définis sont :
- 1 - Accès analogique pris en charge
- 2 - Accès numérique pris en charge
Maximum Channels (Canaux maximum)
Le nombre total de sessions PPP individuelles que ce PAC peut prendre en charge. Dans les Start-Control-Connection-Reply émises par le PNS, cette valeur devrait (SHOULD) être définie à 0 et doit (MUST) être ignorée par le PAC. Le PNS ne doit pas (MUST NOT) utiliser cette valeur pour essayer de suivre le nombre restant de sessions PPP que le PAC autorisera.
Firmware Revision (Révision du micrologiciel)
Ce champ contient le numéro de révision du micrologiciel du PAC émetteur, ou la version du pilote PPTP du PNS s'il est émis par le PNS.
Host Name (Nom d'hôte)
Un champ de 64 octets contenant le nom DNS du PAC ou PNS émetteur.
Vendor String (Chaîne du fournisseur)
Un champ de 64 octets contenant une chaîne spécifique au fournisseur.
2.3. Stop-Control-Connection-Request (Demande d'arrêt de connexion de contrôle)
Le Stop-Control-Connection-Request est un message de contrôle PPTP envoyé par l'un des pairs d'une connexion de contrôle PAC-PNS pour informer l'autre pair que la connexion de contrôle doit être fermée. En plus de fermer la connexion de contrôle, tous les appels utilisateur actifs sont implicitement effacés. La raison de l'émission de cette demande est indiquée dans le champ Reason.
Format du message
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | PPTP Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Message Type | Reserved0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason | Reserved1 | Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Description des champs
Length (Longueur)
Longueur totale en octets de ce message PPTP, y compris l'en-tête PPTP entier.
PPTP Message Type (Type de message PPTP)
1 pour message de contrôle.
Magic Cookie
0x1A2B3C4D.
Control Message Type (Type de message de contrôle)
3 pour Stop-Control-Connection-Request.
Reserved0 (Réservé 0)
Ce champ doit (MUST) être 0.
Reason (Raison)
Indique la raison de la fermeture de la connexion de contrôle. Les valeurs de raison actuellement valides sont :
- 1 (None) - Demande générale de fermeture de la connexion de contrôle
- 2 (Stop-Protocol) - Impossible de prendre en charge la version du protocole du pair
- 3 (Stop-Local-Shutdown) - Le demandeur est en cours d'arrêt
Reserved1, Reserved2 (Réservé 1, 2)
Ces champs doivent (MUST) être 0.
2.4. Stop-Control-Connection-Reply (Réponse d'arrêt de connexion de contrôle)
Le Stop-Control-Connection-Reply est un message de contrôle PPTP envoyé par l'un des pairs d'une connexion de contrôle PAC-PNS lors de la réception d'un Stop-Control-Connection-Request de l'autre pair.
Format du message
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | PPTP Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Message Type | Reserved0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result Code | Error Code | Reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Description des champs
Length (Longueur)
Longueur totale en octets de ce message PPTP, y compris l'en-tête PPTP entier.
PPTP Message Type (Type de message PPTP)
1 pour message de contrôle.
Magic Cookie
0x1A2B3C4D.
Control Message Type (Type de message de contrôle)
4 pour Stop-Control-Connection-Reply.
Reserved0 (Réservé 0)
Ce champ doit (MUST) être 0.
Result Code (Code de résultat)
Indique le résultat de la tentative de fermeture de la connexion de contrôle. Les valeurs de code de résultat actuellement valides sont :
- 1 (OK) - Connexion de contrôle fermée
- 2 (General Error) - Connexion de contrôle non fermée pour la raison indiquée dans le code d'erreur
Error Code (Code d'erreur)
Ce champ est défini à 0 sauf si une « Erreur générale » existe, auquel cas le code de résultat est défini à 2 et ce champ est défini à la valeur correspondant à la condition d'erreur générale telle que spécifiée dans la section 2.2.
Reserved1 (Réservé 1)
Ce champ doit (MUST) être 0.
2.5. Echo-Request (Demande d'écho)
L'Echo-Request est un message de contrôle PPTP envoyé par l'un ou l'autre des pairs d'une connexion de contrôle PAC-PNS. Ce message de contrôle est utilisé comme « maintien en vie » pour la connexion de contrôle. Le pair récepteur émet un Echo-Reply pour chaque Echo-Request reçu. Comme spécifié dans la section 3.1.4, si l'expéditeur ne reçoit pas d'Echo-Reply en réponse à un Echo-Request, il finira par effacer la connexion de contrôle.
Format du message
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | PPTP Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Message Type | Reserved0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Description des champs
Length (Longueur)
Longueur totale en octets de ce message PPTP, y compris l'en-tête PPTP entier.
PPTP Message Type (Type de message PPTP)
1 pour message de contrôle.
Magic Cookie
0x1A2B3C4D.
Control Message Type (Type de message de contrôle)
5 pour Echo-Request.
Reserved0 (Réservé 0)
Ce champ doit (MUST) être 0.
Identifier (Identifiant)
Valeur de 32 bits renvoyée en écho dans l'Echo-Reply correspondant.
2.6. Echo-Reply (Réponse d'écho)
L'Echo-Reply est un message de contrôle PPTP envoyé par l'un ou l'autre des pairs d'une connexion de contrôle PAC-PNS en réponse à la réception d'un Echo-Request.
Format du message
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | PPTP Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Message Type | Reserved0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result Code | Error Code | Reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Description des champs
Length (Longueur)
Longueur totale en octets de ce message PPTP, y compris l'en-tête PPTP entier.
PPTP Message Type (Type de message PPTP)
1 pour message de contrôle.
Magic Cookie
0x1A2B3C4D.
Control Message Type (Type de message de contrôle)
6 pour Echo-Reply.
Reserved0 (Réservé 0)
Ce champ doit (MUST) être 0.
Identifier (Identifiant)
Le contenu du champ d'identification de l'Echo-Request reçu est copié dans ce champ.
Result Code (Code de résultat)
Indique le résultat de la réception de l'Echo-Request. Les valeurs de code de résultat actuellement valides sont :
- 1 (OK) - L'Echo-Reply est valide
- 2 (General Error) - Echo-Request non accepté pour la raison indiquée dans le code d'erreur
Error Code (Code d'erreur)
Ce champ est défini à 0 sauf si une condition « Erreur générale » existe, auquel cas le code de résultat est défini à 2 et ce champ est défini à la valeur correspondant à la condition d'erreur générale telle que spécifiée dans la section 2.2.
Reserved1 (Réservé 1)
Ce champ doit (MUST) être 0.
2.7. Outgoing-Call-Request (Demande d'appel sortant)
L'Outgoing-Call-Request est un message de contrôle PPTP envoyé par le PNS au PAC pour indiquer qu'un appel sortant depuis le PAC doit être établi. Cette demande fournit au PAC les informations requises pour effectuer l'appel. Elle fournit également au PAC des informations utilisées pour réguler la transmission de données vers le PNS pour cette session une fois qu'elle est établie.
Format du message
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | 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) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Description des champs
Length (Longueur)
Longueur totale en octets de ce message PPTP, y compris l'en-tête PPTP entier.
PPTP Message Type (Type de message PPTP)
1 pour message de contrôle.
Magic Cookie
0x1A2B3C4D.
Control Message Type (Type de message de contrôle)
7 pour Outgoing-Call-Request.
Reserved0 (Réservé 0)
Ce champ doit (MUST) être 0.
Call ID (ID d'appel)
Un identifiant unique, propre à une paire PAC-PNS particulière, attribué par le PNS à cette session. Il est utilisé pour multiplexer et démultiplexer les données envoyées sur le tunnel entre le PNS et le PAC impliqués dans cette session.
Call Serial Number (Numéro de série d'appel)
Un identifiant attribué par le PNS à cette session dans le but d'identifier cette session particulière dans les informations de session enregistrées. Contrairement à l'ID d'appel, le PNS et le PAC associent tous deux le même numéro de série d'appel à une session donnée. La combinaison de l'adresse IP et du numéro de série d'appel devrait (SHOULD) être unique.
Minimum BPS (BPS minimum)
La vitesse de ligne la plus basse acceptable (en bits/seconde) pour cette session.
Maximum BPS (BPS maximum)
La vitesse de ligne la plus élevée acceptable (en bits/seconde) pour cette session.
Bearer Type (Type de support)
Une valeur indiquant la capacité de support requise pour cet appel sortant. Les valeurs actuellement définies sont :
- 1 - Appel à placer sur un canal analogique
- 2 - Appel à placer sur un canal numérique
- 3 - L'appel peut être placé sur n'importe quel type de canal
Framing Type (Type de tramage)
Une valeur indiquant le type de tramage PPP à utiliser pour cet appel sortant.
- 1 - Appel utilisant un tramage asynchrone
- 2 - Appel utilisant un tramage synchrone
- 3 - L'appel peut utiliser l'un ou l'autre type de tramage
Packet Recv. Window Size (Taille de fenêtre de réception de paquets)
Le nombre de paquets de données reçus que le PNS mettra en mémoire tampon pour cette session.
Packet Processing Delay (Délai de traitement des paquets)
Une mesure du délai de traitement des paquets qui pourrait être imposé aux données envoyées au PNS depuis le PAC. Cette valeur est spécifiée en unités de 1/10 secondes. Pour le PNS, ce nombre devrait être très petit.
Phone Number Length (Longueur du numéro de téléphone)
Le nombre réel de chiffres valides dans le champ Phone Number.
Reserved1 (Réservé 1)
Ce champ doit (MUST) être 0.
Phone Number (Numéro de téléphone)
Le numéro à composer pour établir la session sortante. Si la longueur est inférieure à 64 octets, le reste de ce champ est rempli avec des octets de valeur 0.
Subaddress (Sous-adresse)
Un champ de 64 octets utilisé pour spécifier une chaîne de numérotation supplémentaire d'informations de numérotation. Si la longueur est inférieure à 64 octets, le reste de ce champ est rempli avec des octets de valeur 0.
2.8. Outgoing-Call-Reply (Réponse d'appel sortant)
L'Outgoing-Call-Reply est un message de contrôle PPTP envoyé par le PAC au PNS en réponse à un message Outgoing-Call-Request reçu. La réponse indique le résultat de la tentative d'appel sortant. Elle fournit également au PNS des informations sur les paramètres particuliers utilisés pour l'appel et permet au PNS de réguler la transmission de données vers le PAC pour cette session.
Format du message
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Description des champs
Length (Longueur)
Longueur totale en octets de ce message PPTP, y compris l'en-tête PPTP entier.
PPTP Message Type (Type de message PPTP)
1 pour message de contrôle.
Magic Cookie
0x1A2B3C4D.
Control Message Type (Type de message de contrôle)
8 pour Outgoing-Call-Reply.
Reserved0 (Réservé 0)
Ce champ doit (MUST) être 0.
Call ID (ID d'appel)
Identifiant unique du pair (PAC) pour cette session. Cette valeur est utilisée comme clé de multiplexage dans tous les messages de contrôle d'appel ultérieurs reçus par le pair.
Peer's Call ID (ID d'appel du pair)
Cette valeur est copiée depuis le champ Call ID de l'Outgoing-Call-Request correspondant et est utilisée pour associer cette réponse à l'Outgoing-Call-Request envoyé.
Result Code (Code de résultat)
Indique le résultat de la tentative d'appel sortant. Les valeurs de code de résultat actuellement valides incluent :
- 1 (Connected) - L'appel est connecté
- 2 (General Error) - L'appel sortant n'a pas abouti en raison d'une erreur indiquée dans le code d'erreur
- 3 (No Carrier) - L'appel sortant a échoué car aucune porteuse n'a été détectée
- 4 (Busy) - L'appel sortant a échoué en raison d'un signal occupé
- 5 (No Dial Tone) - L'appel sortant a échoué car aucune tonalité n'a été détectée
- 6 (Time-out) - L'appel sortant n'a pas abouti dans le temps imparti
- 7 (Do Not Accept) - L'appel sortant n'est pas accepté administrativement localement
Error Code (Code d'erreur)
Ce champ est défini à 0 sauf si une condition d'erreur générale existe (comme indiqué par le code de résultat 2).
Cause Code (Code de cause)
Ce champ fournit des informations supplémentaires sur la défaillance concernant la déconnexion de l'appel. La valeur est généralement fournie par les installations du réseau téléphonique.
Connect Speed (Vitesse de connexion)
Indique la vitesse réelle (en bits/seconde) à laquelle l'appel a été connecté.
Packet Recv. Window Size (Taille de fenêtre de réception de paquets)
Le nombre de paquets de données reçus que le PAC mettra en mémoire tampon pour cette session.
Packet Processing Delay (Délai de traitement des paquets)
Une mesure du délai de traitement des paquets qui pourrait être imposé aux données envoyées du PNS au PAC. Cette valeur est spécifiée en unités de 1/10 secondes.
Physical Channel ID (ID de canal physique)
Ce champ est défini par le PAC comme identifiant unique du canal physique utilisé pour cet appel. Sa valeur est utilisée à des fins de journalisation et de débogage.
2.9. Incoming-Call-Request (Demande d'appel entrant)
L'Incoming-Call-Request est un message de contrôle PPTP envoyé par le PAC au PNS pour indiquer qu'un appel entrant a été reçu du PSTN et a été accepté localement. Cette demande fournit au PNS des informations sur le type d'appel entrant. Elle fournit également des informations utilisées pour réguler la transmission de données du PAC vers le PNS pour cette session.
Format du message
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | PPTP Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Message Type | Reserved0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Call ID | Call Serial Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bearer Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Physical Channel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Dialed Number Length | Dialing Number Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Dialed Number (64 octets) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Dialing Number (64 octets) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Subaddress (64 octets) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Description des champs
Length (Longueur)
Longueur totale en octets de ce message PPTP, y compris l'en-tête PPTP entier.
PPTP Message Type (Type de message PPTP)
1 pour message de contrôle.
Magic Cookie
0x1A2B3C4D.
Control Message Type (Type de message de contrôle)
9 pour Incoming-Call-Request.
Reserved0 (Réservé 0)
Ce champ doit (MUST) être 0.
Call ID (ID d'appel)
Identifiant unique attribué par le PAC à cette session. Cette valeur est utilisée comme clé de multiplexage dans tous les messages de contrôle d'appel ultérieurs.
Call Serial Number (Numéro de série d'appel)
Identifiant attribué par le PAC à cette session pour identifier cette session particulière dans les informations de session enregistrées.
Bearer Type (Type de support)
Valeur indiquant la capacité de support de l'appel entrant :
- 1 - Appel sur canal analogique
- 2 - Appel sur canal numérique
Physical Channel ID (ID de canal physique)
Identifiant unique du canal physique utilisé par le PAC pour cet appel.
Dialed Number Length (Longueur du numéro composé)
Nombre réel de chiffres valides dans le champ Dialed Number.
Dialing Number Length (Longueur du numéro appelant)
Nombre réel de chiffres valides dans le champ Dialing Number.
Dialed Number (Numéro composé)
Le numéro appelé. Champ de 64 octets, complété par des zéros si nécessaire.
Dialing Number (Numéro appelant)
Le numéro de l'appelant. Champ de 64 octets, complété par des zéros si nécessaire.
Subaddress (Sous-adresse)
Informations de numérotation supplémentaires. Champ de 64 octets, complété par des zéros si nécessaire.
2.10. Incoming-Call-Reply (Réponse d'appel entrant)
L'Incoming-Call-Reply est un message de contrôle PPTP envoyé par le PNS au PAC en réponse à un Incoming-Call-Request reçu. La réponse indique si le PNS accepte l'appel entrant. Elle fournit également des informations utilisées pour réguler la transmission de données du PNS vers le PAC pour cette session.
Format du message
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | PPTP Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Message Type | Reserved0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Call ID | Peer's Call ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result Code | Error Code | Packet Recv. Window Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Processing Delay | Reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Description des champs
Control Message Type (Type de message de contrôle)
10 pour Incoming-Call-Reply.
Result Code (Code de résultat)
Indique si le PNS accepte l'appel entrant :
- 1 (Connect) - Accepte l'appel entrant
- 2 (General Error) - L'appel entrant n'est pas accepté en raison d'une erreur
- 3 (Do Not Accept) - L'appel entrant n'est pas accepté administrativement
2.11. Incoming-Call-Connected (Appel entrant connecté)
L'Incoming-Call-Connected est un message de contrôle PPTP envoyé par le PAC au PNS servant de confirmation finale pour un appel entrant. Il fournit des informations sur les paramètres de la session établie.
Format du message
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | PPTP Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Message Type | Reserved0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer's Call ID | Reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Connect Speed |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Recv. Window Size | Packet Processing Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Framing Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Description des champs
Control Message Type (Type de message de contrôle)
11 pour Incoming-Call-Connected.
Framing Type (Type de tramage)
Type de tramage utilisé pour l'appel entrant :
- 1 - Tramage asynchrone
- 2 - Tramage synchrone
2.12. Call-Clear-Request (Demande d'effacement d'appel)
Le Call-Clear-Request est un message de contrôle PPTP envoyé par le PNS au PAC pour indiquer qu'un appel spécifique doit être déconnecté.
Format du message
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | PPTP Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Message Type | Reserved0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Call ID | Reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Control Message Type (Type de message de contrôle)
12 pour Call-Clear-Request.
2.13. Call-Disconnect-Notify (Notification de déconnexion d'appel)
Le Call-Disconnect-Notify est un message de contrôle PPTP envoyé par le PAC au PNS pour indiquer qu'un appel a été déconnecté.
Format du message
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | PPTP Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Message Type | Reserved0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Call ID | Result Code | Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code | Reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Call Statistics (128 octets) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Control Message Type (Type de message de contrôle)
13 pour Call-Disconnect-Notify.
2.14. WAN-Error-Notify (Notification d'erreur WAN)
Le WAN-Error-Notify est un message de contrôle PPTP envoyé par le PAC au PNS pour indiquer qu'une condition d'erreur WAN s'est produite.
Format du message
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Control Message Type (Type de message de contrôle)
14 pour WAN-Error-Notify.
2.15. Set-Link-Info (Définir les informations de lien)
Le Set-Link-Info est un message de contrôle PPTP envoyé par le PNS au PAC pour définir les paramètres de négociation PPP.
Format du message
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | PPTP Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Message Type | Reserved0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer's Call ID | Reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Send ACCM |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receive ACCM |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Control Message Type (Type de message de contrôle)
15 pour Set-Link-Info.
2.16. General Error Codes (Codes d'erreur généraux)
Voici les valeurs de code d'erreur général utilisées dans le champ Error Code de divers messages de contrôle PPTP :
- 0 - None (Aucune erreur)
- 1 - Not-Connected (Non connecté) - Aucune connexion de contrôle n'existe entre PAC et PNS
- 2 - Bad-Format (Mauvais format) - Longueur de message incorrecte ou format de message incorrect
- 3 - Bad-Value (Mauvaise valeur) - La valeur dans un champ de message est hors plage ou invalide
- 4 - No-Resource (Aucune ressource) - Ressources insuffisantes pour traiter cette commande
- 5 - Bad-Call ID (ID d'appel incorrect) - Cet homologue ne connaît pas l'ID d'appel référencé
- 6 - PAC-Error (Erreur PAC) - Erreur générale rencontrée par le PAC
Instructions d'utilisation des codes d'erreur
Lorsque le champ Result Code d'un message de contrôle est défini pour indiquer une erreur générale (généralement la valeur 2), le champ Error Code doit être utilisé pour fournir plus de détails sur la nature de cette erreur. Si le Result Code n'indique pas d'erreur générale, le champ Error Code doit (MUST) être défini à 0.
Ces codes d'erreur sont destinés à fournir des informations de diagnostic utiles à des fins de débogage et de journalisation, aidant à identifier et résoudre les problèmes lors de l'établissement et de la maintenance des sessions PPTP.
Section 2 terminée - Cette section a défini en détail tous les types de messages utilisés dans le protocole de connexion de contrôle PPTP, y compris les messages de gestion de connexion de contrôle (2.1-2.6), les messages de contrôle d'appel (2.7-2.15) et les codes d'erreur généraux (2.16).
3. Fonctionnement du protocole (Protocol Operation)
Cette section décrit les détails opérationnels du protocole PPTP, y compris les états de connexion de contrôle, les états d'appel et les flux de traitement pour divers scénarios opérationnels.
3.1. États de connexion de contrôle (Control Connection States)
La connexion de contrôle est une connexion TCP établie entre le PAC et le PNS pour échanger des messages de contrôle PPTP. L'établissement de la connexion de contrôle peut être initié par le PAC ou le PNS.
Transitions d'état de base
La connexion de contrôle passe par les états de base suivants :
- Idle (Inactif) - Aucune connexion de contrôle n'existe
- Wait-Connect (Attente de connexion) - Demande de connexion envoyée, en attente de réponse
- Established (Établi) - Connexion de contrôle établie avec succès
- Wait-Disconnect (Attente de déconnexion) - Demande de déconnexion envoyée, en attente de confirmation
3.1.1. Initiateur de connexion de contrôle (Control Connection Originator)
L'initiateur de la connexion de contrôle (PAC ou PNS) effectue les opérations suivantes :
État : Idle (Inactif)
- Action : Établir une connexion TCP vers le pair
- Envoyer : Start-Control-Connection-Request
- Transition vers : État Wait-Reply
État : Wait-Reply (Attente de réponse)
- Recevoir : Start-Control-Connection-Reply (Result = succès)
- Transition vers : État Established
- Recevoir : Start-Control-Connection-Reply (Result = erreur)
- Fermer la connexion TCP
- Transition vers : État Idle
- Timeout :
- Fermer la connexion TCP
- Transition vers : État Idle
État : Established (Établi)
- Peut envoyer et recevoir : tous les messages de contrôle PPTP
- Envoyer : Echo-Request (maintien en vie périodique)
- Recevoir : Echo-Reply (réponse au maintien en vie)
- Envoyer : Stop-Control-Connection-Request (fermeture active)
- Transition vers : État Wait-Stop-Reply
État : Wait-Stop-Reply (Attente de réponse d'arrêt)
- Recevoir : Stop-Control-Connection-Reply
- Fermer la connexion TCP
- Transition vers : État Idle
- Timeout :
- Fermer la connexion TCP
- Transition vers : État Idle
3.1.2. Récepteur de connexion de contrôle (Control Connection Receiver)
Le récepteur de la connexion de contrôle (PAC ou PNS) effectue les opérations suivantes :
État : Idle (Inactif)
- Écouter : Port TCP 1723
- Recevoir : Demande de connexion TCP
- Accepter la connexion TCP
- Transition vers : État Wait-Request
État : Wait-Request (Attente de demande)
- Recevoir : Start-Control-Connection-Request
- Valider : Version du protocole, paramètres
- Si accepté :
- Envoyer : Start-Control-Connection-Reply (Result = succès)
- Transition vers : État Established
- Si rejeté :
- Envoyer : Start-Control-Connection-Reply (Result = erreur)
- Fermer la connexion TCP
- Transition vers : État Idle
État : Established (Établi)
- Peut envoyer et recevoir : tous les messages de contrôle PPTP
- Recevoir : Echo-Request
- Envoyer : Echo-Reply
- Recevoir : Stop-Control-Connection-Request
- Envoyer : Stop-Control-Connection-Reply
- Fermer la connexion TCP
- Transition vers : État Idle
3.1.3. Collision de demande d'initiation Start Control Connection (Initiation Request Collision)
Lorsque le PAC et le PNS tentent simultanément d'établir une connexion de contrôle, une collision peut se produire. La gestion est la suivante :
- Détection de collision : Quand une partie reçoit un Start-Control-Connection-Request en état Wait-Reply
- Résolution de collision :
- Comparer les adresses IP (valeur numérique)
- Partie avec l'adresse IP inférieure : fermer sa connexion initiée, accepter celle du pair
- Partie avec l'adresse IP supérieure : continuer sa connexion initiée, rejeter celle du pair
- Résultat final : Une seule connexion de contrôle est établie
3.1.4. Maintien en vie et temporisateurs (Keep Alives and Timers)
Pour maintenir l'état actif de la connexion de contrôle, les mécanismes suivants sont implémentés :
Mécanisme Echo-Request/Reply
- Fréquence d'envoi : Recommandé d'envoyer un Echo-Request toutes les 60 secondes
- Gestion du timeout : Si aucun Echo-Reply n'est reçu dans les 60 secondes, la connexion est considérée comme défaillante
- Stratégie de réessai : Peut réessayer jusqu'à 3 fois, avec un intervalle de 60 secondes entre chaque essai
- Échec de connexion : Après plusieurs timeouts consécutifs, fermer la connexion de contrôle
Maintien en vie TCP
- Le mécanisme de maintien en vie de la couche TCP peut être utilisé en complément
- Le mécanisme Echo de la couche PPTP est requis (MUST)
Paramètres de temporisation
- Timeout d'établissement de connexion de contrôle : 60 secondes
- Intervalle de maintien en vie : 60 secondes
- Timeout d'Echo-Reply : 60 secondes
- Timeout de fermeture de connexion de contrôle : 60 secondes
Ces valeurs de temporisation sont des recommandations. Les implémentations peuvent les ajuster selon les besoins, mais doivent s'assurer que :
- L'intervalle de maintien en vie est suffisamment court pour détecter rapidement les échecs de connexion
- Les valeurs de timeout sont suffisamment longues pour éviter les faux positifs dus à la latence réseau
3.2. États d'appel (Call States)
3.2.1. Considérations de temporisation (Timing Considerations)
En raison de la nature temps réel de la signalisation téléphonique, le PNS et le PAC doivent tous deux être implémentés avec des architectures multi-thread de sorte que les messages relatifs à plusieurs appels ne soient pas sérialisés et bloqués. Le délai de transit entre le PAC et le PNS ne doit pas dépasser 1 seconde (SHOULD NOT). Les diagrammes d'état d'appel et de connexion ne spécifient pas explicitement les exceptions causées par les temporisateurs. L'hypothèse implicite est que puisque la connexion de contrôle basée sur TCP est vérifiée avec des messages de maintien en vie, il y a moins besoin de maintenir des temporisateurs stricts pour les messages de contrôle d'appel.
L'établissement d'appels sortants internationaux, y compris les séquences d'entraînement et de négociation de modem, peut prendre plus d'1 minute, donc l'utilisation de temporisateurs courts est déconseillée.
Si une transition d'état ne se produit pas dans 1 minute (sauf pour les connexions en état inactif ou établi), l'intégrité du traitement du protocole entre les pairs est suspecte et l'ENSEMBLE DE LA CONNEXION DE CONTRÔLE (ENTIRE CONTROL CONNECTION) doit être fermée et redémarrée. Tous les ID d'appel sont logiquement libérés chaque fois qu'une connexion de contrôle est démarrée. Cela aide également à empêcher que les appels payants soient "perdus" et jamais effacés.
3.2.2. Valeurs d'ID d'appel (Call ID Values)
Chaque pair attribue une valeur d'ID d'appel à chaque session utilisateur qu'il demande ou accepte. Cette valeur d'ID d'appel doit (MUST) être unique pour le tunnel entre le PNS et le PAC auquel elle appartient. Les tunnels vers d'autres pairs peuvent utiliser le même numéro d'ID d'appel, donc le récepteur d'un paquet sur un tunnel doit associer une session utilisateur à un tunnel particulier et un ID d'appel. Il est suggéré que le nombre de valeurs d'ID d'appel potentielles pour chaque tunnel soit au moins deux fois plus grand que le nombre maximum d'appels attendus sur un tunnel donné.
Une session est définie par le triplet (PAC, PNS, Call ID).
3.2.3. Appels entrants (Incoming Calls)
Un message Incoming-Call-Request est généré par le PAC lorsqu'une ligne téléphonique associée sonne. Le PAC sélectionne un ID d'appel et un numéro de série et indique le type de support d'appel. Les modems doivent toujours indiquer le type d'appel analogique (SHOULD). Les appels ISDN doivent indiquer numérique lorsque le service numérique sans restriction ou l'adaptation de débit est utilisé et analogique si des modems numériques sont impliqués (SHOULD). Le numéro appelant, le numéro appelé et la sous-adresse peuvent être inclus dans le message s'ils sont disponibles depuis le réseau téléphonique.
Une fois que le PAC envoie l'Incoming-Call-Request, il attend une réponse du PNS mais ne répond pas à l'appel du réseau téléphonique. Le PNS peut choisir de ne pas accepter l'appel si :
- Aucune ressource n'est disponible pour gérer plus de sessions
- Les champs de numéro appelé, appelant ou sous-adresse n'indiquent pas un utilisateur autorisé
- Le service de support n'est pas autorisé ou n'est pas pris en charge
Si le PNS choisit d'accepter l'appel, il répond avec un Incoming-Call-Reply qui indique également les tailles de fenêtre (voir section 4.2). Lorsque le PAC reçoit l'Outgoing-Call-Reply, il tente de connecter l'appel, en supposant que la partie appelante n'a pas raccroché. Un message final de connexion d'appel du PAC au PNS indique que les états d'appel pour le PAC et le PNS doivent entrer dans l'état établi.
Lorsque le client entrant raccroche, l'appel est effacé normalement et le PAC envoie un message Call-Disconnect-Notify. Si le PNS souhaite effacer un appel, il envoie un message Call-Clear-Request puis attend un Call-Disconnect-Notify.
3.2.3.1. États d'appel entrant PAC (PAC Incoming Call States)
Les états associés au PAC pour les appels entrants sont :
idle (inactif)
- Le PAC détecte un appel entrant sur l'une de ses interfaces téléphoniques. Typiquement, cela signifie qu'une ligne analogique sonne ou qu'un TE ISDN a détecté un message SETUP Q.931 entrant. Le PAC envoie un message Incoming-Call-Request et passe à l'état wait_reply.
wait_reply (attente de réponse)
- Le PAC reçoit un message Incoming-Call-Reply indiquant une non-volonté d'accepter l'appel (erreur générale ou refus) et retourne à l'état inactif. Si le message de réponse indique que l'appel est accepté, le PAC envoie un message Incoming-Call-Connected et entre dans l'état établi.
established (établi)
- Les données sont échangées sur le tunnel. L'appel peut être effacé suite à :
- Un événement sur la connexion téléphonique. Le PAC envoie un message Call-Disconnect-Notify
- Réception d'un Call-Clear-Request. Le PAC envoie un message Call-Disconnect-Notify
- Une raison locale. Le PAC envoie un message Call-Disconnect-Notify
3.2.3.2. États d'appel entrant PNS (PNS Incoming Call States)
Les états associés au PNS pour les appels entrants sont :
idle (inactif)
- Un message Incoming-Call-Request est reçu. Si la demande n'est pas acceptable, un Incoming-Call-Reply est renvoyé au PAC et le PNS reste dans l'état inactif. Si le message Incoming-Call-Request est acceptable, un Incoming-Call-Reply est envoyé indiquant accepter dans le code de résultat. La session passe à l'état wait_connect.
wait_connect (attente de connexion)
- Si la session est connectée sur le PAC, le PAC envoie un message de connexion d'appel entrant au PNS qui passe alors à l'état établi. Le PAC peut envoyer un Call-Disconnect-Notify pour indiquer que l'appelant entrant n'a pas pu être connecté. Cela pourrait se produire, par exemple, si un utilisateur téléphonique passe accidentellement un appel vocal standard à un PAC, entraînant une défaillance de négociation sur le modem appelé.
established (établi)
- La session est terminée soit par réception d'un message Call-Disconnect-Notify du PAC, soit par envoi d'un Call-Clear-Request. Une fois qu'un Call-Clear-Request a été envoyé, la session entre dans l'état wait_disconnect.
wait_disconnect (attente de déconnexion)
- Une fois qu'un Call-Disconnect-Notify est reçu, la session retourne à l'état inactif.
3.2.4. Appels sortants (Outgoing Calls)
Les messages sortants sont initiés par un PNS et ordonnent à un PAC de passer un appel sur une interface téléphonique. Il n'y a que deux messages pour les appels sortants : Outgoing-Call-Request et Outgoing-Call-Reply. Le PNS envoie un Outgoing-Call-Request spécifiant le numéro de téléphone de la partie appelée et la sous-adresse ainsi que les paramètres de vitesse et de fenêtre. Le PAC doit (MUST) répondre au message Outgoing-Call-Request avec un message Outgoing-Call-Reply une fois que le PAC détermine que :
- L'appel a été connecté avec succès
- Une défaillance d'appel s'est produite pour des raisons telles que : aucune interface n'est disponible pour composer, la partie appelée est occupée ou ne répond pas, ou aucune tonalité de composition n'est détectée sur l'interface choisie pour composer
3.2.4.1. États d'appel sortant PAC (PAC Outgoing Call States)
Les états associés au PAC pour les appels sortants sont :
idle (inactif)
- Outgoing-Call-Request reçu. Si ceci est reçu en erreur, répondre avec un Outgoing-Call-Reply avec condition d'erreur définie. Sinon, allouer un canal physique pour composer. Passer l'appel sortant, attendre une connexion et passer à l'état wait_cs_ans.
wait_cs_ans (attente de réponse de commutation de circuit)
- Si l'appel est incomplet, envoyer un Outgoing-Call-Reply avec un code d'erreur non nul. Si un temporisateur expire sur un appel sortant, renvoyer un Outgoing-Call-Reply avec un code d'erreur non nul. Si une connexion de commutation de circuit est établie, envoyer un Outgoing-Call-Reply indiquant le succès.
established (établi)
- Si un Call-Clear-Request est reçu, l'appel téléphonique devrait être libéré (SHOULD) via des mécanismes appropriés et un message Call-Disconnect-Notify devrait être envoyé (SHOULD) au PNS. Si l'appel est déconnecté par le client ou par l'interface téléphonique, un message Call-Disconnect-Notify devrait être envoyé (SHOULD) au PNS.
3.2.4.2. États d'appel sortant PNS (PNS Outgoing Call States)
Les états associés au PNS pour les appels sortants sont :
idle (inactif)
- L'indication d'ouverture de l'application de couche supérieure entraîne l'envoi d'un Outgoing-Call-Request et le passage à l'état wait_reply.
wait_reply (attente de réponse)
- Si un Outgoing-Call-Reply avec erreur est reçu, retourner à l'état inactif. Si un Outgoing-Call-Reply réussi est reçu, passer à l'état établi. Si un abandon se produit en attendant l'Outgoing-Call-Reply, envoyer un Call-Clear-Request et passer à l'état wait_disconnect.
established (établi)
- Si un Call-Disconnect-Notify est reçu, passer à l'état inactif. Si une terminaison locale se produit, envoyer un Call-Clear-Request et passer à l'état wait_disconnect.
wait_disconnect (attente de déconnexion)
- Si un Call-Disconnect-Notify est reçu, passer à l'état inactif.
4. Fonctionnement du protocole de tunnel (Tunnel Protocol Operation)
Les données utilisateur transportées par le protocole PPTP sont des paquets de données PPP. Les paquets PPP sont transportés entre le PAC et le PNS, encapsulés dans des paquets GRE qui à leur tour sont transportés sur IP. Les paquets PPP encapsulés sont essentiellement des paquets de données PPP moins tous les éléments de tramage spécifiques au média. Aucun drapeau HDLC, insertion de bits, caractères de contrôle ou échappements de caractères de contrôle ne sont inclus. Aucun CRC n'est envoyé à travers le tunnel. Les paquets IP transmis sur les tunnels entre un PAC et un PNS ont la structure générale suivante :
+--------------------------------+
| Media Header |
| (En-tête média) |
+--------------------------------+
| IP Header |
| (En-tête IP) |
+--------------------------------+
| GRE Header |
| (En-tête GRE) |
+--------------------------------+
| PPP Packet |
| (Paquet PPP) |
+--------------------------------+
4.1. En-tête GRE amélioré (Enhanced GRE Header)
L'en-tête GRE utilisé dans PPTP est légèrement amélioré par rapport à celui spécifié dans la spécification actuelle du protocole GRE [1,2]. La principale différence concerne la définition d'un nouveau champ de numéro d'accusé de réception (Acknowledgment Number), utilisé pour déterminer si un paquet GRE particulier ou un ensemble de paquets est arrivé à l'extrémité distante du tunnel. Cette capacité d'accusé de réception n'est pas utilisée conjointement avec une retransmission de paquets de données utilisateur. Elle est plutôt utilisée pour déterminer le débit auquel les paquets de données utilisateur doivent être transmis sur le tunnel pour une session utilisateur donnée. Le format de l'en-tête GRE amélioré est le suivant :
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Description des champs
C (Bit 0) - Checksum Present (Somme de contrôle présente)
- Mettre à 0.
R (Bit 1) - Routing Present (Routage présent)
- Mettre à 0.
K (Bit 2) - Key Present (Clé présente)
- Mettre à 1.
S (Bit 3) - Sequence Number Present (Numéro de séquence présent)
- Mettre à 1 si un paquet de charge utile (données) est présent. Mettre à 0 si la charge utile n'est pas présente (le paquet GRE est un accusé de réception uniquement).
s (Bit 4) - Strict Source Route Present (Route source stricte présente)
- Mettre à 0.
Recur (Bits 5-7) - Recursion Control (Contrôle de récursion)
- Mettre à 0.
A (Bit 8) - Acknowledgment Sequence Number Present (Numéro de séquence d'accusé de réception présent)
- Mettre à 1 si le paquet contient un numéro d'accusé de réception à utiliser pour accuser réception des données précédemment transmises.
Flags (Bits 9-12)
- Doit être mis à 0 (MUST).
Ver (Bits 13-15) - Version
- Doit contenir 1 (GRE amélioré) (MUST).
Protocol Type (Type de protocole)
- Mettre à hexadécimal 880B [8].
Key (Clé)
- L'utilisation du champ Clé dépend de l'implémentation. PPTP l'utilise comme suit :
- Payload Length (Longueur de charge utile) (2 octets supérieurs de la clé) : Taille de la charge utile, sans inclure l'en-tête GRE
- Call ID (ID d'appel) (2 octets inférieurs) : Contient l'ID d'appel du pair pour la session à laquelle ce paquet appartient
Sequence Number (Numéro de séquence)
- Contient le numéro de séquence de la charge utile. Présent si le bit S (Bit 3) est à 1.
Acknowledgment Number (Numéro d'accusé de réception)
- Contient le numéro de séquence du paquet GRE le plus élevé reçu par le pair émetteur pour cette session utilisateur. Présent si le bit A (Bit 8) est à 1.
La section de charge utile contient un paquet de données PPP sans aucun élément de tramage spécifique au média.
Les numéros de séquence impliqués sont des numéros de séquence par paquet. Le numéro de séquence pour chaque session utilisateur est mis à zéro au démarrage de la session. Chaque paquet envoyé pour une session utilisateur donnée qui contient une charge utile (et a le bit S (Bit 3) mis à 1) se voit attribuer le prochain numéro de séquence consécutif pour cette session.
Ce protocole permet aux accusés de réception d'être transportés avec les données et rend le protocole global plus efficace, ce qui nécessite à son tour moins de mise en mémoire tampon des paquets.
4.2. Protocole à fenêtre glissante (Sliding Window Protocol)
Le protocole à fenêtre glissante utilisé sur le chemin de données PPTP est utilisé pour le contrôle de flux par chaque côté de l'échange de données. Le protocole GRE amélioré permet aux accusés de réception de paquets d'être superposés sur les paquets de données. Les accusés de réception peuvent également être envoyés séparément des paquets de données. Encore une fois, le but principal du protocole à fenêtre glissante est le contrôle de flux - les retransmissions ne sont pas effectuées par les pairs du tunnel.
4.2.1. Taille de fenêtre initiale (Initial Window Size)
Bien que chaque côté ait indiqué la taille maximale de sa fenêtre de réception, il est recommandé d'adopter une approche conservatrice lors du début de la transmission de données. La taille de fenêtre initiale sur l'émetteur est fixée à la moitié de la taille maximale demandée par le récepteur, avec une taille minimale d'un paquet. L'émetteur arrête d'envoyer des paquets lorsque le nombre de paquets en attente d'accusé de réception est égal à la taille de fenêtre actuelle. Au fur et à mesure que le récepteur digère avec succès chaque fenêtre, la taille de fenêtre sur l'émetteur est augmentée d'un paquet jusqu'à ce que le maximum soit atteint. Cette méthode empêche un système d'inonder un réseau déjà congestionné car aucun historique n'a été établi.
4.2.2. Fermeture de la fenêtre (Closing the Window)
Lorsqu'un délai d'expiration se produit sur un paquet, l'émetteur ajuste la taille de la fenêtre de transmission à la moitié de sa valeur au moment de l'échec. Les fractions sont arrondies vers le haut, et la taille de fenêtre minimale est de 1.
4.2.3. Ouverture de la fenêtre (Opening the Window)
Avec chaque transmission réussie d'une fenêtre de paquets sans délai d'expiration, la taille de fenêtre de transmission est augmentée d'un paquet jusqu'à ce qu'elle atteigne la taille de fenêtre maximale qui a été envoyée par l'autre côté lorsque l'appel a été connecté. Comme indiqué précédemment, aucune retransmission n'est effectuée lors d'un délai d'expiration. Après un délai d'expiration, la transmission reprend avec la fenêtre commençant à la moitié de la taille de la fenêtre de transmission lorsque le délai d'expiration s'est produit et s'ajustant vers le haut d'un chaque fois que la fenêtre de transmission est remplie de paquets qui sont tous accusés de réception sans délais d'expiration.
4.2.4. Débordement de fenêtre (Window Overflow)
Lorsque la fenêtre d'un récepteur déborde avec trop de paquets entrants, les paquets excédentaires sont jetés. Cette situation ne devrait pas survenir si les procédures de fenêtre glissante sont correctement suivies par l'émetteur et le récepteur. On suppose que, du côté de l'émission, les paquets sont mis en mémoire tampon pour la transmission et ne sont plus acceptés de la source de paquets lorsque le tampon de transmission se remplit.
4.2.5. Accusé de réception multi-paquets (Multi-packet Acknowledgment)
Une caractéristique du protocole à fenêtre glissante PPTP est qu'il permet l'accusé de réception de plusieurs paquets avec un seul accusé de réception. Tous les paquets en suspens avec un numéro de séquence inférieur ou égal au numéro d'accusé de réception sont considérés comme accusés de réception. Les calculs de délai d'expiration sont effectués en utilisant l'heure à laquelle le paquet correspondant au numéro de séquence le plus élevé accusé de réception a été transmis.
Les calculs de délai d'expiration adaptatifs ne sont effectués que lorsqu'un accusé de réception est reçu. Lorsque des accusés de réception multi-paquets sont utilisés, la surcharge de l'algorithme de délai d'expiration adaptatif est réduite. Le PAC n'est pas tenu (not required) de transmettre des accusés de réception multi-paquets ; il peut plutôt accuser réception de chaque paquet individuellement lorsqu'il est livré au client PPP.
4.3. Paquets hors séquence (Out-of-sequence Packets)
Occasionnellement, les paquets perdent leur séquençage à travers un internetwork compliqué. Disons, par exemple, qu'un PNS envoie les paquets 0 à 5 à un PAC. En raison du reroutage dans l'internetwork, le paquet 4 arrive au PAC avant le paquet 3. Le PAC accuse réception du paquet 4 et peut supposer que le paquet 3 est perdu. Cet accusé de réception accorde un crédit de fenêtre au-delà du paquet 4.
Lorsque le PAC reçoit effectivement le paquet 3, il ne doit pas (MUST NOT) tenter de le transmettre au client PPP correspondant. Le faire pourrait causer des problèmes, car le fonctionnement correct du protocole PPP est basé sur la réception de paquets dans l'ordre. PPP gère correctement la perte de paquets, mais pas la réorganisation, donc les paquets hors séquence entre le PNS et le PAC doivent être silencieusement jetés (MUST), ou ils peuvent être réordonnés par le récepteur. Lorsque le paquet 5 arrive, il est accusé de réception par le PAC puisqu'il a un numéro de séquence plus élevé que 4, qui était le dernier paquet le plus élevé accusé de réception par le PAC. Des paquets avec des numéros de séquence en double ne devraient jamais se produire puisque le PAC et le PNS ne retransmettent jamais de paquets GRE. Une implémentation robuste jettera silencieusement les paquets GRE en double, si elle en reçoit.
4.4. Délais d'expiration d'accusé de réception (Acknowledgment Time-Outs)
PPTP utilise des fenêtres glissantes et des délais d'expiration pour fournir à la fois un contrôle de flux de session utilisateur à travers l'internetwork et pour effectuer une mise en mémoire tampon de données efficace afin de maintenir les canaux de données PAC-PNS pleins sans provoquer de débordement de tampon de réception. PPTP exige qu'un délai d'expiration soit utilisé pour récupérer des paquets de données ou d'accusé de réception perdus. L'implémentation exacte du délai d'expiration est spécifique au fournisseur. Il est suggéré qu'un délai d'expiration adaptatif soit implémenté avec un recul pour le contrôle de la congestion. Le mécanisme de délai d'expiration proposé ici a les propriétés suivantes :
- Délais d'expiration indépendants pour chaque session : Un dispositif (PAC ou PNS) devra maintenir et calculer des délais d'expiration pour chaque session active.
- Un délai d'expiration maximum ajustable par l'administrateur (MaxTimeOut) : Unique à chaque dispositif.
- Un mécanisme de délai d'expiration adaptatif : Qui compense le débit changeant. Pour réduire la surcharge de traitement des paquets, les fournisseurs peuvent choisir de ne pas recalculer le délai d'expiration adaptatif pour chaque accusé de réception reçu. Le résultat de cette réduction de surcharge est que le délai d'expiration ne répondra pas aussi rapidement aux changements rapides du réseau.
- Recul du temporisateur lors du délai d'expiration : Pour réduire la congestion. La valeur du temporisateur reculé est limitée par la valeur de délai d'expiration maximum configurable. Le recul du temporisateur est effectué chaque fois qu'un délai d'expiration d'accusé de réception se produit.
En général, ce mécanisme a le comportement souhaitable de reculer rapidement lors d'un délai d'expiration et de diminuer lentement la valeur du délai d'expiration lorsque les paquets sont livrés sans délais d'expiration.
Définitions
Packet Processing Delay (PPD) - Délai de traitement des paquets
- Le temps nécessaire pour que chaque côté traite la quantité maximale de données mise en mémoire tampon dans leur fenêtre glissante de réception de paquets. Le PPD est la valeur échangée entre le PAC et le PNS lorsqu'un appel est établi. Pour le PNS, ce nombre devrait être petit. Pour un PAC effectuant des connexions modem, ce nombre pourrait être significatif.
Sample (Échantillon)
- Le temps réel encouru pour recevoir un accusé de réception pour un paquet. L'échantillon est mesuré, pas calculé.
Round-Trip Time (RTT) - Temps aller-retour
- Le temps aller-retour estimé pour qu'un accusé de réception soit reçu pour un paquet transmis donné. Lorsque le lien réseau est un réseau local, ce délai sera minimal (sinon nul). Lorsque le lien réseau est Internet, ce délai pourrait être substantiel et varier largement. Le RTT est adaptatif : il s'ajustera pour inclure le PPD et tous les délais réseau changeants qui contribuent au temps entre la transmission d'un paquet et la réception de son accusé de réception.
Adaptive Time-Out (ATO) - Délai d'expiration adaptatif
- Le temps qui doit s'écouler avant qu'un accusé de réception soit considéré comme perdu. Après un délai d'expiration, la fenêtre glissante est partiellement fermée et l'ATO est reculé.
Le paramètre de délai de traitement des paquets (PPD) est un mot de 16 bits échangé pendant la phase de contrôle d'appel qui représente des dixièmes de seconde (64 signifie 6,4 secondes). Le protocole spécifie seulement que le paramètre est échangé, il ne spécifie pas comment il est calculé. La manière dont les valeurs pour PPD sont calculées dépend de l'implémentation et n'a pas besoin d'être variable (les délais d'expiration statiques sont autorisés). Le PPD doit être échangé (MUST) dans les séquences de connexion d'appel, même s'il reste constant dans une implémentation. Une façon possible de calculer le PPD est :
PPD' = ((PPP_MAX_DATA_MTU - Header) * WindowSize * 8) / ConnectRate
PPD = PPD' + PACFudge
Où :
- Header est la taille totale des en-têtes IP et GRE, qui est de 36
- MTU est le MTU global pour le lien internetwork entre le PAC et le PNS
- WindowSize représente le nombre de paquets dans la fenêtre glissante et dépend de l'implémentation
- La constante 8 convertit les octets en bits (en supposant que ConnectRate est en bits par seconde)
- PACFudge n'est pas requis mais peut être utilisé pour prendre en compte la surcharge de traitement globale du PAC
La valeur de PPD est utilisée pour initialiser l'algorithme adaptatif avec la valeur initiale RTT[n-1].
4.4.1. Calcul du délai d'expiration d'accusé de réception adaptatif (Calculating Adaptive Acknowledgment Time-Out)
Nous devons encore décider combien de temps allouer pour que les accusés de réception reviennent. Si le délai d'expiration est réglé trop haut, nous pouvons attendre inutilement longtemps pour les paquets perdus. Si le délai d'expiration est trop court, nous pouvons expirer juste avant l'arrivée de l'accusé de réception. Le délai d'expiration d'accusé de réception devrait également être raisonnable et réactif aux conditions réseau changeantes.
L'algorithme adaptatif suggéré détaillé ci-dessous est basé sur l'implémentation TCP 1989 et est expliqué dans [11]. 'n' signifie le paquet actuel et 'n-1' signifie le paquet précédent :
Err[n] = Sample[n] - RTT[n-1]
RTT[n] = RTT[n-1] + (g * Err[n])
Dev[n] = Dev[n-1] + h * (|Err[n]| - Dev[n-1])
ATO[n] = RTT[n] + (f * Dev[n])
Où :
- g est le facteur de gain (valeur recommandée 0.125)
- h est le facteur de gain de déviation (valeur recommandée 0.25)
- f est le facteur de multiplication de déviation (valeur recommandée 4)
4.4.2. Contrôle de congestion : Ajustement pour le délai d'expiration (Congestion Control: Adjusting for Time-Out)
Cette section décrit comment le calcul de l'ATO est modifié dans le cas où un délai d'expiration se produit. Lorsqu'un délai d'expiration se produit, la valeur du délai d'expiration devrait être ajustée rapidement vers le haut. Bien que les paquets GRE ne soient pas retransmis lorsqu'un délai d'expiration se produit, le délai d'expiration devrait être ajusté vers une limite maximale. Pour compenser les délais temporels internetwork changeants, une stratégie doit être employée pour augmenter le délai d'expiration lorsqu'il expire (notez qu'en plus d'augmenter le délai d'expiration, nous rétrécissons également la taille de la fenêtre comme décrit dans la section suivante).
Pour un intervalle dans lequel un délai d'expiration se produit :
ATO[n] = MIN(2 * ATO[n-1], MaxTimeOut)
Où MaxTimeOut est la valeur de délai d'expiration maximum configurée par l'administrateur.
5. Considérations de sécurité (Security Considerations)
La sécurité des données utilisateur transmises sur la connexion PPP tunnelisée est traitée par PPP, tout comme l'authentification des pairs PPP.
Étant donné que les messages du canal de contrôle PPTP ne sont ni authentifiés ni protégés en intégrité, il pourrait être possible pour un attaquant de détourner la connexion TCP sous-jacente. Il est également possible de fabriquer de faux messages de canal de contrôle et de modifier les messages authentiques en transit sans détection.
Les paquets GRE formant le tunnel lui-même ne sont pas protégés cryptographiquement. Étant donné que les négociations PPP sont effectuées sur le tunnel, il peut être possible pour un attaquant d'écouter et de modifier ces négociations.
À moins que les données de charge utile PPP ne soient protégées cryptographiquement, elles peuvent être capturées et lues ou modifiées.
6. Adresses des auteurs (Authors' Addresses)
Kory Hamzeh
Ascend Communications
1275 Harbor Bay Parkway
Alameda, CA 94502
Email: [email protected]
Gurdeep Singh Pall
Microsoft Corporation
Redmond, WA
Email: [email protected]
William Verthein
U.S. Robotics/3Com
Jeff Taarud
Copper Mountain Networks
W. Andrew Little
ECI Telematics
Glen Zorn
Microsoft Corporation
Redmond, WA
Email: [email protected]
7. Références (References)
[1] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 1701, October 1994.
[2] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic Routing Encapsulation (GRE) over IPv4 Networks", RFC 1702, October 1994.
[3] Lloyd, B. and W. Simpson, "PPP Authentication Protocols", RFC 1334, October 1992.
[4] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[5] Postel, J., "User Data Protocol", STD 6, RFC 768, August 1980.
[6] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994. See also: http://www.iana.org/numbers.html
[7] Simpson, W., editor, "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[8] Ethertype for PPP, Reserved with Xerox Corporation.
[9] Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996.
[10] Blunk, L. and J Vollbrecht, "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998.
[11] Stevens, R., "TCP/IP Illustrated, Volume 1", p. 300, Addison-Wesley, 1994.
[12] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
8. Déclaration complète de copyright (Full Copyright Statement)
Copyright (C) The Internet Society (1999). All Rights Reserved.
Ce document et ses traductions peuvent être copiés et fournis à d'autres, et les œuvres dérivées qui commentent ou expliquent autrement ce document ou aident à sa mise en œuvre peuvent être préparées, copiées, publiées et distribuées, en tout ou en partie, sans restriction d'aucune sorte, à condition que l'avis de copyright ci-dessus et ce paragraphe soient inclus dans toutes ces copies et œuvres dérivées. Cependant, ce document lui-même ne peut être modifié d'aucune manière, par exemple en supprimant l'avis de copyright ou les références à l'Internet Society ou à d'autres organisations Internet, sauf si cela est nécessaire dans le but de développer des normes Internet, auquel cas les procédures de copyright définies dans le processus des normes Internet doivent être suivies, ou selon les besoins pour le traduire dans des langues autres que l'anglais.
Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par l'Internet Society ou ses successeurs ou ayants droit.
Ce document et les informations qu'il contient sont fournis "TELS QUELS" et l'Internet Society et l'Internet Engineering Task Force DÉCLINENT TOUTES GARANTIES, EXPRESSES OU IMPLICITES, Y COMPRIS MAIS SANS S'Y LIMITER TOUTE GARANTIE QUE L'UTILISATION DES INFORMATIONS ICI CONTENUES NE VIOLE AUCUN DROIT OU TOUTE GARANTIE IMPLICITE DE QUALITÉ MARCHANDE OU D'ADÉQUATION À UN USAGE PARTICULIER.