Résumé

  • RFC 1455 proposait la valeur TOS 15 pour demander le chemin physique le moins exposé à une observation clandestine extérieure ; le mot « maximum » ordonnait les choix disponibles, il ne fixait aucun niveau garanti.
  • Chaque réseau devait convertir la demande en coûts relatifs pour ses lignes et ses routeurs. Le marquage attestait donc une intention, non la politique chargée, le trajet réellement suivi ou la confidentialité obtenue.
  • La proposition distingue durablement une classe déclarée du service observé : entre les deux se trouvent l’interprétation, la politique locale, le routage, l’état des installations, le chiffrement et les contrôles aux extrémités.

Le chiffre qui n’était pas une probabilité

Le tableau fictif de RFC 1455 est frappant. Une liaison dotée d’un chiffrement robuste et d’une distribution sûre des clés reçoit le coût 1. Une ligne point à point physiquement protégée reçoit 2 ; une liaison point à point ordinaire, 6 ; un support local partagé, 8 ; un support métropolitain partagé, 12 ; une radio locale, 24 ; un satellite, 32.

Lire ces nombres comme des probabilités serait une erreur. Le document ne disait pas qu’une interception avait 32 % de chances de réussir sur satellite. Il ne publiait aucune campagne de mesure. Il proposait des rapports permettant à un algorithme de classer des itinéraires selon une hypothèse locale : ici, le satellite était tenu pour trente-deux fois plus exposé que la liaison chiffrée de référence.

Le paquet, lui, n’emportait ni le barème, ni sa date, ni le modèle d’adversaire. Il ne contenait que la demande.

Quatre bits visibles, aucune serrure

La valeur retenue était 15 en décimal, F en hexadécimal, soit 1111 dans le champ TOS de quatre bits. Elle se trouvait à la plus grande distance de Hamming des autres valeurs définies. Cette distance réduisait les risques de confusion entre codes ; elle ne mesurait pas la robustesse de la protection.

RFC 1349 avait précisément transformé ce champ en valeur énumérée. Les bits n’étaient plus quatre interrupteurs indépendants à combiner. 1111 ne signifiait pas retard, débit, fiabilité et coût tout à la fois. Il sélectionnait une seule demande nouvelle.

Le contenu restait inchangé. Les adresses IP demeuraient en clair pour que les routeurs travaillent. Même un contenu chiffré pouvait révéler, par son rythme et ses correspondants, une activité sensible. RFC 1455 cherchait à compliquer l’observation par un tiers extérieur en préférant des supports physiques moins accessibles. Il n’éliminait ni la visibilité des en-têtes, ni un observateur interne, ni un routeur compromis.

« Le mieux disponible » n’était pas un seuil

Le texte avait la prudence d’opposer préférence et garantie. Des utilisateurs auraient voulu exiger un niveau déterminé de sécurité, comme ils auraient voulu garantir bande passante ou délai. Un tel engagement supposait réservation de ressources ou routage par politique, au-delà du TOS de l’époque.

Ainsi, « maximum » voulait dire : parmi les routes que ce nœud connaît et selon la table qu’il applique, favoriser celle qu’il estime la moins facile à observer. Il ne voulait pas dire : refuser tout chemin situé sous un seuil vérifiable.

RFC 1349 avait adopté un TOS faible. En l’absence d’une route correspondant à la valeur demandée, une route par défaut pouvait servir. Ce choix évitait que les premiers utilisateurs de classes encore rares soient punis par une perte systématique. Mais il rendait le succès silencieux : recevoir le paquet ne prouvait pas que sa préférence avait été comprise.

RFC 1455 reconnaissait d’ailleurs qu’une mise en œuvre par tout l’Internet n’était pas réaliste à brève échéance. Quatre bits traversant le réseau ne constituaient donc pas une chaîne d’exécution.

La politique résidait chez l’opérateur

Un protocole de routage tenant compte du TOS pouvait associer une métrique différente à chaque liaison. Le réglage de cette métrique était explicitement une fonction de politique locale.

La fibre pouvait sembler plus difficile à écouter que le cuivre ; le point à point, moins exposé qu’Ethernet ou FDDI ; un conduit surveillé ou pressurisé, plus sûr qu’une ligne accessible ; l’étalement de spectre, moins interceptable qu’une diffusion radio ordinaire. Une liaison chiffrée résistait mieux après une prise du signal. Pourtant, ces qualités ne formaient pas toujours une échelle naturelle. Une diffusion chiffrée et une fibre non chiffrée protégeaient des choses différentes.

