Protocole de transmission sous tunnel point à point

(Point-to-Point Tunneling Protocol - PPTP)

Statut de ce mémo

Ce mémo procure une information à la communauté internet. il ne spécifie en aucun cas un standard internet. La distribution de ce mémo est libre.

Copyright

Copyright (C) The Internet Society (1999). Tous droits réservés.

Notes de traduction

Le texte original est traduit aussi fidèlement que possible, Les acronymes issus de mots anglais sont conservés tel quels mais généralement explicités à leur première occurrence. Des notes de traduction (N.D.T.) peuvent préciser des concepts qui se décrivent en anglais avec un seul mot ainsi que des caractéristiques ou exceptions françaises.

Note de l'IESG

Le protocole PPTP a été développé par un consortium de fabricants. La documentation de PPTP est fournie pour l'information de la communauté internet. Le groupe de travail PPP est en train de définir un protocole standard (L2TP) pour le transport de PPP dans un tunnel au sein d'un réseau par commutation de paquets. (N.D.T. C'est devenu PPoE)

Généralités

Ce document spécifie un protocole qui permet au Protocole Point à Point (PPP) d'être transporté dans un tunnel au travers d'un réseau IP (Protocole internet). PPTP n'apporte aucun changement au protocole PPP mais décrit plutôt un nouveau moyen de transporter PPP. Une architecture client-serveur est définie en vue de séparer les fonctions qui existent dans un serveur d'accès réseau (NAS) existant et les réseau privés virtuels (VPN). Le serveur réseau PPTP (PNS) est conçu pour fonctionner avec un système d'exploitation polyvalent tandis que le client, connu sous le nom de concentrateur d'accès PPTP (PAC) fonctionne sur une plate-forme d'accès téléphonique. PPTP spécifie un protocole de contrôle et de gestion des appels qui permet au serveur de contrôler les circuits de numérotation analogiques ou numériques afin de générer un appel sortant. Pour fournir un contrôle du flux et des encombrements, PPTP utilise un mécanisme GRE avancé (Encapsulation de routage générique) d'encapsulation des datagrammes pour le transport des paquets PPP.

Règles de base

Dans ce document, les mots clés « PEUT », « DOIT », « NE DOIT PAS », « OPTIONNEL », RECOMMENDE » doivent être interprétés comme décrit en [12].

Le mot « rejeté », quand il est utilisé par rapport à l'attitude d'une implémentation devant la réception d'un paquet, doit être interprété comme suit : l'implémentation rejette le datagramme sans autre action et sans prévenir l'expéditeur. L'implémentation DEVRAIT procurer la possibilité de journaliser l'erreur avec le contenu du datagramme rejeté et DEVRAIT enregistrer cet événement dans un compteur statistique.

Table des matières

1. Introduction
1.1. Buts et définition du protocole
1.2. Terminologie
1.3. Vue générale du protocole
1.3.1. Vue générale du protocole de liaison de contrôle
1.3.2. Vue générale du protocole de tunnel
1.4. Format des messages et extensibilité du protocole
2. Spécifications du protocole de liaison de contrôle
2.1. Établissement de liaison de contrôle-Demande
2.2. Établissement de liaison de contrôle-Réponse
2.3. Fermeture de liaison de contrôle-Demande
2.4. Fermeture de liaison de contrôle-Réponse
2.5. Écho-Demande
2.6. Écho-Réponse
2.7. Appel sortant-Demande
2.8. Appel sortant-Réponse
2.9. Appel entrant-Demande
2.10. Appel entrant-Réponse
2.11. Appel entrant-Connecté
2.12. Fin d'appel-Demande
2.13. Appel terminé-Notification
2.14. Erreur WAN (Réseau étendu)-Notification
2.15. Paramètrage lien-Info
2.16. Codes des erreurs générales
3. Fonctionnement du protocole de liaison de contrôle
3.1. États de la liaison de contrôle
3.1.1. Initiateur de la liaison de contrôle (PAC ou PNS)
3.1.2. Destinataire de la liaison de contrôle (PAC ou PNS)
3.1.3. Collision de la demande d'établissement de liaison de contrôle par l'initiateur
3.1.4. « Maintien de connexion » et temporisations
3.2. États d'un appel
3.2.1. Considérations sur les temporisations
3.2.2. Valeur des identificateurs d'appel
3.2.3. Appels entrants
3.2.3.1. PAC États des appels entrants
3.2.3.2. PNS États des appels entrants
3.2.4. Appels sortants
3.2.4.1. PAC États des appels sortants
3.2.4.2. PNS États des appels sortants
4. Fonctionnement du protocole de tunnel
4.1. En-tête GRE étendu
4.2. Protocole de « fenêtre coulissante »
4.2.1. Taille initiale de la fenêtre
4.2.2. Rétrécissement de la fenêtre
4.2.3. Élargissement de la fenêtre
4.2.4. Débordement de la fenêtre
4.2.5. Acquittement de paquets multiples
4.3. Paquets hors séquence
4.4. Temporisation d'acquittement
4.4.1. Calcul évolutif des temporisations d'acquittement
4.4.2. Contrôle des encombrements: Réglage des temporisations
5. Considérations de sécurité
6. Adresses des auteurs
7. Références
8. Copyright intégral

1. Introduction

PPTP permet de séparer les fonctions d'un serveur d'accès réseau (NAS) grâce à une architecture client-serveur. Traditionnellement les fonctions suivantes sont implémentées dans un NAS:

1) Interfaçage physique avec le PSTN (Réseau téléphonique analogique) ou l'ISDN (Réseau téléphonique numérique (N.D.T. Réseau Numéris en France) et contrôle des modems extérieurs ou des adaptateurs terminaux de ligne numérique. (N.D.T. L'adaptateur terminal de ligne numérique est souvent appelé improprement « modem » numérique)

Un NAS peut interfacer directement un circuit de télécommunication ou utiliser un modem extérieur ou adaptateur terminal. Le contrôle des connexions par circuit commuté se fait soit par le modem soit par les fonctions de contrôle d'appel des adaptateurs terminaux numériques

Le NAS, avec le modem ou l'adaptateur terminal numérique, peut adapter la vitesse, convertir l'analogique en numérique, convertir le synchrone en asynchrone ou effectuer d'autres opérations sur les flux de données.

2) Fermeture logique d'un lien point à point (PPP).

3) Participer à l'authentification dans le protocole PPP [3, 9, 10].

4) Assemblage des canaux et gestion d'ensemble pour le protocole multi-liens PPP.

5) Arrêt logique des différents protocoles de contrôles réseau (NCP) de PPP.

6) Routage multi-protocoles et pontage entre les interfaces du NAS.

PPTP répartit ces fonctions entre le PAC et le PNS. Le PAC est responsable des fonctions 1, 2 et parfois 3. Le PNS est responsable des fonctions 4, 5, 6 et parfois 3. Le protocole utilisé pour transporter les unités de données PPP (PDU) entre le PAC et le PNS ainsi que pour le contrôle et la gestion constitue PPTP.

La séparation des fonctions du NAS offre certains avantages :

Gestion flexible des adresses IP. Les utilisateurs distants peuvent avoir une adresse IP unique alors qu'ils communiquent avec différents PACs 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 assigne des adresses ayant un sens sur le réseau privé.

Support de protocoles non IP pour des réseaux distants derrière des réseaux IP. Cela permet à Appletalk et IPX par exemple de passer dans le tunnel au travers d'un fournisseur uniquement IP. Le PAC n'a pas besoin de traiter ces protocoles.

Une solution au problème de répartition des liens multiples. PPP multi-liens utilise en principe sur l'ISDN un ensemble de canaux B qui doivent être regroupés sur un NAS unique. Puisque l'ensemble multi-liens PPP peut être géré par un unique PNS, les canaux formant l'ensemble peuvent transiter dans plusieurs PACs.

1.1. Buts et définitions du protocole

Le protocole PPTP n'est implémenté que par les PACs et PNSs. Aucun autre système n'est affecté par PPTP. Les réseaux distants peuvent se connecter à un PAC sans traiter avec PPTP. Le logiciel client PPP DOIT continuer à fonctionner au travers d'un lien PPP en tunnel.

