Résumé

  • Dans l'en-tête HYPERchannel étendu, l'émetteur pouvait poser SRC pour annoncer une adresse FROM utilisable en sens inverse ; chaque adaptateur intermédiaire pouvait retirer cette affirmation.
  • Si le bit arrivait encore posé, la garantie portait sur le retour vers le processus d'origine. La CRC, le choix du serveur de protocole, la sécurité physique et l'autorisation applicative restaient des preuves distinctes.

En février 1988, la RFC 1044 cherchait à rendre interopérables plusieurs pratiques d'IP sur les équipements HYPERchannel. Le texte devait stabiliser un format à adresses de 16 bits, introduire une extension à 32 bits, organiser les types de message et préparer une résolution d'adresses moins dépendante des fichiers locaux. Dans cette architecture, une adresse pouvait désigner un point de retour sans devenir pour autant le nom d'un acteur de confiance.

La symétrie précédait le bit

Le format de base contenait une adresse TO pour la livraison et une adresse FROM transportée jusqu'au destinataire. Le réseau n'utilisait pas FROM pour acheminer le message aller. Elle permettait de construire la réponse. Dans le cas général, l'inversion de TO, FROM et des masques de trunks correspondants ramenait le message vers son origine.

Cette symétrie rendait le support commode. Elle ne disait pas qu'un utilisateur précis avait composé la requête, qu'un compte était habilité, ni que le logiciel expéditeur était sain. Elle répondait à une question plus basse dans la pile : quelle adresse le support doit-il suivre dans l'autre sens ?

Une autre partie de TO, dite logique, choisissait le serveur de protocole final. Le champ de type pouvait influencer un traitement intermédiaire, mais ne pouvait pas déplacer la livraison finale vers un autre serveur une fois l'adresse complète enregistrée. La destination du processus et la classification en transit étaient donc déjà séparées.

SRC permettait au chemin de retirer une affirmation

L'en-tête de 32 bits ajoutait les indicateurs GNA, CRC et SRC. GNA annonçait le mode d'adressage global. CRC concernait la corruption des octets au cours du transport. SRC, développé comme Source FROM Address Correct, concernait l'aptitude de l'adresse de retour.

Le mécanisme ne reposait pas sur une certification accumulée. Le pilote émetteur posait le bit après avoir fourni, selon lui, l'adresse de l'interface réellement employée. Chaque adaptateur intermédiaire avait le droit de l'effacer si cette adresse ne pouvait pas servir de TO à un message envoyé en sens inverse vers l'origine.

Le destinataire ne recevait donc pas une série de signatures. Il voyait une affirmation initiale que le chemin n'avait pas invalidée. Un équipement défaillant ou hors du périmètre de confiance pouvait ne pas appliquer correctement la règle. À l'inverse, l'absence du bit ne révélait pas à elle seule une attaque : l'émetteur pouvait ne pas l'avoir posé, un équipement ancien pouvait l'ignorer, ou un adaptateur pouvait l'avoir retiré pour une raison légitime.

Cette forme négative de contrôle reste utile. Un bit effacé interdit de prétendre que la garantie forte a survécu. Mais un bit conservé ne crée pas la preuve des hypothèses physiques qui ont permis sa conservation.

Le mot « correcte » gardait une portée mesurable

La RFC 1044 définit l'adresse correcte dans un sens précis : si SRC reste posé, inverser TO et FROM doit remettre une réponse au processus qui a effectivement émis le message. Ce résultat est plus riche qu'une simple réception. Il attache la route inverse à un processus du système HYPERchannel.

Il reste plus étroit qu'une authentification. Un processus compromis peut posséder une adresse parfaitement réversible. Un poste installé au bon endroit peut envoyer une opération interdite. Une réponse peut revenir sans que l'effet demandé soit acceptable ou accompli. La réversibilité établit une destination pour le dialogue ; l'autorisation établit le droit de provoquer un effet.

