Résumé

  • Dans RFC 1326, un paquet X enveloppé dans Y pouvait être enveloppé de nouveau dans X avant d’avoir quitté le premier tunnel. Chaque passerelle accomplissait une opération locale cohérente, mais la suite n’avait plus de borne commune.
  • Si la nouvelle enveloppe ne conservait pas le nombre de sauts de la précédente, le compteur actif repartait à neuf. L’accumulation d’en-têtes atteignait ensuite la MTU et la fragmentation transformait la croissance en multiplication.
  • Traduire les compteurs, regarder à travers les en-têtes ou interdire certains emboîtements ne résolvait qu’une partie du problème. La propriété décisive était une limite consommée par toutes les encapsulations.

Le compteur n’avait pas disparu ; il avait perdu son autorité

La scène la plus importante de RFC 1326 tient dans une différence de visibilité. Un paquet porte un compteur destiné à l’empêcher de tourner indéfiniment. Une passerelle l’encapsule pour traverser un réseau d’une autre famille. Le compteur original reste présent, mais il se trouve désormais dans la charge utile. Les routeurs du nouveau réseau obéissent à l’en-tête extérieur et à son propre nombre de sauts.

Si le paquet revient vers une autre passerelle avant d’être décapsulé, une enveloppe supplémentaire peut recevoir, elle aussi, une valeur neuve. Le système n’a donc pas supprimé sa règle d’expiration. Il l’a reléguée à un étage qui ne gouverne plus l’étape suivante. La règle existe dans le fichier ; elle n’agit plus sur le trajet effectif.

Cette séparation donne la thèse historique du document. Une valeur non nulle dans l’en-tête visible décrit la vie restante de cette enveloppe. Elle ne certifie ni l’âge du paquet intérieur ni le nombre de frontières de tunnel déjà franchies. Confondre les deux revient à prendre l’état du contenant pour l’histoire de l’objet transporté.

Deux adaptations raisonnables formaient une boucle déraisonnable

L’encapsulation ordinaire répondait à un besoin concret. Un paquet du protocole X devait traverser un backbone qui ne comprenait que Y. Le routeur d’entrée ajoutait un en-tête Y dirigé vers un routeur de sortie ; celui-ci retirait l’enveloppe et rendait le paquet X à son réseau. Rien, dans ce parcours, n’était pathologique.

Le risque apparaissait lorsque les relations étaient réciproques : X circulait au-dessus de Y quelque part, tandis que Y circulait au-dessus de X ailleurs. RFC 1326 citait IP sur AppleTalk et AppleTalk sur IP, puis envisageait d’autres rencontres entre IP, CLNP, IPX, DECNET et des protocoles propriétaires. La multiplication des mondes techniques rendait ces ponts inévitables.

Supposons alors une boucle de routage transitoire. Le paquet X devient Y<X> pour traverser un réseau Y. La route ne le conduit pas vers la sortie attendue, mais vers une frontière où le prochain réseau exige X. La passerelle ajoute X sans retirer Y : X<Y<X>>. Au retour, une nouvelle couche Y donne Y<X<Y<X>>>.

La panne globale ne suppose pas que l’une des passerelles mente. Chacune peut constater avec exactitude que son prochain lien exige une enveloppe particulière. Ce qui manque est une preuve portant sur leur composition : le paquet se rapproche-t-il d’une sortie, et chaque nouvelle couche consomme-t-elle une ressource qui ne peut être réinitialisée ?

La MTU changeait une accumulation en descendance

À chaque tour, les en-têtes ajoutaient des octets. Cette augmentation restait d’abord linéaire. La Maximum Transmission Unit introduisait ensuite un seuil. Dès que le paquet enveloppé ne tenait plus sur un lien, il devait être fragmenté. Les fragments reprenaient la boucle, recevaient leurs propres couches et pouvaient être fragmentés encore.

