Résumé

  • Le 27 octobre 1980, les IMP de l’ARPANET ont accepté puis propagé des mises à jour numérotées 8, 40 et 44 : la comparaison sur six bits faisait paraître chacun de ces nombres plus récent qu’un autre.
  • Dans la reconstruction probable d’Eric Rosen, une retransmission corrompue par un défaut matériel a déclenché la boucle ; les messages ont alors épuisé les tampons, empêché les contrôles de ligne et rendu le réseau lui-même lent pour transporter le correctif.

L’accès fonctionnait encore, mais les IMP ne se joignaient plus

Les premiers symptômes dessinaient une rupture étrange. Certains utilisateurs pouvaient encore joindre un Terminal Interface Processor, ou TIP, par ligne téléphonique. Mais une tentative vers un ordinateur rattaché à un autre Interface Message Processor (IMP) se terminait par « net trouble ». Des connexions déjà ouvertes tombaient. Le TIP répondait au téléphone ; le chemin de données entre IMP, lui, n’était plus utilisable. Cette différence a aidé les opérateurs à chercher sous la couche d’accès.

Eric C. Rosen a reconstitué l’incident dans le RFC 789 à partir, entre autres, de vidages mémoire de plusieurs IMP. Les tampons contenaient presque tous des mises à jour de routage en attente. Elles semblaient provenir de l’IMP 50, qui avait connu une panne peu avant et était hors réseau pendant l’incident. Son voisin immédiat, l’IMP 29, subissait lui aussi un défaut matériel et perdait des bits. Redémarrer les machines proches ne suffisait pas : une fois reconnectées, elles recevaient à nouveau les mêmes mises à jour de leurs voisines.

Une comparaison circulaire

Chaque IMP diffusait périodiquement des informations sur les délais et les liaisons. Chaque mise à jour portait un numéro de séquence de six bits, incrémenté modulo 64. Un IMP devait décider si la mise à jour reçue était plus récente que celle déjà connue pour son origine. La règle comparait les nombres en utilisant la moitié de l’espace de valeurs : elle acceptait un écart vers l’avant d’au plus 32, ou un retour autour de zéro de plus de 32.

Cette règle n’était pas une horloge générale. Pour les valeurs observées, elle produisait pourtant un cycle : 44 était plus récent que 40 ; 40, plus récent que 8 ; et 8, plus récent que 44. Les vidages mémoire montraient des files répétant exactement cette séquence — 8, 40, 44, puis de nouveau 8, 40, 44. Les mises à jour étaient identiques à l’exception du numéro. Chacune pouvait donc évincer une autre comme « dernière » information et repartir vers les IMP voisins.

Rosen n’a pas présenté l’origine de ces trois nombres comme une certitude. Son hypothèse la plus plausible était une mise à jour 44 recréée pour retransmission depuis des données stockées, puis retransmise après que des bits perdus eurent modifié son numéro, d’abord en 40, puis en 8. Le paquet transmis avait un contrôle d’intégrité, mais l’IMP reconstruisait une retransmission depuis des tables internes qui n’étaient pas vérifiées en continu. Une vérification constante aurait consommé du temps processeur ou de la mémoire, des ressources déjà rares.

Rosen a aussi envisagé l’autre sens : 8 aurait pu être la valeur initiale, altérée par l’ajout de bits. La boucle est observable dans les vidages ; le défaut matériel exact reste une déduction.

La panne de routage est devenue une panne de ressources

Les mises à jour étaient traitées à haute priorité. À mesure qu’elles revenaient, les IMP consacraient leurs processeurs et leurs tampons à ces paquets. Ils ne pouvaient plus réserver de tampons pour les messages HELLO et I-HEARD-YOU qui servaient à vérifier l’état des liaisons. Le protocole de voisinage cessait de fonctionner, puis le logiciel déclarait les lignes indisponibles. Une boucle dans les mises à jour a ainsi perturbé la topologie que les autres IMP essayaient de mesurer.

Le récit est plus précis que « le routage a calculé un mauvais chemin ». Pour Rosen, les routes restaient cohérentes avec les règles définies et le code de routage exécutait la procédure prévue. Le défaut matériel avait créé un état anormal ; le traitement valide de cet état consommait ensuite trop de ressources, sans mécanisme d’arrêt suffisant. Ce cas ne prouve ni une attaque ni une propriété des protocoles de routage actuels. Il montre comment une hypothèse raisonnable sur les entrées peut échouer en production lorsqu’une donnée stockée est corrompue puis amplifiée par la retransmission.

Le réseau devait se réparer par le réseau

Les opérateurs ont diffusé un correctif demandant aux IMP d’ignorer les mises à jour issues de l’IMP 50, pourtant déjà hors service. En temps normal, la diffusion prenait quelques minutes. Dans ces conditions, elle pouvait en prendre trois ou quatre heures : les IMP étaient généralement sans opérateur sur place et le centre de contrôle les pilotait par le réseau lui-même. Le canal de rétablissement dépendait donc de l’infrastructure en panne. Le correctif a fonctionné et Rosen n’a signalé aucun dommage durable au-delà de l’interruption.

Il proposait de modifier une borne dans la comparaison LATER, de renforcer la détection d’erreurs dans la prochaine génération de matériel C30 et de pouvoir repérer puis contenir un processus prioritaire qui consommait trop de ressources. Ce sont des réponses à différents étages : empêcher ce cycle connu, détecter l’erreur matérielle et rendre un nœud récupérable à distance. Elles ne garantissaient pas l’absence de tout défaut rare.

Sources et portée des preuves

Rosen a publié son étude dans le numéro de janvier 1981 de SIGSOFT Software Engineering Notes, puis l’a fait circuler comme RFC 789. C’est la source principale de cette reconstitution et elle signale explicitement les éléments qui relèvent d’une hypothèse. L’article de McQuillan, Richer et Rosen paru en mai 1980 documente les essais antérieurs du nouvel algorithme sur le réseau réel ; il ne faut pas en déduire que l’association rare d’une corruption de table et d’un bouclage des numéros avait déjà été testée. Un bref anniversaire du Computer History Museum appelle les valeurs des « horodatages » ; le RFC décrit des numéros de séquence sur six bits.

Sources : RFC 789 ; McQuillan, Richer et Rosen, « The New Routing Algorithm for the ARPANET » ; notice du 27 octobre du Computer History Museum ; copie hébergée de l’article de 1980 sur IPCOMPRO ; la primauté du code exécuté selon Heng Lu, citée uniquement comme grille éditoriale.