PPTP peut aussi transmettre en tunnel une session PPP au travers d'un réseau IP. Dans ce cas le tunnel PPTP et la session PPP fonctionnent entre les deux mêmes machines, l'appelant jouant le rôle du PNS.

Il est envisagé qu'il puise y avoir une relation « plusieurs à plusieurs » entre PACs et PNSs. Un PAC peut fournir ses services à plusieurs PNSs. Par exemple, un fournisseur d'accès internet peut choisir d'utiliser PPTP pour certains réseaux privés de clients et créer des VPNs pour eux. Chaque VPN peux fonctionner avec un ou plusieurs PNSs. Un PNS unique peux être associé à plusieurs PACs pour concentrer le trafic d'un grand nombre de sites géographiques.

PPTP utilise une version étendue de GRE pour transporter les paquets PPP. Ces améliorations permettent un moindre encombrement et un contrôle de flux dans le tunnel utilisé pour transporter les données entre PAC et PNS. Ce mécanisme permet une utilisation plus efficace de la bande passante disponible pour les tunnels, évite les retransmissions et les débordements de tampon. PPTP n'impose pas d'algorithmes particuliers pour cela mais il définit les paramètres qui DOIVENT être transmis pour que ces algorithmes fonctionnent. Des suggestions d'algorithmes se trouvent en section 4.

1.2. Terminologie

Circuit analogique : Un circuit commuté de communication analogique qui est prévu pour transporter un signal audio de 3,1 kHz bilatéralement.

Circuit numérique: Un circuit commuté de communication numérique qui est prévu pour transporter bilatéralement des informations digitales.

Appel : La connexion ou l'essai de connexion entre deux terminaux d'une liaison téléphonique analogique ou numérique; par exemple un appel téléphonique entre deux modems.

Liaison de contrôle : Une liaison de contrôle est créée pour chaque paire de PAC/PNS et est basée sur TCP [4]. La liaison de contrôle s'occupe d'entretenir le tunnel et les sessions qui y sont associées.

Utilisateur distant : Un système terminal ou un routeur relié au réseau téléphonique analogique ou numérique qui peut être l'initiateur ou le destinataire d'un appel.

Serveur d'accès réseau (NAS) : Un système procurant temporairement et à la demande un accès réseau aux utilisateurs. Cet accès point à point utilise le réseau téléphonique analogique ou numérique.

Concentrateur d'accès PPTP (PAC) : Un appareil relié à une ou plusieurs lignes téléphonique analogique ou numérique offrant un fonctionnement PPP et supportant le protocole PPTP. Le PAC ne nécessite que l'implémentation de TCP/IP pour traiter le trafic d'un ou plusieurs PNSs. Il peut aussi transmettre en tunnel des protocoles non IP.

Serveur réseau PPTP (PNS) : Un PNS est conçu pour fonctionner sur un ordinateur ou serveur à usage général. Le PNS gère le coté serveur du protocole PPTP. Du fait que PPTP repose entièrement sur TCP/IP et est indépendant de l'interface matérielle, le PNS peut utiliser n'importe quelle combinaison d'interface matérielle IP incluant des périphériques LAN et WAN.

Session : PPTP est orienté connexion. Le PNS et le PAC contrôlent l 'état de la liaison de chaque utilisateur relié au PAC. Une session est créée quand une connexion point à point PPP est demandée entre un utilisateur distant et le PNS. Les datagrammes relatifs à une session sont envoyés dans 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 [1, 2]. Le tunnel transporte les datagrammes PPP entre le PAC et le PNS. Plusieurs sessions peuvent être multiplexées dans un unique tunnel. Une liaison de contrôle basée sur TCP gère l'établissement, la fermeture et l'entretien des sessions ainsi que le tunnel lui-même.

1.3. Vue générale du protocole

Il y a deux composants parallèles dans PPTP :

1) La liaison de contrôle entre chaque paire PAC/PNS basée sur TCP

2) Un tunnel IP reliant la même paire PAC/PNS qui est utilisé pour transporter les paquets PPP encapsulés des sessions utilisateurs.

1.3.1. Vue générale de la liaison de contrôle

Avant que la mise sous tunnel de PPP ne puise se faire entre un PAC et un PNS, une liaison de contrôle doit être établie entre eux. La liaison de contrôle est une session TCP standard qui transmettra le contrôle des appels PPTP et la gestion des informations. La session de la liaison de contrôle et les sessions transmises dans le tunnel PPTP sont logiquement associés bien que différentes. Pour chaque paire de PAC/PNS il existe une liaison de contrôle et un tunnel. La liaison de contrôle est responsable de l'établissement, de la gestion et de la fermeture des sessions transportées dans le tunnel. C'est le moyen d'informer un PNS d'un appel entrant dans le PAC associé ainsi que de demander au PAC d'effectuer un appel sortant.

Une liaison de contrôle peut être établie par le PNS ou le PAC. Après l'établissement de la connexion TCP requise, le PNS et le PAC établissent la liaison de contrôle en utilisant les messages « Établissement de la liaison de contrôle », demande et réponse. Ces messages sont aussi utilisés pour échanger des informations à propos des capacités de base du PAC et du PNS. Quand la liaison de contrôle est établie, le PAC ou le PNS peut initier des sessions en demandant des appels sortants ou en répondant aux appels entrants. La liaison de contrôle peux communiquer des changements de caractéristiques d'une session individuelle avec le message « Lien - Info » Les sessions peuvent être individuellement fermées par le PAC ou le PNS toujours au moyen des messages de la liaison de contrôle.

La liaison de contrôle elle-même est entretenue par des messages « Maintien de connexion ». Cela assure qu'une défaillance de connexion entre le PNS et le PAC sera détectée sur temporisation. D'autres défaillances peuvent être signalées à l'aide du message « Notification d'erreur WAN », également sur la liaison de contrôle.

Il est également prévu que la liaison de contrôle transportera des messages de gestion dans le futur, comme un message permettant à un PNS de demander le statut d'un PAC donné; ces types de message ne sont pas encore définis.

1.3.2. Vue générale du protocole de tunnel

PPTP nécessite l'établissement d'un tunnel pour chaque paire de PNS/PAC en communication. Ce tunnel est utilisé pour transporter tous les paquets PPP des sessions utilisateurs concernées par cette paire PNS/PAC. Une clé présente dans l'en-tête GRE indique à quelle session PPP particulière ce paquet appartient.

De cette manière les paquets PPP sont multiplexés et démultiplexés dans un unique tunnel entre une paire PNS/PAC donnée. La valeur de cette clé est définie par la procédure d'établissement de l'appel qui fait partie de la liaison de contrôle.

L'en-tête GRE contient aussi l'acquittement et des informations de séquencement qui sont utilisées pour contrôler les encombrements et détecter les erreurs dans le tunnel. La liaison de contrôle sert encore à déterminer la vitesse de transmission et les paramètres des tampons qui sont utilisés pour réguler le flux de paquets PPP d'une session donnée dans le tunnel. PPTP ne spécifie pas les algorithmes à utiliser pour le contrôle des encombrements et du flux. En section 4.4 de ce document se trouvent des suggestions d'algorithmes pour la détermination des temporisations évolutives pour la récupération à partir des données perdues ou des acquittements.

1.4. Format des messages et extensibilité du protocole

PPTP défini un jeu de messages envoyés en tant que données TCP sur la liaison de contrôle entre un PNS et un PAC donné. La session TCP pour la liaison de contrôle est établie en ouvrant une session TCP vers le port 1723 [6]. Le port source est n'importe quel port inutilisé.

Chaque message de la liaison de contrôle PPTP commence par un en-tête de longueur fixe de 8 octets. Cet en-tête fixe contient : la longueur totale du message, le type de message PPTP et un nombre magique.

Deux types de message de la liaison de contrôle sont indiqués par le champ « type » du message PPTP :

1 – Message de contrôle

2 – Message de gestion

Les messages de gestion ne sont pas actuellement définis.

Le nombre magique est toujours la constante 0x1A2B3C4D. Son utilité de base 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 être utilisé pour resynchroniser le flux de données TCP au cas ou l'expéditeur fourni un message incorrectement formaté. La perte de synchronisation DOIT entraîner immédiatement la fermeture de la session TCP de la liaison de contrôle.