Le terme d’« explosion exponentielle » employé par RFC 1326 désignait ce mécanisme de reproduction. Il ne décrivait ni une explosion physique ni une attaque observée. Un paquet produisait plusieurs fragments ; plusieurs fragments repassaient par la même transformation ; leur population pouvait donc croître plus vite que la simple pile d’en-têtes.

La saturation n’était pas seulement un problème de débit. Le texte avertissait que les paquets en boucle pouvaient faire rejeter les mises à jour de routage ou les messages de gestion. Le trafic de données défectueux privait alors le plan de contrôle de la capacité nécessaire pour corriger la boucle. L’incident potentiel s’entretenait en détruisant son propre mécanisme de retour d’information.

Le document ajoutait qu’une fois la boucle rompue, les paquets seraient rapidement évacués. Cette phrase décrit le comportement attendu d’un mécanisme. Elle ne constitue pas le compte rendu d’un réseau nommé, d’une durée mesurée ou d’un service effectivement rétabli.

Préserver le nombre de sauts n’était pas une opération neutre

La première solution envisagée consistait à reporter le nombre de sauts dans la nouvelle enveloppe. Quand les deux protocoles possédaient des champs compatibles, la même limite pouvait continuer à diminuer. Mais certains protocoles, dont X.25 et SMDS dans l’exemple du RFC, ne portaient pas un tel champ. D’autres n’offraient pas la même plage.

AppleTalk limitait le trajet à 16 sauts, alors qu’IP pouvait en exprimer jusqu’à 256. Réduire une valeur IP pour la faire entrer dans la petite plage arrêtait certaines boucles au prix d’un autre risque : déclarer morte une route IP légitime de plus de 16 sauts. Une conversion n’était pas seulement un calcul. Elle choisissait quelle sémantique sacrifier.

La seconde idée était l’inspection des couches. Avant d’ajouter X autour de Y<X>, une passerelle pouvait repérer la présence antérieure de X et rejeter le paquet. Mais son savoir s’arrêtait à l’en-tête inconnu, au contenu chiffré ou à un protocole transporté plus haut dans la pile. Surtout, deux enveloppes du même protocole pouvaient être légitimes dans un emboîtement correctement construit. La répétition était un indice, pas un verdict.

RFC 1326 proposait enfin une combinaison prudente : décourager l’encapsulation mutuelle, interdire son emboîtement, préserver les compteurs et inspecter quand cela avait un sens. Ce n’était pas un algorithme universel. Le statut Informational du texte et sa déclaration selon laquelle les questions de sécurité n’étaient pas abordées interdisent d’en faire rétroactivement la preuve d’une attaque.

Un budget distinct pour l’emboîtement

RFC 2003 a ensuite encadré l’encapsulation IP dans IP. Quand le tunnel fait partie du transfert, l’encapsulateur décrémente une fois le TTL intérieur et refuse d’envelopper un datagramme dont le TTL vaut zéro. Il rejette aussi certains cas où l’adresse source correspond à l’encapsulateur ou à la destination du tunnel. Ces règles sont précises ; leur précision limite également leur portée.

RFC 2473 a rendu explicite une autre dimension dans les tunnels IPv6. La limite de sauts du paquet original mesure son transfert. Une Tunnel Encapsulation Limit mesure le nombre de couches supplémentaires encore permises. Zéro signifie que le paquet ne peut pas entrer dans un nouveau tunnel avant d’avoir quitté le tunnel courant.

Le progrès conceptuel tient à l’objet mesuré. Un compteur de sauts ne remplace pas un compteur d’emboîtement. Les deux peuvent évoluer différemment parce qu’ils répondent à deux questions différentes. RFC 2473 rappelle également que fragmenter un paquet tunnel déjà fragmenté double le nombre de fragments. Six ans après RFC 1326, le risque architectural n’avait pas été effacé ; il avait reçu une limite dédiée.

Sources

Ces sources établissent le statut des documents, les mécanismes décrits et des réponses protocolaires ultérieures. Elles n’établissent aucun incident de 1992, tunnel actuel, auteur malveillant, défaut de fournisseur, taux de déploiement, dommage ou réparation réussie.