Résumé

  • RFC 3358 a défini un TLV facultatif contenant une somme de Fletcher sur 16 bits pour les CSNP, PSNP et IIH d’IS-IS, précisément parce que le succès de la couche liaison ne garantissait pas les octets lus plus haut.
  • L’absence et la valeur zéro restaient compatibles, tandis qu’une somme erronée, un doublon ou un placement interdit entraînaient le rejet ; cette détection d’erreur accidentelle n’était pas une authentification.

Le piège commençait par une proposition vraie : la trame avait été reçue. Il se poursuivait par une conclusion injustifiée : donc le PDU confié au routage était intact. Entre les deux se trouvait une frontière d’implémentation que le voyant vert de la couche inférieure ne pouvait pas certifier.

Publié en août 2002 dans la catégorie Information, RFC 3358 est un texte de T. Przygienda issu du groupe ISIS. Son ambition était volontairement étroite. Les LSP possédaient déjà leur propre contrôle, mais les Complete Sequence Number PDUs, les Partial Sequence Number PDUs et les IS-IS Hello PDUs reposaient sur l’intégrité fournie en dessous du protocole de routage.

Cette dépendance n’était pas absolue. Le RFC envisage un composant de couche basse défectueux ou une technologie de liaison dépourvue du contrôle attendu. Dans ce cas, la structure remise au processus IS-IS pouvait être différente de celle qui avait été émise. Une altération d’un champ de longueur avait un pouvoir particulier : elle pouvait transformer la limite apparente d’un PDU ou d’un TLV, puis faire lire comme une suite d’entrées ce qui n’en était pas une.

Le résultat possible était disproportionné par rapport au bit initial. Un résumé de base de données corrompu pouvait donner l’impression qu’un grand nombre de LSP vides ou inexistants étaient annoncés. L’erreur matérielle appartenait à une couche ; ses conséquences symboliques se multipliaient dans une autre, lorsque le logiciel reconstruisait l’état de routage.

La réparation tient dans un petit contrat. Le type 12, d’une longueur de deux octets, transporte une somme de contrôle de Fletcher sur 16 bits calculée sur l’ensemble du PDU selon les règles du document. RFC 3359 conserve ce numéro dans le registre des TLV IS-IS. L’importance du mécanisme ne vient donc pas d’un algorithme spectaculaire, mais de l’endroit où un nouveau reçu est produit.

Un récepteur qui prend en charge l’extension vérifie l’unique TLV autorisé lorsqu’il contient une valeur non nulle. Si le calcul ne correspond pas, le PDU est éliminé. Deux TLV de somme dans le même PDU sont une erreur. Un tel TLV dans un type de PDU non prévu l’est également. Le rejet intervient avant que la structure ambiguë puisse devenir une conclusion sur la base d’état de liens.

Cependant, l’absence du TLV reste valide. C’est la condition d’une évolution progressive : les voisins anciens n’émettaient pas encore le type 12 et ne pouvaient pas devenir fautifs par simple publication d’un RFC. Un récepteur ancien pouvait aussi appliquer sa règle habituelle pour un TLV inconnu sans effectuer le contrôle nouveau. L’interopérabilité était préservée, au prix d’une évidence inégale selon les deux extrémités.

La valeur zéro constitue encore un autre état. Le texte la considère comme correcte. Elle ne démontre pourtant pas qu’une valeur de Fletcher non nulle a été calculée et comparée. Pour l’exploitation, il faut donc distinguer au moins six observations : TLV absent, valeur zéro, valeur non nulle vérifiée, somme fausse, doublon et placement interdit. Les fondre dans une case « contrôle actif » détruirait l’information décisive.

La relation avec l’authentification explique en partie cette prudence. Quand une authentification cryptographique telle que HMAC-MD5 intervient, les champs couverts et l’ordre des calculs peuvent créer une dépendance circulaire. RFC 3358 impose alors d’omettre la somme facultative ou de lui donner la valeur zéro. RFC 5304 puis RFC 5310 documentent l’authentification cryptographique d’IS-IS ; ils répondent à une question différente.

Une somme de Fletcher repère une modification accidentelle. Elle ne dit pas quel système a émis le PDU, si cet émetteur était autorisé, si un ancien message a été rejoué ni si un adversaire capable a recalculé la somme après une modification. L’intégrité accidentelle, l’identité et l’autorisation sont trois reçus distincts. Présenter le type 12 comme un cadenas de sécurité serait précisément l’erreur de couche que l’article cherche à éviter.

Le contexte historique demande la même discipline. RFC 1195 décrit l’emploi intégré d’IS-IS dans les environnements TCP/IP. RFC 1142 reproduisait un texte lié à ISO 10589, mais RFC 7142 l’a ensuite classé Historique en rappelant qu’il n’avait pas vocation à devenir une norme IETF. La filiation est documentée ; un taux d’adoption de RFC 3358 ne l’est pas.

Les textes ultérieurs montrent la portée opérationnelle des familles de PDU sans prouver un incident précis. RFC 5303 ajoute une négociation à trois voies dans les IIH point à point. RFC 5306 utilise la signalisation de redémarrage. RFC 6232 aide à identifier l’origine d’une purge de LSP. Ce voisinage éclaire le terrain, mais ne permet pas d’attribuer leurs problèmes à la corruption décrite en 2002.

Le dossier ne fournit ni panne nommée, ni recensement de fournisseurs, ni pourcentage de routeurs compatibles, ni comparaison chiffrée avant et après déploiement. Il établit une machine d’états normative pour une implémentation. Il ne mesure pas sa diffusion dans le monde réel.

Pour un opérateur, l’inventaire pertinent se situe donc par adjacence. Le voisin émet-il le TLV ? Le récepteur le comprend-il ? La valeur zéro est-elle la conséquence attendue d’une authentification ? Les compteurs séparent-ils somme fausse, doublon et type interdit ? Une interface sans erreurs visibles peut coexister avec des PDU rejetés plus haut ; inversement, l’absence peut être un comportement compatible et non une panne.

Le déploiement prudent commence par observer, puis active le support sans punir l’absence. Les valeurs non nulles vérifiées, les rejets et les changements après mise à jour doivent être corrélés aux compteurs d’interface, aux captures, aux versions logicielles et à la topologie. Le checksum localise un endroit où l’altération devient visible ; il ne désigne pas son auteur.

Deux textes de Lu Heng servent ici de grille éditoriale déclarée. « Minimum Initial Specification » aide à lire le type 12 comme une correction minimale, volontaire et déployable localement. « Reality Layers » empêche de confondre les octets matériels, le symbole « trame reçue », l’interprétation du routage et le récit d’incident. Ces essais n’attribuent aucune intention supplémentaire aux auteurs du RFC.

La leçon dépasse IS-IS : tout résultat d’intégrité possède un périmètre. La preuve d’une couche n’est pas automatiquement transportable vers la suivante. La trame pouvait être bonne selon son contrôle et mauvaise pour le processus qui allait décider des routes.

Sources