Pour plus de clarté, tout les modèles de message de la liaison de contrôle dans la prochaine section incluent entièrement l'en-tête de message. 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 :

Les messages « Établissement de liaison de contrôle » demande et réponse déterminent la version du protocole de liaison de contrôle qui sera utilisée. Le champ de version transporté dans ce message consiste en un numéro de version dans l'octet de poids fort et un numéro de révision dans l'octet de poids faible. Le support des versions est décrit en section 2. La valeur actuelle du champ de version est 0x0100 pour version 1, révision 0.

L'utilisation d'en-têtes de style GRE pour l'encapsulation des paquets utilisateur PPP est spécifiée en section 4.1.

Le MTU (Unité maximale de transmission) de chaque paquet de données utilisateur encapsulé est de 1532 octets, non compris les en-tête GRE et IP.

2. Spécifications du protocole de liaison de contrôle

Des messages de la liaison de contrôle sont utilisés pour établir et fermer des sessions utilisateur. Le premier jeu de message de la liaison de contrôle sert à entretenir la liaison de contrôle elle-même. La liaison de contrôle est initiée soit par le PNS soit par le PAC après qu'ils aient établie la connexion TCP sous-jacente. Les procédures et informations de configuration requises pour l'établissement de cette connexion TCP ne sont pas couvertes par ce protocole.

Les messages de la liaison de contrôle suivants sont tous envoyés en tant que données utilisateur sur la connexion TCP établie entre la paire PNS/PAC. Notez qu'il a été fait attention à ce que les mots (2 octets) et les mots longs (4 octets) commencent aux limites appropriées. Toutes les données sont envoyées sur le réseau dans l'ordre. (Octet de poids fort en premier.) Les champs « Réservé » DOIVENT être remplis de 0 pour permettre les extensions du protocole.

2.1. Établissement de liaison de contrôle-Demande

Le message «  Établissement de liaison de contrôle-Demande » est un message de contrôle PPTP utilisé pour établir la liaison de contrôle entre un PNS et un PAC. Chaque paire de PNS/PAC nécessite qu'une liaison de contrôle dédiée soit créée. Une liaison de contrôle doit être établie avant que d'autres messages puisent être utilisés. L'établissement de la liaison de contrôle peut être initiée soit par le PNS soit par le PAC. Une procédure qui gère le cas d'une collision entre demande du PNS et demande du PAC est décrite en section 3.1.3.

2.2. Établissement de liaison de contrôle-Réponse

Le message «  Établissement de liaison de contrôle-Réponse » est un message de contrôle PPTP envoyé en réponse à un message «  Établissement de liaison de contrôle-Demande ». Ce message contient un code indiquant le résultat de l'établissement de la liaison de contrôle.

2.3. Fermeture de liaison de contrôle-Demande

Le message «  Fermeture de liaison de contrôle-Demande » est un message de contrôle PPTP envoyé par une extrémité de la liaison PAC/PNS pour informer l'autre extrémité que la liaison de contrôle doit être fermée. En plus de fermer la liaison de contrôle tout les appels utilisateurs sont également stoppés. La raison de cette requête est indiquée dans le champ « raison ».

2.4. Fermeture de liaison de contrôle-Réponse

Le message «  Fermeture de liaison de contrôle-Réponse » est un message de contrôle PPTP envoyé par une extrémité de la liaison PAC/PNS suite à la réception du message « Fermeture de liaison de contrôle-Demande » de l'autre extrémité.

2.5.-Écho-Demande

Le message « Écho-Demande » est un message de contrôle PPTP envoyé par l'une des extrémité de la liaison de contrôle PAC/PNS. Ce message de contrôle est utilisé pour « garder en vie » la liaison de contrôle. L'extrémité réceptrice adresse un message « Écho-Réponse » à chaque message « Écho-Demande » reçu. Comme spécifié en section 3.1.4, si l'expéditeur ne reçoit pas de « Écho-Réponse » en réponse à son « Écho-Demande », il doit éventuellement fermer la liaison de contrôle.

2.6. Écho-Réponse

Le message « Écho-Réponse » est un message de contrôle PPTP envoyé par l'une des extrémité de la liaison de contrôle PAC/PNS en réponse à un message « Écho-Demande ».

2.7. Appel sortant-Demande

Le message « Appel sortant-Demande » est un message de contrôle PPTP envoyé par le PNS au PAC pour lui demander d'effectuer un appel sortant. Cette requête fournie au PAC les informations nécessaires pour faire cet appel. Il procure aussi au PAC les paramètres de transmissions des données vers le PNS dès que la session aura été établie.

2.8. Appel sortant-Réponse

Le message « Appel sortant-Réponse » est un message de contrôle PPTP envoyé par le PAC au PNS en réponse à un message « Appel sortant-Demande ». La réponse indique le résultat de la tentative d'appel. Il procure aussi au PNS des informations sur certains paramètres utilisés pour l'appel. Il donne des informations qui permettent au PNS de réguler la transmission des données vers le PAC pour cette session.

2.9. Appel entrant-Demande

Le message « Appel entrant-Demande » est un message de contrôle PPTP envoyé par le PAC au PNS pour signaler qu'un appel entrant doit être établi par le PAC. Cette requête fourni au PNS des informations sur l'appel entrant.
Ce message est le premier d'un triple échange utilisé par PPTP pour établir un appel entrant. Le PAC peut différer sa réponse à l'appel jusqu'à ce qu'il ait reçu un message « Appel entrant-Réponse » du PNS indiquant que l'appel doit être établi. Ce mécanisme permet au PNS d'obtenir suffisamment d'informations sur l'appel avant qu'il n'y soit répondu afin de déterminer si'il faut ou non y répondre.

2.10. Appel entrant-Réponse

Le message « Appel entrant-Réponse » est un message de contrôle PPTP envoyé par le PNS au PAC en réponse à un message « Appel entrant-Demande ». La réponse indique le résultat de la tentative d'appel. Il procure aussi au PAC des informations qui permettent de réguler la transmission des données vers le PNS pour cette session.
Ce message est le second du triple échange utilisé par PPTP pour établir un appel entrant. Il indique au PAC s'il faut répondre ou non à l'appel.

2.11. Appel entrant-Connecté

Le message « Appel entrant-Connecté » est un message de contrôle PPTP envoyé par le PAC au PNS en réponse à un message « Appel entrant-Réponse ». Il procure au PNS certaines informations sur l'appel. Il procure aussi des informations qui permettent au PNS de réguler la transmission des données vers le PAC pour cette session.
Ce message est le troisième du triple échange utilisé par PPTP pour établir un appel entrant. Il fournit le moyen de donner au PNS des informations sur l'appel qui ne peuvent pas en général être obtenue au moment ou le PAC adresse son message « Appel entrant-Demande »

2.12. Fin d'appel-Demande

Le message « Fin d'appel-Demande » est un message de contrôle PPTP envoyé par le PNS au PAC indiquant qu'un appel particulier doit être arrêté. L'appel à arrêter peut être entrant ou sortant, dans n'importe quel état. Le PAC réponds à ce message avec un message « Appel terminé-Notification ».

2.13. Appel terminé-Notification

Le message « Appel terminé-Notification » est un message de contrôle PPTP envoyé par le PAC au PNS. Il est émis quand un appel est interrompu suite à la réception par le PAC d'un message « Fin d'appel-Demande » ou pour n'importe quelle autre raison. Son rôle est d'informer le PNS à la fois de la déconnexion et de la raison de celle-ci.

2.14. Erreur WAN-Notification

