Résumé

  • RFC 3145 ajouta au message de fin d’appel L2TP un motif propre à PPP, tout en lui interdisant d’être obligatoire ou d’agir sur le tunnel.
  • Le triplet code, protocole de contrôle et direction décrit le point de vue d’un pair ; il ne démontre ni la panne physique, ni la faute, ni la réception par l’utilisateur.
  • L’extension rendit l’enquête possible entre propriétaires distincts sans confondre registre de valeurs, canal protégé et vérité opérationnelle.

Deux exploitants, une fin de session, deux réalités

L2TP avait une qualité qui créait sa propre zone d’ombre. Le protocole pouvait transporter une session PPP entre un concentrateur d’accès, le LAC, et un serveur de réseau, le LNS, sans mêler son fonctionnement à tous les détails de PPP. Le tunnel restait donc gérable. Mais lorsqu’une session se terminait, le pair distant recevait un résultat L2TP sans nécessairement connaître le dernier état PPP.

Cette lacune était plus qu’un problème de confort lorsque LAC et LNS n’avaient pas le même propriétaire. L’un pouvait répondre au client, l’autre observer l’échec d’une négociation LCP, d’une authentification ou d’un protocole réseau. Chacun détenait une partie du récit et aucune convention interne ne suffisait à relier leurs journaux.

RFC 3145 proposa une pièce de jonction étroite. L’AVP PPP Disconnect Cause Code, Vendor ID zéro et type 46, n’était valable que dans Call-Disconnect-Notify. Sa valeur réunissait un code de déconnexion, le numéro du protocole de contrôle PPP, une direction et, éventuellement, un texte UTF-8.

Le document refusa toutefois le raccourci le plus séduisant. Cette AVP devait accompagner les Result Code et Error Code de L2TP, non les remplacer. La fin du contrôle L2TP et l’observation PPP demeuraient deux faits. Une base qui transforme les deux en un unique champ « cause » détruit la séparation avant même que l’enquête commence.

Une information que le destinataire pouvait ignorer

Le bit Mandatory devait être à zéro. Un pair qui ne connaissait pas l’extension pouvait continuer à traiter le message de fermeture. L’interopérabilité de la fonction principale ne dépendait donc pas du déploiement uniforme de l’explication. Cette asymétrie protégeait aussi le protocole contre une inflation du diagnostic : une information supplémentaire ne devenait pas une nouvelle condition d’exécution.

RFC 3145 précisait que l’AVP servait uniquement à l’information et à la journalisation. Elle ne devait modifier ni le tunnel ni la session PPP. La machine d’états décidait l’arrêt ; un hôte rapportait ce qu’il avait observé ; une procédure ultérieure pouvait en tirer une conclusion. Ces trois compétences ne passaient pas ensemble dans le paquet.

Le bit Hidden pouvait être activé, et RFC 3193 décrivit ensuite la protection de L2TP par IPsec. Une association protégée peut renforcer confidentialité, intégrité et identification du pair. Elle ne transforme pas l’analyse locale du pair en fait incontestable. Elle prouve mieux la provenance des octets que la causalité de l’incident.

« Local » ne voulait pas dire « coupable »

La direction zéro désignait une erreur globale, un la situation « au pair », deux la situation « en local ». Ces mots étaient relatifs à l’hôte qui fabriquait l’AVP. Dès qu’un agrégateur les renomme « client » et « fournisseur », ou « innocent » et « responsable », il ajoute un jugement absent du protocole.

La direction était pourtant indispensable. Pour une terminaison LCP normale, elle indiquait qui avait envoyé Terminate-Request. Pour un chiffrement ou un rappel obligatoire refusé, elle distinguait celui qui exigeait la fonction de celui qui la refusait. Pour les méthodes d’authentification, elle séparait les offres rejetées par le pair des demandes du pair non prises en charge localement. Refuser peut être une politique correcte ; envoyer la dernière requête ne résume pas les événements antérieurs.

Le numéro de protocole apportait une autre dimension. Les erreurs globales portaient zéro, les erreurs de lien identifiaient LCP, les erreurs d’authentification la méthode concernée, et les erreurs NCP le protocole réseau. Plusieurs AVP pouvaient représenter plusieurs échecs NCP. Si une seule était envoyée, elle devait viser l’échec le plus récent. « Le plus récent » organisait l’échantillon ; il ne déclarait pas les échecs précédents sans importance.