Le texte évoque lui-même la condition permettant d'aller plus loin : une attention rigoureuse à la sécurité physique des adaptateurs et des liaisons intermédiaires. Dans un périmètre où le matériel, la configuration et les chemins sont sous garde identifiable, l'adresse FROM peut soutenir une politique locale. Cette garde est une prémisse externe. Le bit ne prouve pas tout seul que le périmètre existe.

La CRC ne répondait pas à la question de l'identité

La présence d'un indicateur CRC distinct empêche de confondre les dossiers. Des adaptateurs équipés pouvaient ajouter et vérifier une CRC de 32 bits afin de détecter une corruption du message à travers les réseaux et le matériel intermédiaires. Cette preuve concernait les octets.

SRC ne vérifiait pas ces octets. CRC ne vérifiait pas le chemin de retour. Aucun des deux ne nommait une personne, ne validait l'adresse IP interne et n'accordait un pouvoir à l'application. Un journal qui résumerait tous ces résultats par « source validée » détruirait l'information dont une enquête a besoin.

La RFC 791 décrit encore une autre couche : le datagramme IPv4 possède ses propres adresses, sa longueur totale, son champ de protocole et la somme de contrôle de son en-tête. Les coordonnées HYPERchannel enveloppent ce datagramme. La cohérence entre l'adresse IP et l'adresse physique peut renforcer un diagnostic ; deux valeurs cohérentes ne constituent toujours pas une identité autorisée.

Résoudre une adresse ne signifiait pas en connaître le maître

La RFC 1044 présente quatre étapes de résolution : troncature de l'adresse IP, table locale, serveur ARP central, puis ARP distribué lorsqu'un support de diffusion serait disponible. Elle reprend la structure générale de la RFC 826, capable de relier une adresse de protocole à une adresse de liaison.

Chaque étape produit une provenance différente. Une ligne de configuration a un auteur et une date. Un serveur central possède sa base et son domaine d'administration. Une réponse diffusée provient d'un échange local. La résolution indique quel en-tête utiliser ; elle ne prouve ni la fraîcheur de la donnée, ni le propriétaire légitime de la machine, ni le droit du service à accepter une commande.

Une mauvaise correspondance peut même rester parfaitement réversible. Le bit SRC confirmerait alors que la réponse revient au processus indiqué par cette correspondance, non que la correspondance était juste au regard de la politique IP ou de l'organisation.

Le pilote récepteur ne devait pas transformer le bit en couperet

La partie consacrée aux pilotes IP contient une prudence remarquable. L'émetteur devait poser le bit lorsqu'il s'était efforcé de produire une adresse FROM entièrement correcte. Le pilote IP récepteur, lui, ne devait entreprendre aucune action particulière sur cette base à ce stade. Le document reconnaissait qu'un travail supplémentaire était nécessaire pour définir la réaction à l'absence du bit face à une violation réelle ou seulement imaginée.

Cette réserve est une leçon d'exploitation. Définir un signal n'écrit pas automatiquement la politique d'admission. Refuser tous les messages non marqués peut casser les anciens équipements. Accepter toutes les requêtes marquées peut donner un privilège à n'importe quel processus situé sur un chemin réversible. Entre les deux, il faut connaître les capacités, la garde physique et les conséquences de l'action demandée.

L'intérêt historique du SRC n'est donc pas une promesse d'authentification avant la cryptographie moderne. C'est une partition propre : le chemin peut conserver ou soustraire une affirmation de retour, tandis que l'intégrité, l'identité, la sélection du service et l'autorisation demeurent ailleurs.

Sources et limites de la preuve

La RFC 1044 fournit les formats HYPERchannel, la règle d'inversion, les indicateurs, la condition de sécurité physique, les instructions aux pilotes et les étapes de résolution. La RFC 791 fixe la frontière du datagramme IPv4 embarqué. La RFC 826 fournit le modèle générique de résolution repris par la RFC 1044.

Ces documents prouvent une conception publiée et ses hypothèses. Ils ne mesurent pas son déploiement, ne démontrent pas qu'un adaptateur historique appliquait correctement SRC, et ne permettent pas d'attribuer une requête observée à une personne autorisée.