Le message « Erreur WAN-Notification » est un message de contrôle PPTP envoyé par le PAC au PNS pour indiquer une erreur WAN (Erreur se produisant sur l'interface supportant PPP). Les compteurs de ce message sont cumulatifs. Ce message ne DOIT être envoyé que lorsqu'une erreur se produit et pas plus d'une fois toute les 60 secondes. Les compteurs sont remis à zéro lors d'un nouvel appel.

2.15. Paramètrage lien-Info

Le message « Paramètrage lien-Info » est un message de contrôle PPTP envoyé par le PNS au PAC pour configurer les options négociées PPP. Du fait que ces options peuvent changer à n'importe quel moment de l'appel, le PAC doit pouvoir mettre à jour ses paramètres d'appel internes de manière dynamique et réaliser une négociation PPP sur une session PPP active.

2.16. Codes des erreurs générales

Les erreurs générales ne sont pas spécifiques à une requête PPTP particulière mais appartiennent plutôt au protocole ou aux erreurs de format de message. Si une réponse PPTP indique dans son code résultat qu'une erreur générale s'est produite, la valeur de l'erreur générale DOIT être examinée pour déterminer de quelle erreur il s'agit. Les codes et significations des erreurs actuellement définis sont :

0 - Aucune - Pas d'erreur générale

1 - Non connecté - Il n'y a pas de liaison de contrôle pour cette paire PAC/PNS

2 - Mauvais format - Longueur erronée ou nombre magique incorrect

3 - Mauvaise valeur - La valeur de l'un des champs était hors limites ou un champ réservé n'était pas à zéro

4 - Pas de ressource - Les ressources sont insuffisantes pour supporter cette commande maintenant.

5 - Mauvais identifiant d'appel - L'identifiant d'appel n'est pas valide dans ce contexte

6 - Erreur PAC - Une erreur générique spécifique au fabriquant dans le PAC

3. Fonctionnement du protocole de liaison de contrôle

Cette section décrit le fonctionnement des différentes fonctions de la liaison de contrôle PPTP et les messages utilisés par cette liaison. Le fonctionnement du protocole de la liaison de contrôle est simplifié par l'usage de TCP pour fournir un mécanisme de transport fiable. Le séquencement et la retransmission des messages n'intervient pas à ce niveau. La connexion TCP elle-même peut cependant s'arrêter à tout moment et un mécanisme de récupération d'erreur approprié doit être prévu dans ce cas.

Des procédures de récupération d'erreur sont communes à tout les niveaux de la liaison de contrôle. Si une réponse attendue n'arrive pas dans les 60 secondes, la liaison de contrôle est fermée, sauf spécifications contraires. Un enregistrement approprié DOIT être implémenté pour déterminer facilement les problèmes et les raisons d'une clôture de la liaison de contrôle.

La réception d'un message de la liaison de contrôle non-valide ou mal-formé DOIT être enregistré et la liaison de contrôle DOIT être fermée, puis redémarrée pour se retrouver dans un état connu.

3.1. États de la liaison de contrôle

La liaison de contrôle repose sur une connexion TCP standard. Le protocole PPTP de la liaison de contrôle ne fait pas de différence entre le PNS et le PAC mais entre l'initiateur et le destinataire. L'extrémité d'origine est celle qui a essayé en premier d'ouvrir la liaison TCP. Du fait que le PAC ou le PNS peuvent tout deux initier une connexion il peut se produire une collision TCP. Voir la section 3.1.3 pour la description de cette situation.

3.1.1. Initiateur de la liaison de contrôle (PAC ou PNS)

L.C. = Liaison de contrôle.

Ouverture de TCP / Envoi de «Établissement L.C.-Demande» +-----------------------+ +------------------------------------>| attente L.C. réponse | | +-----------------------+ | Collision / Voir 4.1.3 / Fermer TCP V V V Réception de | +-------------------------------+ | | «Établissement L.C.-Réponse» | | | | Version OK ^ V | V +-----------------+ Réception de «Établis- | +-----------------+ | Inactif | sement L.C.-Réponse» | | Connecté | +-----------------+ Version non OK| +-----------------+ ^ | V Déconnexion locale | Réception de | | / Envoi de | «Fermeture L.C.-Demande» | | «Fermeture L.C.-Demande» | / «Envoi Fermeture L.C.-Réponse» V V | Fermer TCP +---------------------------+ +-------------------------------------| Attente réponse fermeture | +---------------------------+

Inactif

L'initiateur de la liaison de contrôle essaie d'ouvrir une connexion TCP vers l'autre extrémité durant l'état inactif. Quand la connexion TCP est ouverte, l'initiateur envoie «  Établissement liaison de contrôle-Demande » et passe en état d'attente de réponse.

Attente L.C. Réponse

L'initiateur vérifie si une autre connexion TCP a été demandée depuis la même extrémité, et, dans ce cas gère la collision comme décrit en section 3.1.3.

Quand le message « Établissement liaison de contrôle-Réponse » est reçu la compatibilité de version est vérifiée. Si la version de la réponse est inférieure à la version envoyée dans la requête, l'ancienne (plus petite) version DOIT être utilisée. Si la version de la réponse est plus récente et supportée, l'initiateur passe en état « connecté ». Si la version de la réponse est plus récente mais non supportée un « Fermeture de liaison de contrôle-Demande » DOIT être envoyé à l'autre extrémité et l'initiateur passe en état d'attente de réponse de fermeture.

Connecté

Une connexion établie peut être fermée soit par une condition locale, soit par la réception de « Fermeture de liaison de contrôle-Demande ». Dans le cas d'un événement local, l'initiateur DOIT envoyer un « Fermeture de liaison de contrôle-Demande » et passer en état d'attente de réponse de fermeture.

Si l'initiateur reçoit un « Fermeture de liaison de contrôle-Demande », il DOIT envoyer un « Fermeture de liaison de contrôle-Réponse » et fermer la connexion TCP pour s'assurer que les dernières données ont bien étés transmises.

Attente réponse fermeture

Si un « Fermeture de liaison de contrôle-Réponse » est reçu, la connexion TCP DOIT être fermée et la liaison de contrôle devient inactive.

3.1.2. Destinataire de la liaison de contrôle (PAC ou PNS)

Réception de «Établissement L.C.-Demande» Version non OK / Envoi de «Établissement L.C.-Réponse» avec erreur +--------+ | | Réception de «Établissement L.C.-Demande» Version OK | | / Envoi de «Établissement L.C.-Réponse» | | +----------------------------------------+ ^ V ^ V +-----------------+ Réception de «Établissement +-----------------+ | Inactif | L.C.-Demande» | Connecté | +-----------------+ / envoi de «Fermeture- +-----------------+ ^ ^ L.C. Réponse» / Fermer TCP V V Déconnexion locale | +-------------------------------------+ | / envoi de «Fermeture L.C.- | | Demande» | V | +-------------------------+ +----------------------------------|Attente réponse fermeture| Réception de «Fermeture L.C.- +-------------------------+ Réponse / Fermer TCP

Inactif

Le destinataire de la liaison de contrôle attend une connexion TCP sur le port 1723. Quand il est informé de l'ouverture de la connexion TCP, il DOIT se préparer à recevoir des messages PPTP. Quand il reçoit « Établissement L.C.-Demande », il doit examiner le champ version. Si la version est plus récente que la version du destinataire et que celui-ci peut la supporter, il DOIT envoyer « Établissement L.C.-Réponse ». Si la version est plus récente et qu'il ne peut pas la supporter, il DOIT envoyer « Établissement L.C.-Réponse », fermer la connexion TCP et revenir à l'état inactif. Si la version du destinataire est identique ou plus récente, le destinataire DOIT envoyer « Établissement L.C.-Réponse » avec sa version et passer à l'état connecté.

Connecté

Une connexion établie peut être fermée soit par une condition locale, soit par la réception de « Fermeture de liaison de contrôle-Demande ». Dans le cas d'un événement local, l'initiateur DOIT envoyer un « Fermeture de liaison de contrôle-Demande » et passer en état d'attente de réponse de fermeture.

Si l'initiateur reçoit un « Fermeture de liaison de contrôle-Demande », il DOIT envoyer un « Fermeture de liaison de contrôle-Réponse » et fermer la connexion TCP pour s'assurer que les dernières données ont bien étés transmises.

Attente réponse fermeture

Si un « Fermeture de liaison de contrôle-Réponse » est reçu, la connexion TCP DOIT être fermée et la liaison de contrôle devient inactive.

3.1.3. Collision de la demande d'établissement de liaison de contrôle par l'initiateur

Un PAC et un PNS ne doivent avoir qu'une seule liaison de contrôle entre eux. Il est cependant possible pour un PNS et un PAC d'essayer simultanément d'établir une liaison de contrôle vers l'autre. Quand un « Établissement L.C.-Demande » arrive sur une connexion TCP alors qu'un autre « Établissement L.C.-Demande » a déjà été envoyé sur une autre connexion TCP vers la même extrémité, une collision s'est produite.

Le « gagnant » de cette compétition est l'extrémité avec la plus grande adresse IP (Comparée en tant que valeur non signée de 32 bits, l'adresse réseau en poids fort). Par exemple si les extrémités 192.33.45.17 et 192.33.45.89 rentrent en collision, la deuxième sera déclarée vainqueur. Le perdant DEVRA fermer immédiatement la connexion TCP qu'il a créé sans envoyer aucun autre message de contrôle PPTP et il répondra à la requête du gagnant avec un message « Établissement L.C.-Réponse ». Le gagnant attendra un message « Établissement L.C.-Réponse » sur la connexion TCP qu'il a créé et il attendra aussi une indication de fermeture de la connexion TCP ouverte par le perdant. Le gagnant ne DOIT PAS envoyer de messages sur la connexion créé par le perdant.

