Résumé

  • Le RFC 831, publié comme proposition de discussion en 1982 et non comme norme, cherchait à maintenir un accès logiciel à la partie européenne de SATNET pendant une partition.
  • Son « Header Munger » M avançait une route source et réécrivait les deux sens d’un échange, tout en restant un hôte qui n’émettait aucune mise à jour de routage. Cette abstention empêchait le secours d’aspirer le trafic ordinaire.
  • Lorsque l’équipement ancien ne savait pas inverser une route source, M apprenait une correspondance de retour qualifiée de « soft state ». Le texte ne définissait ni expiration, ni authentification, ni nettoyage ; la correspondance ambiguë ne permettait qu’un hôte américain par cible SATNET.

Le problème commençait par un retour impossible

Le schéma normal partait d’un hôte de contrôle américain H. Il gagnait la passerelle B de BBN, le SIMP S1, SATNET, le SIMP S2 puis la passerelle G de l’UCL. Une partition rendait S2, G et le contrôleur d’accès de l’UCL injoignables depuis les passerelles américaines. Un datagramme normalement adressé finissait rejeté, avec éventuellement un message ICMP Unreachable.

L’échec n’était pas seulement américain. Depuis le Royaume-Uni, H devenait lui aussi injoignable. Trouver un passage pour la demande ne suffisait donc pas : il fallait construire un retour qui ne dépende pas précisément de la partie brisée de SATNET.

C’est à ce problème que Robert Braden consacra le RFC 831 en décembre 1982. Le document voulait concentrer une discussion ; il précisait ne pas être destiné à devenir une norme à ce stade. Rien ne permet d’en faire le compte rendu d’un déploiement ou d’une panne effectivement traitée.

Le détour envisagé reliait H à une passerelle VAN, puis à un tunnel IP sur VANNET, à un système de l’UCL, à UCLNET, à G et enfin à S2. Le code spécial pouvait résider dans H et/ou dans le système de l’UCL, mais pas dans G, S2 ou la passerelle VAN. Le projet préservait ainsi les équipements que la maintenance devait justement secourir.

Refuser une annonce faisait partie de la fonction

Pourquoi ne pas transformer l’extrémité U du tunnel en passerelle ? Parce que la passerelle VAN aurait pu découvrir, à travers U, une route générale vers UCLNET. Elle aurait alors envoyé dans le tunnel VANNET non seulement le trafic de maintenance, mais aussi des flux ordinaires destinés à l’UCL ou à RSRE. L’issue de secours serait devenue un raccourci de production.

Le RFC 831 introduisait donc M, le « Header Munger ». M possédait deux attaches : M2 du côté VANNET et M1 du côté UCLNET. Il devait appliquer l’algorithme de route source d’une passerelle, tout en se comportant par ailleurs comme deux hôtes et sans émettre de mises à jour de routage.

Cette combinaison est le cœur du texte. Un algorithme de passerelle est une capacité d’exécution sur un paquet. Une annonce de route revendique une autorité beaucoup plus large : elle demande aux autres systèmes de remettre tout un ensemble de flux à l’annonceur. L’urgence justifiait la première capacité, pas la seconde.

On peut parler d’autorité négative : M était défini autant par ce qu’il devait s’abstenir de faire que par ses réécritures. Ne pas devenir visible comme transit protégeait le trafic sans rapport avec l’incident.

M2 et M1 formaient une charnière d’adresses

H savait atteindre M2. Il adressait donc la demande de maintenance vers ce côté de M. Le Munger remplaçait ensuite la source par M1 et la destination par S2, puis injectait le datagramme dans UCLNET. Aux yeux de G et de S2, les extrémités observées étaient à nouveau localement accessibles.

La réponse suivait l’autre moitié de la charnière. S2 envoyait vers M1 ; M réécrivait le paquet pour qu’il puisse repartir par VANNET et Internet vers H. Les deux transformations n’étaient pas redondantes. L’une compensait l’absence de chemin américain vers la cible, l’autre l’absence de chemin britannique vers l’origine.

La commodité avait un coût probatoire. Après la réécriture, le journal de S2 pouvait ne montrer que M1. En amont, un équipement pouvait ne voir que M2. La réception d’une réponse attestait qu’une chaîne particulière avait transporté l’échange ; elle ne nommait pas nécessairement l’opérateur humain et ne prouvait ni son autorisation ni l’application correcte d’une modification logicielle.

Le rapprochement avec la traduction d’adresses doit rester analytique. Le RFC 3022 décrivit bien plus tard les mappages statiques et dynamiques et le prix payé lorsque l’état du réseau remplace la signification de bout en bout de l’adresse IP. Ce parallèle éclaire M ; il ne transforme pas le RFC 831 en NAT et n’établit aucune filiation historique.

Le retour révélait trois modèles de mémoire

Une première solution associait à l’avance des adresses M1 et M2 à des couples de machines. Son comportement était déterministe, mais chaque couple américain–SATNET exigeait une préparation et une ressource d’adressage.

Une deuxième solution comptait sur la route source IP dans les deux sens. Le RFC 791 définissait les options Loose et Strict Source and Record Route. Le créateur du paquet inscrivait des étapes ; à chaque étape atteinte, l’adresse suivante devenait la destination et l’adresse de l’interface courante entrait dans l’enregistrement. Un destinataire capable d’inverser cet enregistrement pouvait répondre par les mêmes articulations.