Le bon enregistrement n’est donc pas « code 16 ». Il est : tel pair, dans telle session et tel CDN, a rapporté tel code, pour tel protocole, dans telle direction, à telle heure et sous telle protection. Le nombre devient interprétable grâce à ses coordonnées, non grâce à son apparence officielle.

Le catalogue normalisait des observations

Les vingt et une valeurs initiales allaient de l’absence d’information à l’interdiction d’utiliser une adresse. Elles couvraient notamment la déconnexion administrative, la terminaison LCP normale, les temporisations, l’absence de paquets LCP reconnaissables, un possible bouclage signalé par Magic Number, l’expiration d’Echo Request, les incohérences multilink, le refus de rappel ou de chiffrement, les échecs d’authentification et l’absence de NCP utilisable.

Un vocabulaire commun permettait à deux équipements de nommer la même classe de symptôme. Il ne reconstituait pas la chaîne causale. Une expiration d’écho peut correspondre à de la perte, de la congestion, une route retour filtrée, un processus mort ou un pair inaccessible. Un échec d’authentification décrit un résultat protocolaire, pas l’identité civile d’un fautif.

Le RFC marqua même une limite de sécurité à la précision. Une extension future ne devait pas révéler que le nom d’authentification était correct mais que le mot de passe ne l’était pas. Une taxonomie trop fine devient un oracle pour l’attaquant. L’observabilité n’a pas pour seul coût le volume des journaux ; elle modifie ce qu’un tiers peut apprendre par essais répétés.

Le texte UTF-8 facultatif demandait la même prudence. Il pouvait être affiché ou enregistré, mais son encodage ne garantissait ni son exactitude, ni sa sûreté, ni son arrivée devant un lecteur. Le message original, sa traduction et le code structuré sont trois objets. Les fusionner empêche ensuite de savoir ce que le pair avait réellement déclaré.

La compatibilité n’accordait pas l’autorité

Une version de projet avait utilisé le Vendor ID 43 de 3Com. Le standard autorisa les récepteurs à accepter cette forme comme équivalente, tout en déconseillant de l’émettre. Il conserva ainsi la lecture d’anciens messages et fixa la forme future sous l’attribution IETF. L’IANA pouvait maintenir la signification des valeurs ; elle ne certifiait ni leur déploiement ni la justesse d’une occurrence.

Cette transition illustre une méthode plus générale. Un registre est une autorité de décodage. Le pair est l’auteur du constat. L’état PPP, les paquets et les alarmes fournissent la réalité opérationnelle. Une organisation qui confère au registre le pouvoir de valider le constat mélange les couches parce qu’elles partagent un numéro.

Aider la comptabilité sans la solder

L’abstract citait la comptabilité et le débogage. Le mot utile était « aider ». Les attributs d’accounting de tunnel RADIUS peuvent corréler une session, marquer son début, ses mises à jour et sa fin, et porter des compteurs. Le code PPP peut expliquer pourquoi un arrêt a été demandé. Il ne démontre pas que l’enregistrement Stop est arrivé, que les compteurs sont complets ou que la facture est juste.

Le diagnostic doit aussi rencontrer le plan de données. Un code d’expiration d’écho se compare aux compteurs, alarmes et tests de retour. Une erreur d’authentification se compare aux états sans répandre les secrets. Une terminaison normale se vérifie dans l’échange LCP. Le code désigne la bonne étagère de preuves ; il n’en remplit pas à lui seul le dossier.

L’interface utilisateur ajoute enfin sa propre étape. Générer une phrase à partir d’un code n’établit pas qu’elle a été livrée ni comprise. Une traduction qui efface la direction ou transforme « méthode non acceptable » en « mot de passe incorrect » dépasse le constat normalisé.

Le réel conservait un droit d’appel

La valeur durable de RFC 3145 ne réside pas dans les vingt et un libellés. Elle réside dans une discipline : standardiser un minimum transportable, conserver le point de vue qui l’a produit, puis autoriser le fonctionnement observé à contredire le symbole. Le code appartient à la couche du langage partagé ; le CDN est un acte ; l’état PPP et les paquets sont le fonctionnement ; l’accounting et l’expérience sont des conséquences.

Les plateformes contemporaines répètent souvent l’erreur que ce petit RFC évitait. Elles aspirent un champ reason, retirent le rapporteur et la direction, produisent une phrase agréable puis l’emploient comme cause globale d’incident. Un motif peut franchir le tunnel. Le pouvoir de décider de la réalité, lui, ne voyage pas dans l’AVP.

Sources