3.1.4. « Maintien de connexion » et temporisations

Une liaison de contrôle DOIT être fermée par fermeture de la connexion TCP sous-jacente dans les circonstances suivantes :

1. Si une liaison de contrôle n'est pas dans un état « connecté » (c.a.d. que « Établissement L.C.-Demande » et « Établissement L.C.-Réponse » n'ont pas été échangés) une liaison de contrôle DOIT être fermée au bout de 60 secondes d'attente par une extrémité d'un message « Établissement L.C.-Demande » ou « Établissement L.C.-Réponse ».

2. Si une extrémité de la liaison de contrôle est dans l'état « connecté » et n'a pas reçu de message de contrôle depuis 60 secondes, il DOIT envoyer un message « Écho-Demande ». Si un « Écho-Réponse » n'est pas reçu dans les 60 secondes qui suivent la demande, la liaison de contrôle DOIT être fermée.

3.2. États d'un appel

3.2.1. Considérations sur les temporisations

Du fait que la signalisation téléphonique fonctionne en temps réel, le PNS et le PAC doivent tout deux être implémentés avec une architecture multi-tâche de sorte que les messages relatifs à différents appels ne soient pas bloqués dans des files d'attente. Le délai de transfert entre PAC et PNS ne DOIT PAS excéder une seconde. Les diagrammes d'état d'appel et de connexion n'indiquent pas les exceptions provoquées par les temporisations. Le principe implicite est que puisque la liaison de contrôle reposant sur TCP est contrôlée par des « maintien de connexion » il est moins nécessaire de maintenir des chronogrammes stricts pour les messages de contrôle d'appel.

La durée pour l'établissement d'appels sortants internationaux, incluant l'apprentissage du modem et les séquences de négociations, peut dépasser une minute, aussi l'utilisation de temporisations courtes est-elle déconseillée.

Si aucun changement d'état n'intervient avant une minute (Excepté pour les connexions inactives ou en état « connecté »), l'intégrité de fonctionnement du protocole entre les extrémités est suspecte et la liaison de contrôle DOIT être entièrement fermée et redémarrée. Tous les identificateurs d'appels sont réinitialisés lorsque la liaison de contrôle démarre. Cela devrait aussi aider à éviter que des appels payants ne soient perdus et jamais stoppés.

3.2.2. Valeur des identificateurs d'appel

Chaque extrémité assigne un identificateur d'appel à chaque session utilisateur qu'elle demande ou accepte. Cet identificateur d'appel DOIT être unique pour son tunnel entre le PNS et le PAC. Les tunnels vers d'autres extrémités peuvent utiliser le même identificateur d'appel aussi la réception d'un paquet d'un tunnel nécessite d'associer une session utilisateur à un tunnel particulier et à un identificateur d'appel. Il est suggéré que le nombre de valeur d'identificateur d'appel potentiel pour chaque tunnel soit au moins le double du nombre maximum d'appels attendus sur un tunnel donné.

Une session est définie par le triplet : PAC – PNS – Identificateur d'appel.

3.2.3. Appels entrants

Un message « Appel entrant-Demande » est généré par le PAC lorsqu'une ligne de téléphone associée sonne. Le PAC choisi un identificateur d'appel et un numéro de série et indique le type d'appel. Les modems doivent toujours indiquer un type analogique. Les appels par réseau numérique doivent indiquer un type numérique quand il n'y a pas de restriction de service ou que l'adaptation de débit est utilisée et un type analogique quand il s'agit d'un modem digital. Le numéro d'appelant, le numéro composé et une sous-adresse peuvent être inclus dans le message s'il sont disponibles sur le réseau téléphonique.

Après que le PAC ait envoyé le message « Appel entrant-Demande », il attend une réponse du PNS mais il ne répond pas à l'appel téléphonique. Le PNS peut choisir de ne pas accepter l'appel si :

- Il n'y a plus de ressources pour supporter une nouvelle session.

- Le numéro d'appelant, le numéro composé ou la sous-adresse n'appartiennent pas à un utilisateur autorisé.

- Le type d'appel n'est pas autorisé ou supporté.

Si le PNS choisi d'accepter l'appel, il répond avec un message « Appel entrant-Réponse » qui indique aussi les tailles de la fenêtre (Voir section 4.2). Quand le PAC reçoit la réponse, il tente de répondre en s'assurant que le correspondant n'a pas raccroché. Un message de connexion final envoyé du PAC au PNS indique à la fois au PAC et au PNS qu'ils doivent passer en état « connecté ».

Quand le correspondant raccroche, l'appel est normalement stoppé et le PAC envoie un message « Appel terminé-Notification ». Si le PNS souhaite stopper l'appel, il envoie un message « Fin d'appel-Demande » et attend le message « Appel terminé-Notification ».

3.2.3.1. PAC États des appels entrants

Sonnerie/Envoie de «Appel entrant-Demande» +-----------------+ +----------------------------------------->| Attente réponse | | +-----------------+ | Réception de «Appel entrant-Réponse» V V V | Non accepté | | | Réception de «Appel entrant-Réponse» | +--------------------------------+ | | Acceptation de l'appel | | +------------------------------+ | Envoi de «Appel entrant-Connecté» | | | Avorté/Envoi de | ^ V V «Appel terminé-Notification» V +-----------------+ +-----------------+ | Inactif |<--------------------------------------| Connecté | +-----------------+ Réception de «Appel terminé-Demande» +-----------------+ ou appel perdu ou déconnexion locale /Envoi de «Appel terminé-Notification»

Les états associés du PAC pour les appels entrants sont :

Inactif

Le PAC détecte les appels entrants sur l'une de ses interfaces téléphoniques. C'est à dire qu'une ligne analogique sonne ou que l'interface numérique à détecté un message Q.931 « SETUP ». Le PAC envoie un message « Appel entrant-Demande » et se place en état d'attente de réponse.

Attente réponse

Le PAC reçoit un message « Appel entrant-Réponse » indiquant le refus de l'appel (Erreur générale ou non-acceptation) et retourne en état inactif. Si la réponse indique que l'appel est accepté, le PAC envoie le message « Appel entrant-Connecté » et passe en état « Connecté ».

Connecté

Des données sont échangées dans le tunnel. L'appel peut se terminer par :

- Un événement sur la liaison téléphonique. Le PAC envoie le message « Appel terminé-Notification »

- Réception du message « Appel terminé-Demande ». Le PAC envoie le message « Appel terminé-Notification »

- Une raison locale. Le PAC envoie le message « Appel terminé-Notification »

3.2.3.2. PNS États des appels entrants

Réception de «Appel entrant-Demande» /Envoie de «Appel entrant-Réponse» +-------------------+ Non accepté si erreur | Attente-Connexion | +-----+ +-------------------+ | | Réception de «Appel entrant-Demande» ^ V V | | /Envoie de «Appel entrant-Réponse» OK | | | Réception de «Appel | | +-----------------------------------+ | | entrant-Connecté» ^ V ^ V---------------------------------+ V +-----------------+ Réception de «Appel terminé +-----------------+ | Inactif | -Notification» +--| Connecté | +-----------------+ | +-----------------+ ^ ^ | V Arrêt local | +----------------------------+ | /Envoi de «Appel terminé | Réception de «Appel terminé | -Demande» | -Notification» V | +---------------------+ +--------------------------------------| Attente-Déconnexion | Réception de «Appel terminé +---------------------+ -Notification»

