Résumé

  • L’option IPv4 numéro 68 organisait, dans un espace limité du paquet, l’inscription d’horodatages seuls ou de couples adresse-horodatage.
  • L’absence d’authentification, les horloges non synchronisées, la divulgation d’informations et le filtrage ont progressivement vidé cette coopération de sa portée pratique.

Un registre dont le paquet fixait les règles

Le mécanisme partait d’une idée directe : plutôt que d’observer le chemin uniquement depuis ses extrémités, le paquet emporterait la place nécessaire pour recevoir des observations en route. RFC 791 lui attribuait le type 68. Son bit de copie valait zéro : après fragmentation, seule la première partie le conservait. Un datagramme ne pouvait contenir l’option qu’une seule fois.

Le format empêchait l’écriture sans borne. Un octet indiquait la longueur, plafonnée à 40 octets, et un autre pointait vers le prochain emplacement, avec 5 comme valeur minimale valide. Un champ de quatre bits comptait les débordements et un autre champ de quatre bits choisissait le mode. Faute de place, la machine incrémentait le compteur au lieu de dépasser l’option. Une longueur ou un pointeur incorrect, ou le débordement du compteur lui-même, rendait le datagramme erroné : il devait être détruit, avec la possibilité d’envoyer un message ICMP Parameter Problem.

Trois modes donnaient des sens différents au registre. Le drapeau 0 alignait des horodatages de 32 bits. Le drapeau 1 faisait précéder chaque heure par l’adresse Internet de la machine. Le drapeau 3 fournissait d’avance les adresses et n’autorisait l’inscription que si la prochaine adresse correspondait au système qui traitait le paquet. La valeur normale exprimait les millisecondes écoulées depuis minuit en temps universel. Une autre référence restait permise si le bit de poids fort signalait explicitement qu’elle n’était pas standard.

Ce registre n’était donc jamais la chronique complète et certifiée d’un trajet. Il disait seulement ce qu’une implémentation participante avait écrit, avec sa propre horloge, dans l’espace et le mode imposés par l’expéditeur.

Des obligations différentes pour les hôtes et les routeurs

RFC 1122 laissait aux hôtes le choix d’émettre et de traiter l’option. Ceux qui l’implémentaient devaient cependant respecter le contrat : l’hôte d’origine inscrivait son heure lorsque le mode le permettait ; la destination ajoutait si possible l’heure courante avant de remettre l’option à la couche supérieure. La norme maintenait la référence à minuit UT et le marquage des valeurs non standard.

RFC 1812 demandait davantage aux routeurs : ils devaient prendre en charge l’option dans les paquets transférés. En mode 3, une correspondance avec n’importe laquelle de leurs adresses suffisait, pas seulement l’interface d’entrée ou de sortie. Une commande pouvait laisser inchangés les modes 0 et 1, mais elle devait être désactivée par défaut. Le texte reconnaissait en même temps une faiblesse essentielle : inscrire au plus près de l’arrivée améliore l’observation, sans rendre comparables des horloges désaccordées.

Le coût de rendre le chemin visible

RFC 7126 a formulé le renversement opérationnel. Les heures de traitement et les adresses pouvaient aider au diagnostic, mais révélaient aussi la topologie, le temps des systèmes et des caractéristiques d’implémentation. Le décalage des horloges pouvait même contribuer à distinguer des appareils physiques. Le même registre servait ainsi l’opérateur légitime et l’observateur indésirable.

Le filtrage rendait ensuite l’outil incertain. Un ping ordinaire n’avait pas besoin d’options IPv4, tandis qu’un diagnostic dépendant du type 68 échouait dès qu’une frontière refusait le paquet. Constatant que cette pratique était déjà répandue et avait rendu la technique presque inutilisable, RFC 7126 recommandait aux routeurs, passerelles de sécurité et pare-feu de supprimer ces paquets.

Sources