Celui qui attribuait les coûts décidait de l’arbitrage. Deux réseaux pouvaient reconnaître la même valeur 15 et produire des routes opposées. Ils auraient partagé la syntaxe sans partager le jugement.

Cinquante sauts contre deux

RFC 1455 poussait sa logique jusqu’à une image paradoxale : plus de cinquante liaisons très protégées pouvaient l’emporter sur deux liaisons dangereuses, par exemple un saut satellite non chiffré puis une radio. La métrique de sécurité pouvait sacrifier la brièveté.

Mais chaque saut ajoutait un routeur. Or un routeur possède un site, des personnes, un logiciel, une configuration et une exposition physique. Un modèle obsédé par le seul câble pouvait choisir une succession de lignes excellentes et de locaux vulnérables. Le document demandait donc de noter les équipements autant que les supports.

Cette correction ne transformait toujours pas le calcul en preuve. Il fallait encore savoir quelle route avait été calculée, laquelle avait effectivement transmis le paquet et dans quel état se trouvaient alors les sites.

Additionner une réalité multiplicative

Les algorithmes additionnaient d’ordinaire les coûts des liens. Pour la probabilité d’une transmission sûre, RFC 1455 jugeait qu’un produit serait plus approprié. Il acceptait néanmoins la somme comme approximation utilisable, à l’image du TOS de haute fiabilité dans RFC 1349.

Le détail est essentiel. Le résultat du routeur provenait d’un modèle simplifié appliqué à des rapports supposés. Il pouvait ordonner des possibilités ; il ne calculait pas la chance absolue qu’un adversaire échoue.

Une métrique utile n’a pas besoin d’être parfaite. Elle doit en revanche conserver son nom exact : préférence sous une politique donnée. Si on la rebaptise « sécurité garantie », l’approximation emprunte une autorité qu’elle ne possède pas.

Étiquette de sécurité et chemin discret

RFC 1108 portait une proposition différente. Son option de sécurité de base transportait un niveau de classification et les autorités de protection applicables. Les systèmes pouvaient vérifier si un datagramme était admissible depuis sa source, vers sa destination et sur une route suffisamment protégée ; les protocoles de routage devaient connaître les étiquettes nécessaires.

La valeur de RFC 1455 ne disait rien de tel. Elle ne nommait ni classification, ni autorité, ni habilitation. Elle demandait simplement le meilleur chemin physique disponible pour limiter l’observation extérieure.

Une étiquette ne chiffrait pas à elle seule les données ; un chemin jugé discret n’autorisait pas le lecteur final. Classification, chiffrement, identité, admission et résultat demeuraient des faits séparés.

Quand l’octet changea de métier

RFC 2474 a ensuite rendu obsolètes les anciennes définitions du TOS et créé le champ Differentiated Services. Un DSCP choisissait un comportement par saut ; des classificateurs, des conditionneurs de trafic et une politique aux frontières du domaine construisaient le service.

L’octet du paquet survivait, mais sa grammaire changeait. Une capture ne peut donc être interprétée seulement par sa forme. Il faut connaître l’époque, le domaine et la règle qui donnaient sens aux bits.

Cette succession n’est pas la preuve que la demande de RFC 1455 fut déployée, puis améliorée. Elle montre plutôt qu’un emplacement de protocole peut rester stable alors que les contrats d’exploitation qui l’entourent disparaissent.

La chaîne qu’il fallait encore établir

demande de l’émetteur → code reconnu → coûts locaux à jour → route calculée → chemin réellement suivi → protection des lignes et des routeurs → état cryptographique → autorisation aux extrémités → résultat face à l’adversaire

À chaque flèche, le détenteur de la preuve change. Le paquet prouve son marquage. La configuration prouve une table. La télémétrie prouve un trajet. Les dossiers d’installation et de clés prouvent des conditions. Seule une observation bornée peut décrire ce qu’un adversaire déterminé a obtenu.

Le mérite historique de RFC 1455 tient à sa modestie. Il inscrivait une préférence dans l’en-tête tout en refusant de présenter cette préférence comme le résultat final.

Sources et limites

Le statut et l’obsolescence figurent dans la notice RFC Editor de RFC 1455. La définition, le modèle de menace et le tableau de coûts viennent de RFC 1455. La grammaire énumérée, la sémantique sans garantie et le repli faible sont décrits par RFC 1349. Le mécanisme distinct de classification provient de RFC 1108. Le remplacement du champ est établi par la notice RFC Editor de RFC 2474.

Ces textes prouvent des spécifications et leurs limites déclarées. Ils ne prouvent ni déploiement, ni métrique réelle, ni taux d’interception, ni chemin protégé observé, ni état actuel du droit, ni confidentialité réussie.