Les états associés du PNS pour les appels entrants sont :

Inactif

Un message « Appel entrant-Demande » est reçu. Si la demande n'est pas acceptable, un message « Appel entrant-Réponse » est retourné au PAC et le PNS revient en état inactif. Si la demande est acceptable, un message « Appel entrant-Réponse » indiquant l'acceptation dans le code résultat. La session passe en état « Attente-Connexion ».

Attente-Connexion

Si le PAC prend l'appel, il envoie un message « Appel entrant-Connecté » au PNS qui passe en état « Connecté ». Le PAC peut envoyer, un message « Appel terminé-Notification » pour indiquer que l'appel ne peut pas être établi. Cela peut arriver, par exemple, si un utilisateur appelle accidentellement le PAC par un appel vocal provoquant une erreur de négociation sur le modem appelé.

Connecté

La session se termine soit par la réception du message « Appel terminé-Notification » du PAC soit part l'envoi du message « Appel terminé-Demande ». Dès que le message « Appel terminé-Demande » a été envoyé, la session passe en état « Attente-Déconnexion ».

Attente-Déconnexion

Dès que le message « Appel terminé-Notification » est reçu, la session revient en état inactif.

3.2.4. Appels sortants

Les messages d'appels sortants sont initiés par un PNS et ordonnent au PAC d'effectuer un appel sur une interface téléphonique. Il n'y a que deux messages pour les appels sortants : « Appel sortant-Demande » et « Appel sortant-Réponse ». Le PNS envoie « Appel sortant-Demande » en spécifiant le numéro appelé, la sous-adresse, le débit et les paramètres de fenêtre. Le PAC DOIT répondre à « Appel sortant-Demande » par le message « Appel sortant-Réponse » dès que l'appel est établi avec succès. L'appel peut avorter pour des raisons telles que : pas d'interface téléphonique disponible, correspondant occupé ou ne répondant pas, pas de tonalité sur la ligne choisie pour l'appel.

3.2.4.1. PAC États des appels sortants

Réception de «Appel sortant-Demande» en erreur /Envoi de «Appel sortant-Réponse» avec erreur |--------+ | | Réception de «Appel sortant-Demande» sans erreur | | /Décrochage; Numérotation | | +-----------------------------------------------+ ^ V ^ V +-----------------+ Appel incomplet +-----------------+ | Inactif | /Envoi de «Appel sortant | Attente réponse | +-----------------+ -Réponse» avec erreur +-----------------+ ^ ^ ou réception de «Appel terminé-Demande» V V Réponse téléphonique | | /Envoi de «Appel terminé-Notification» | | / Envoi de «Appel sortant | +----------------------------------------------+ | -Réponse» | V | +-----------------+ +--------------------------------------------| Connecté | Réception de «Appel terminé-Demande +-----------------+ ou interruption locale ou déconnexion téléphonique /Raccrochage et envoi de «Appel terminé-Notification»

Les états associés du PAC pour les appels sortants sont :

Inactif

Réception de « Appel sortant-Demande ». S'il est reçu en erreur, répondre avec un « Appel sortant-Réponse » en positionnant la condition d'erreur. Sinon allouer une ligne pour numéroter. Réaliser l'appel, attendre la connexion et passer en état « Attente réponse ».

Attente réponse

Si l'appel est incomplet, envoyer un « Appel sortant-Réponse » avec un code erreur non nul. Si la temporisation expire sur un appel sortant, renvoyer un « Appel sortant-Réponse » avec un code erreur non nul. Si la connexion au réseau commuté est établie, envoyer un « Appel sortant-Réponse » indiquant le succès.

Connecté

Si un « Appel terminé-Demande » est reçu, la ligne téléphonique DOIT être libérée par un mécanisme approprié et un message « Appel terminé-Notification » DOIT être envoyé au PNS Si l'appel est stoppé par le client ou par l'interface téléphonique, un message « Appel terminé-Notification » DOIT être envoyé au PNS.

3.2.4.2. PNS États des appels sortants

Indication d'ouverture Avorté/Envoi de /Envoi de «Appel sortant «Appel terminé-Demande» -Demande» +-----------------+ +-------------------------------->| Attente-Réponse |------------+ | +-----------------+ | | Réception de «Appel sortant V V Réception de «Appel | | -Réponse» avec erreur | | sortant-Réponse» | | +-------------------------------+ | sans erreur | ^ V V | +-----------------+ +-----------------+ | | Inactif |<-----------------------------| Connecté | | +-----------------+ Réception de «Appel terminé +-----------------+ | ^ -Notification» V Interruption locale | | | /Envoi de «Appel | | | terminé-Demande» | | Réception de «Appel terminé V | | -Notification» +---------------------+ | +---------------------------------| Attente-Déconnexion |<-------+ +---------------------+

Les états associés du PNS pour les appels sortants sont :

Inactif

Un message « Appel sortant-Demande » est envoyé au PAC et la session passe en état « Attente-Réponse ».

Attente-Réponse

Un message « Appel sortant-Réponse » est reçu qui indique une erreur. La session retourne à l'état inactif. Il n'y a pas d'appel téléphonique actif. Si la réponse n'indique pas d'erreur l'appel téléphonique est établi et la session passe en état « Connecté ».

Connecté

Si un « Appel terminé-Demande » est reçu, l'appel téléphonique s'est terminé pour la raison indiquée dans les codes résultat et raison. La session revient à l'état inactif. Si le PNS choisi de terminer la session, il envoi un « Appel terminé-Demande » au PAC et passe en état « Attente-Déconnexion ».

Attente-Déconnexion

Le PAC attend la confirmation de la déconnexion de la session. Quand le PNS reçoit le message « Appel terminé-Notification », la session passe en état inactif.

4. Fonctionnement du protocole de tunnel

Les données utilisateurs transportées par le protocole PPTP sont des paquets PPP. Les paquets PPP sont transportés entre le PAC et le PNS encapsulés dans des paquets GRE qui sont à leur tour transportés par IP. Les paquets PPP encapsulés sont essentiellement des paquets de données PPP plutôt que des trames spécifiques au support. Il n'y a pas d'inclusion de drapeaux HDLC, de bit, de caractères de contrôle ou de caractères d'échappement. Il n'y a pas de CRCs envoyées dans le tunnel. Les paquets IP transmis dans le tunnel entre le PAC et le PNS ont la structure générale suivante :

4.1. En-tête GRE étendu

L'entête GRE utilisé par PPTP est légèrement étendue comme indiquée dans les spécifications du protocole GRE [1, 2]. La principale différence inclus la définition d'un nouveau champ de numéro d'acquittement utilisé pour déterminer si un paquet GRE donné ou un ensemble de paquets est arrivé à l'autre bout du tunnel. Cette possibilité d'acquittement n'est pas utilisée en association avec une quelconque retransmission des paquets de données utilisateur. Elle est plutôt utilisé pour déterminer le débit des paquets de données utilisateur au travers du tunnel pour une session donnée. Le format de l'entête GRE étendue est le suivant :

C

(Bit 0) Présence d'une somme de contrôle. Positionné à zéro (0).

R

(Bit 1) Présence du routage. Positionné à zéro (0).

K

(Bit 2) Présence de la clé. Positionné à un (1).

S

(Bit 3) Présence du numéro de séquence. Positionné à un (1) si une charge utile (données) est présente. Positionné à zéro (0) si la charge utile n'est pas présente (Ce paquet GRE est seulement un acquittement).

s

(Bit 4) Présence d'une source stricte. Positionné à zéro (0).

Recur.

(Bits 5-7) Contrôle de récursion. Positionné à zéro (0).

A

(Bit 8) Présence du numéro de séquence d'acquittement. Positionné à un (1) si le paquet contient un numéro d'acquittement à utiliser pour l'acquittement des données précédemment transmises.

Drapeaux

(Bits 9-12) Doit être positionné à zéro (0).

Ver