G savait traiter la route source, mais S2 et le contrôleur d’accès n’étaient pas forcément capables d’en composer une en retour. La solution privilégiée était donc hybride. H fournissait le détour à l’aller. En traitant la demande, M apprenait la correspondance entre l’origine américaine et la cible SATNET. Une réponse ordinaire vers M1 pouvait ensuite être associée à H.

Le document appelait cette correspondance un « soft state ». Il faut résister à la tentation de compléter la formule avec les propriétés d’autres systèmes. Le RFC 831 ne donne aucun intervalle de rafraîchissement, minuteur d’expiration, ordre de suppression, comportement après redémarrage ou trace d’audit. Il ne spécifie pas davantage qui est autorisé à créer cet état.

La clé perdait aussi de l’information. Une seule machine américaine pouvait utiliser à la fois une cible SATNET donnée. Si deux sources partageaient la même cible, la réponse dépourvue de route source ne suffisait plus pour choisir son véritable destinataire. La limite exprime une ambiguïté architecturale, non un objectif de débit.

Le protocole inférieur présentait sa facture

VANNET reposait sur un service X.25 commuté. L’appelant payait. Dans le fonctionnement ordinaire, l’UCL ouvrait le tunnel depuis U ; pour M2, l’extrémité américaine devait lancer l’appel. La direction du tunnel distribuait donc à la fois le coût et la responsabilité de l’activation.

L’UCL ne disposait que d’une ligne PSS physique. Faire coexister U et M exigeait des sous-adresses X.25 différentes, et la passerelle VAN devait accepter des adresses X.121 de quatorze chiffres en plus du format à douze chiffres. Deux chiffres absents dans un équipement pouvaient rendre inopérante une architecture IP correctement raisonnée.

Ces faits ne sont pas une théorie générale du prix des réseaux. Ils rappellent que le plan de continuité doit inventorier les circuits, les initiateurs, les formats d’adresse et le compte débité. Une topologie logique ne passe pas d’appel toute seule.

Une opération d’hôte pouvait avoir des obligations de routeur

Le RFC 1122 autorisa plus tard un hôte à occuper une étape intermédiaire d’une route source, mais sous des règles comparables à celles d’une passerelle : durée de vie, erreurs ICMP et mise à jour des options devaient être correctes. Le transfert d’un paquet à destination non locale nécessitait un commutateur configurable, désactivé par défaut, ainsi que des filtres de politique.

Cette formulation confirme la séparation de RFC 831. Le logiciel pouvait rester celui d’un hôte, mais l’opération intermédiaire entraînait des conséquences de routage. Le nom donné à la machine n’effaçait ni le TTL, ni les erreurs, ni la politique.

L’évolution opérationnelle fut progressive. En 1995, le RFC 1812 exigeait encore que les routeurs prennent en charge la route source pour les paquets transférés et prévoyait un dispositif de rejet qui n’était pas activé par défaut. Ce constat décrit une époque ; il ne recommande pas sa configuration aujourd’hui.

Le RFC 6274 conclut ensuite que les risques — contournement de pare-feu, accès à des systèmes autrement injoignables, connexions furtives, découverte de topologie et épuisement de ressources — dépassaient l’intérêt diagnostique. Il préconisa le rejet par défaut. Le RFC 7126 nota que le filtrage généralisé avait rendu LSRR pratiquement inutilisable pour le dépannage et recommanda un contrôle documenté, propre à l’option, avec rejet par défaut.

La disponibilité d’une option dans une spécification n’oblige donc aucun opérateur indépendant à la transporter. Une porte de secours fondée sur la route source dépendait aussi du consentement opérationnel de chaque réseau traversé.

« Middlebox » n’est qu’une lecture postérieure

Le RFC 3234 qualifia plus tard de middlebox un intermédiaire qui transforme ou détourne un flux au-delà du routage IP ordinaire. M entre assez bien dans cette taxonomie : il changeait les adresses, conservait une correspondance et ajoutait des modes de panne et de configuration. Le RFC 831, lui, n’employait pas ce mot.

La catégorie décrit une action, pas une délégation. Elle ne dit pas qui peut ouvrir le passage, quelles cibles sont admises, combien de temps la mémoire survit ni qui doit la supprimer. Le terme « passerelle » serait encore moins précis, puisqu’il pourrait suggérer l’autorité de transit général que le projet refusait.

M était un hôte multirésident accomplissant, sur une sélection de trafic de maintenance, un travail de passerelle sans annoncer de route. La phrase paraît paradoxale ; elle est en réalité la définition exacte du périmètre.

Atteindre S2 ne donnait pas le droit de le modifier

Le RFC 831 ne spécifiait ni preuve d’identité, ni autorisation de cible, ni chiffrement, ni commande de maintenance, ni accusé de résultat. Sa « porte dérobée » désignait un chemin alternatif, pas la preuve d’une intrusion. Néanmoins, un chemin alternatif donne la capacité de franchir une frontière que la topologie ordinaire ne franchit plus.

Il faut donc séparer quatre constats : la demande a atteint l’entrée ; le principal a été identifié ; l’opération et la cible ont été autorisées ; l’application a confirmé le résultat. Une réponse réécrite contribue au premier constat. Elle ne peut tenir lieu des trois autres.

La leçon durable du RFC 831 est une discipline de retenue. La maintenance urgente n’autorisait pas à faire croire au routage qu’un nouveau transit général existait. Le code exceptionnel demeurait local, le chemin ordinaire restait inchangé et l’intermédiaire n’annonçait rien.

La porte restait une porte parce qu’elle ne prétendait pas être une route.