(Bits 13-15) Doit contenir 1 (GRE étendu).

Type de protocole

Positionné à la valeur hexadécimale 880B [8].

Clé

L'utilisation du champ 'Clé' est fonction de l'implémentation. PPTP l'utilise de la manière suivante :

- Les deux octets de poids forts de la clé : longueur de la charge utile, non compris l'en-tête GRE.

- Les deux octets de poids faibles de la clé : contient l'identifiant d'appel de la session à laquelle appartient ce paquet.

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 positionné à un (1).

Numéro d'acquittement

Contient le numéro de séquence du paquet GRE de plus grand numéro reçu part l'extrémité émettrice de cette session utilisateur. Présent si le bit A (Bit 8) est positionné à un (1).

La charge utile contient un paquet de données PPP sans aucun élément spécifique au support.

Les numéros de séquence inclus correspondent à l'ordre des paquets.

Le numéro de séquence pour chaque session utilisateur est remis à zéro en début de session. Chaque paquet d'une session utilisateur donnée et envoyé avec une charge utile (Et qui a le bit S (Bit 3) positionné à un) se voit assigné le numéro de séquence suivant consécutif de cette session.

Ce protocole permet aux acquittements d'être transporté avec les données et le rend plus efficace, ce qui nécessite moins de tampons de stockage des paquets.

4.2. Protocole de « fenêtre coulissante »

Le protocole de fenêtre coulissante utilisé pour les données PPTP sert à chaque extrémité de l'échange à contrôler le flux. Le protocole GRE étendu permet aux acquittements d'être greffés sur les paquets de données. Les acquittements peuvent aussi être envoyés séparément des paquets de données. L'usage principal du protocole de fenêtre coulissante est le contrôle de flux. Les retransmissions ne sont pas faites par l'extrémité du tunnel.

4.2.1. Taille initiale de la fenêtre

Bien que chaque extrémité ait indiqué la taille maximum de sa fenêtre de réception, il est recommandé d'avoir une approche prudente quand commence le transfert des données. La taille initiale de la fenêtre de l'émetteur est fixée à la moitié de la taille maximum requise par le récepteur, avec un minimum d'un paquet. L'émetteur arrête d'envoyer des paquets quand le nombre de paquet en attente d'acquittement est égal à la taille actuelle de la fenêtre. Quand le récepteur absorbe avec succès chaque fenêtre, la taille de la fenêtre de l'émetteur est incrémentée d'un paquet à la fois jusqu'à atteindre le maximum. Cette méthode évite au système d'inonder un réseau déjà congestionné parce qu'aucun historique n'a été établi.

4.2.2. Rétrécissement de la fenêtre

Quand un dépassement de délai se produit sur un paquet, l'émetteur réduit la taille de la fenêtre de transmission de la moitié de sa valeur. Les fractions sont arrondies par excès et la taille minimum de la fenêtre est de un.

4.2.3. Élargissement de la fenêtre

A chaque transmission réussie de l'ensemble des paquets d'une fenêtre sans dépassement de délai, la taille de la fenêtre d'émission est incrémentée d'un paquet à la fois jusqu'à atteindre la taille maximum de fenêtre qui a été fixée par l'autre extrémité lors de la connexion. Comme indiqué plus tôt, aucune retransmission n'est faite sur un dépassement de délai. Après un dépassement de délai, la transmission de la fenêtre reprend avec une taille de fenêtre de transmission moitié de celle qu'elle avait lorsque le dépassement s'est produit; et augmentant de un chaque fois que la fenêtre de transmission est remplie de paquets qui ont tous étés acquitté sans dépassement de délai.

4.2.4. Débordement de la fenêtre

Quand une fenêtre de réception déborde avec trop de paquets entrants, les paquets en excès sont rejetés. Cette situation ne doit pas se produire si les procédures de fenêtre coulissante sont correctement suivies par l'émetteur et le récepteur. Il est admis que, du coté de l'émetteur, les paquets sont stockés pour transmission et ne sont plus acceptés de la source de paquet quand le tampon de transmission se remplit.

4.2.5. Acquittement de paquets multiples

Une fonctionnalité du protocole de fenêtre coulissante de PPTP est de permettre l'acquittement de plusieurs paquets avec un acquittement unique. Tous les paquets émis avec un numéro de séquence plus petit ou égal au numéro d'acquittement sont considérés comme acquittés. Les calculs de délai de dépassement sont basés sur le temps de transmission du paquet correspondant au plus grand numéro de séquence acquiescé.

Les calculs d'adaptation du délai de dépassement ne sont faits que quand un acquittement est reçu. Quand des acquittements multi-paquets sont utilisés, la charge de l'algorithme d'adaptation du délai de dépassement est réduite. Le PAC n'est pas obligé de transmettre des acquittements multi-paquets; il peut à la place acquitter individuellement chaque paquet quand il est délivré au client PPP.

4.3. Paquets hors séquence

Occasionnellement des paquets perdent leur ordonnancement à travers un réseau complexe. Disons par exemple qu'un PNS envoie les paquets 0 à 5 à un PAC. En raison des redirections dans le réseau, le paquet 4 arrive au PAC avant le paquet 3. Le PAC acquitte le paquet 4, et peut considérer que le paquet 3 est perdu. Cet acquittement garanti la fenêtre au delà du paquet 4.

Quand le PAC reçoit le paquet 3, il ne DOIT PAS tenter de le transmettre au client PPP correspondant. Le faire pourrait conduire à des problèmes du fait que le fonctionnement du protocole PPP est basé sur une réception des paquets en séquence. PPP va lui-même s'occuper de la perte des paquets, mais pas du ré-ordonnancement. Les paquets hors séquence entre le PNS et le PAC DOIVENT être discrètement rejetés, ou peuvent être ré-ordonner par le récepteur. Quand le paquet 5 arrive, il est acquiescé par le PAC puisqu'il a un numéro de séquence plus grand que 4, qui était le dernier plus grand numéro acquiescé par le PAC. Il ne doit jamais se produire que des paquets aient des numéros de séquence dupliqués puisque le PAC et le PNS ne retransmettent jamais de paquets GRE. Une implémentation solide devra discrètement rejeter les paquets GRE dupliqués s'ils adviennent.

4.4. Temporisation d'acquittement

PPTP utilise des fenêtres coulissantes et des temporisations pour procurer à la fois un contrôle de flux des sessions utilisateur au travers du réseau et une optimisation des tampons de données conservant les canaux de données PAC-PNS pleins sans provoquer de débordement du tampon de réception. Une temporisation est nécessaire à PPTP pour repartir depuis les données perdues ou les paquets acquiescés. L'implémentation exacte de la temporisation est spécifique au fabriquant. Il est suggéré d'implémenter une temporisation évolutive avec réaction aux encombrements. Le mécanisme de temporisation proposé ici a les caractéristiques suivantes :

Temporisations indépendantes pour chaque session. Un système (PAC ou PNS) devra entretenir et calculer les temporisations de chaque session active.

Une temporisation maximum, ajustable par administrateur, unique pour chaque système.

Un mécanisme de temporisation évolutive qui compense les changements de débits. Pour réduire la charge du traitement des paquets, le fabriquant peut choisir de ne pas recalculer la temporisation à chaque acquittement reçu. Le résultat de cette réduction de charge est que la temporisation ne répondra pas aussi rapidement aux changements du réseau.

Réaction de la temporisation sur dépassement de délai pour réduire les encombrements. La correction de temporisation est limitée par la valeur configurable de temporisation maximum. La correction de temporisation se fait à chaque fois qu'un dépassement de temporisation se produit.

En général, ce mécanisme à le comportement souhaité consistant à rapidement réagir sur un dépassement de temporisation et à réduire lentement la temporisation lorsque les paquets sont transmis sans dépassement de délai.

Quelques définitions :

- Durée de traitement des paquets (PPD), c'est le temps total demandé par chaque extrémité pour traiter la quantité maximum de données contenu dans le tampon de réception de la fenêtre coulissante. Le PPD est la valeur échangée entre le PAC et le PNS lors de l'établissement de l'appel. Pour le PNS, ce nombre doit être petit. Pour le PAC qui effectue des connections par modem, ce nombre peut être significatif.

- L'échantillon est la durée réelle d'acquittement d'un paquet. L'échantillon est mesuré et non calculé.

- Durée d'aller-retour (RTT), c'est la durée estimée pour recevoir l'acquittement d'un paquet donné émis. Sur un réseau local, cette durée sera minimale (voir nulle). Sur l'internet, cette durée peut être substantielle et peut fortement varier. La RTT est évolutive : elle s'ajustera pour inclure la PPD et tous les changements dans le réseau qui influent sur la durée entre l'envoi d'un paquet et la réception de son acquittement.

- Temporisation évolutive (ATO), c'est le temps qui doit s'écouler avant qu'un acquittement soit considéré comme perdu. Après un dépassement de temporisation, la fenêtre coulissante est rétrécie et l'ATO est corrigée.

Le paramètre PPD est un mot de 16 bits échangé lors de la phase de contrôle de l'appel qui représente des dixièmes de seconde (64 veut dire 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 de la PPD est calculé dépend de l'implémentation et elle n'est pas nécessairement variable (des temporisations statiques sont permises). La PPD doit être échangée lors de la séquence de connexion de l'appel, même si elle reste constante dans l'implémentation. Une possibilité de calcul de la PPD est :

PPD' = ((PPP_MAX_DATA_MTU – En-Tête) * TailleFenêtre * 8) / DébitConnexion

PPD = PPD' + PACDélaiSupplémentaire

L'en-tête est la taille des en-têtes IP et GRE, qui est de 36. Le MTU est le MTU global pour le lien réseau entre le PAC et le PNS. La taille de fenêtre représente le nombre de paquets dans la fenêtre coulissante et dépend de l'implémentation. Le temps d'attente du réseau peut être employé pour sélectionner une taille de fenêtre suffisante pour maintenir le canal de la session correspondante plein. La constante 8 convertit les octets en bits (considérant que le débit de connexion est en bits par seconde). Si le débit de connexion est en octets, omettre le 8. PACDélaiSupplémentaire n'est pas exigé mais peut être utilisé pour tenir compte du temps de traitement total du PAC.

La valeur de la PPD sert à initialiser l'algorithme évolutif avec la valeur initiale RTT[n-1].

4.4.1. Calcul évolutif des temporisations d'acquittement

Nous devrons encore décider du temps à accorder pour le retour des acquittements. Si la temporisation est trop longue nous devrons peut-être attendre longtemps les paquets perdus sans nécessité. Si la temporisation est trop courte, nous dépasserons peut-être le délai juste avant que l'acquittement n'arrive. La temporisation d'acquittement doit être raisonnable et réactive aux changements de condition du réseau.

L'algorithme évolutif suggéré, détaillé ci-dessous, est basé sur l'implémentation de TCP (1989) expliquée en [11]. 'n' veut dire cette itération du calcul et 'n-1' se réfère aux valeurs du dernier calcul.

DIFF[n] = ECHANTILLON[n] - RTT[n-1]

DEV[n] = DEV[n-1] + (bêta * (|DIFF[n]| - DEV[n-1]))

RTT[n] = RTT[n-1] + (alpha * DIFF[n])

ATO[n] = MAX (MinTempo, MIN (RTT[n] + (chi * DEV[n]), MaxTempo))

DIFF représente la différence entre la dernière durée d'aller-retour estimée et la durée mesurée. DIFF est calculé à chaque itération.

DEV est la correction estimée. Elle approche la correction standard. DEV est calculé à chaque itération et est conservé pour utilisation dans l'itération suivante. Initialement, elle est à 0.

RTT est la durée d'aller-retour estimée pour un paquet moyen. RTT est calculé à chaque itération et est conservé pour utilisation dans l'itération suivante. Elle est initialisée avec PPD.

ATO est la temporisation évolutive pour le prochain paquet à transmettre. ATO est calculé à chaque itération. Ses valeurs sont limitées par la fonction MIN au maximum de la valeur configurée de MaxTempo.

Alpha est le facteur de moyenne et est typiquement de 1/8 (0,125).

Bêta est le facteur de correction et est typiquement de 1/4 (0,250).

Chi est le facteur pour la temporisation et est typiquement de 4.

Pour éliminer les divisions sur les facteurs réel, l'ensemble des équations peut-être mis à l'échelle. Avec les facteurs suggérés, il faut multiplier par 8 pour éliminer toute les divisions. Pour simplifier les calculs, tous les facteurs sont des puissances de deux, ainsi des opérations de décalage peuvent être utilisées à la place des multiplications ou divisions.

4.4.2. Contrôle des encombrements: Réglage des temporisations

Cette section décrit comment le calcul de l'ATO est modifié dans le cas ou des dépassements de temporisations se produisent. Quand un dépassement se produit, la valeur de temporisation doit rapidement augmenter. Bien que les paquets GRE ne soient pas retransmis quand un dépassement se produit, la temporisation doit être relevée à sa limite maximum. Pour compenser les changements de temps de propagation du réseau, une stratégie doit être employée pour augmenter la temporisation quand elle expire (Notez qu'en plus d'augmenter la temporisation, nous rétrécissons aussi la taille de la fenêtre comme décrit dans la section suivante). Pour un intervalle pendant lequel un dépassement de temporisation se produit, la nouvelle ATO est calculée comme ceci :

RTT[n] = delta * RTT[n-1]

DEV[n] = DEV[n-1]

ATO[n] = MAX (MinTempo, MIN (RTT[n] + (chi * DEV[n]), MaxTempo))

Dans ce calcul de l'ATO, seulement deux valeurs contribuant à l'ATO sont calculées et stockées pour l'itération suivante. RTT est factorisé par delta et DEV n'est pas modifié. DIFF n'est pas propagé et n'est pas utilisé dans ce cas. Une valeur de 2 pour delta, le facteur de temporisation pour RTT, est suggérée.

5. Considérations de sécurité

La sécurité des données utilisateur transmise par la connexion PPP sous tunnel est assurée par PPP et son authentification.

Du fait que les messages de la liaison de contrôle de PPTP ne sont jamais authentifiés et que leur intégrité n'est pas protégée, il est possible pour un attaquant de détourner la connexion TCP sous-jacente. Il est aussi possible de fabriquer de faux messages de la liaison de contrôle et d'altérer sans détection les messages d'origine pendant leur transit.

Les paquets GRE formant le tunnel en lui-même ne sont pas protégés par cryptage. Du fait que les négociations PPP sont transportées dans le tunnel, il est possible pour un attaquant de modifier ces négociations.

A moins que la charge utile de PPP ne soit protégée par cryptage, elle peut être capturée et lue ou modifiée.

6. Adresses des auteurs

Kory Hamzeh
Ascend Communications
1275 Harbor Bay Parkway
Alameda, CA 94502
émail: kory@ascend.com

Gurdeep Singh Pall
Microsoft Corporation
Redmond, WA
émail: gurdeep@microsoft.com

William Verthein
U.S. Robotics/3Com

Jeff Taarud
Copper Mountain Networks

W. Andrew Little
ECI Telematics

Glen Zorn
Microsoft Corporation
Redmond, WA
émail: glennz@microsoft.com

7. Références

[1] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 1701, Octobre 1994.

[2] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic Routing Encapsulation (GRE) over IPv4 Networks", RFC 1702, Octobre 1994.

[3] Lloyd, B. and W. Simpson, "PPP Authentication Protocols", RFC1334, Octobre 1992.

[4] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, Septembre 1981.

[5] Postel, J., "User Data Protocol", STD 6, RFC 768, Août 1980.

[6] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, Octobre 1994. Voir aussi : http://www.iana.org/numbers.html

[7] Simpson, W., editor, "The Point-to-Point Protocol(PPP)", STD51, RFC 1661, Juillet 1994.

[8] Ethertype for PPP, Reserved with Xerox Corporation.

[9] Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, Août 1996.

[10] Blunk, L. and J Vollbrecht, "PPP Extensible Authentication Protocol (EAP)", RFC 2284, Mars 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, Mars 1997.

8. Copyright intégral

Copyright © The Internet Society (1999). Tous Droits Réservés.

Le document anglais original et les traductions de celui-ci peuvent être copiés et fournis à d'autres, et les trav