Résumé

  • La RFC 7112 exige que le fragment IPv6 dont le décalage vaut zéro contienne toute la chaîne d’en-têtes jusqu’au premier en-tête de couche supérieure. Une politique qui dépend d’un protocole ou d’un port n’a donc plus à choisir avant d’avoir reçu le champ décisif.
  • Cette complétude ne concerne pas le datagramme entier. La construction à la source, le MTU du chemin, la décision de chaque équipement, le message ICMPv6 de type 4 code 3, les fragments suivants, le réassemblage et le résultat applicatif restent des preuves distinctes.

Le port qui arrivait trop tard

La faiblesse décrite par la RFC 7112 tient dans un décalage de quelques octets. IPv6 permet d’enchaîner plusieurs en-têtes d’extension entre l’en-tête de base et TCP, UDP ou ICMPv6. Si cette chaîne est longue, ou si la première pièce est courte, le fragment de décalage zéro peut s’arrêter avant l’en-tête de transport.

Pour un routeur qui ne lit que la destination, la différence peut être sans effet. Pour un pare-feu sans état dont la règle autorise un port et en refuse un autre, elle est décisive. Transmettre la pièce incomplète revient à admettre sans voir le port. La jeter revient peut-être à refuser un flux autorisé. Le dispositif n’a pas seulement trop peu de données ; il doit agir avant que l’information dont dépend son action n’existe dans son champ de vision.

La RFC 7112 ne répond pas en exigeant le réassemblage dans chaque équipement intermédiaire. Une telle obligation ajouterait état, mémoire et exposition au déni de service sur tout le chemin. Elle déplace plutôt la contrainte vers la source : lorsqu’un hôte fragmente un datagramme IPv6, il doit placer la chaîne complète dans le premier fragment.

La règle est minimale. Le paquet ne doit pas tout raconter. Il doit seulement atteindre le point où le prochain protocole est identifiable avant de se couper.

Où se termine « toute la chaîne »

Le mot « complète » pourrait faire croire que le premier fragment doit porter le contenu applicatif. La définition l’exclut.

La chaîne commence avec l’en-tête IPv6 initial. Elle suit les valeurs Next Header à travers zéro, un ou plusieurs en-têtes d’extension. Elle s’arrête au premier en-tête qui n’est ni IPv6 ni une extension IPv6. Dans un cas simple, c’est TCP ou UDP. Un second en-tête IPv6, dans une encapsulation IPv6 sur IPv6, termine également la chaîne au sens de la RFC. ESP joue le même rôle de borne. La valeur « No Next Header » peut la terminer en l’absence de couche supérieure.

Les données situées après l’en-tête TCP ne font pas partie de cette chaîne. Une grande réponse HTTP peut donc rester fragmentée ; seule son introduction protocolaire doit tenir dans la première pièce. La RFC ne prohibe pas les charges utiles volumineuses. Elle limite la longueur cumulée des en-têtes au MTU du chemin.

La conséquence est analytique. Voir le port TCP peut suffire à une ACL. Cela ne suffit pas à une inspection du contenu. Une première pièce conforme peut transporter une intention malveillante dans des données ultérieures. Elle peut aussi être authentique ou usurpée. Le test répond à « l’en-tête nécessaire est-il visible ? », non à « ce trafic est-il digne de confiance ? ».

Trois lieux de décision

La source, l’équipement intermédiaire et la destination ne reçoivent pas le même verbe normatif.

La source qui fragmente doit inclure la chaîne entière dans le premier fragment. C’est l’invariant de construction. Une capture au plus près de l’émetteur permet de vérifier quelle suite d’en-têtes a été produite et avec quelle connaissance du MTU.

L’hôte destinataire qui reçoit un premier fragment incomplet devrait le jeter et devrait envoyer une erreur ICMPv6, sous réserve des règles générales qui limitent ces erreurs. Pour la compatibilité avec d’anciens comportements, une implémentation peut néanmoins proposer une option autorisant ces fragments.

Un système intermédiaire peut jeter le fragment et peut envoyer l’erreur. S’il possède cette capacité, il devrait permettre de configurer le rejet. La RFC ne transforme donc pas chaque routeur en police universelle. Elle donne à chaque point une condition lisible et borne les choix possibles.

Ces nuances empêchent une mauvaise conclusion fréquente : l’absence de rejet à un endroit ne prouve pas que le datagramme est conforme, et la présence d’un rejet ne dit pas encore quel acteur l’a décidé. Il faut le nom de l’équipement, son interface, sa version, la règle active et la capture correspondante.

Le code 3 donne une forme à l’échec

Lorsqu’un hôte ou un système intermédiaire rejette la première pièce pour chaîne incomplète et choisit de le signaler, la RFC 7112 fixe le message : ICMPv6 « Parameter Problem », type 4, code 3, pointeur à zéro. L’IANA a enregistré ce code pour cette cause précise.

Cette précision transforme un silence en reçu potentiel. Un développeur peut relier le message au paquet fautif. Un opérateur peut compter les rejets et comparer une hausse avec un déploiement logiciel ou une modification de tunnel. Un laboratoire peut construire un cas de test où le port n’apparaît qu’après la coupure.

Le reçu n’est pourtant pas garanti. Un intermédiaire n’est pas obligé d’envoyer le message. Les règles ICMPv6 peuvent l’interdire ou le limiter. Le chemin retour peut le filtrer. Une adresse source usurpée peut l’acheminer vers un tiers. L’absence de code 3 ne certifie donc rien à elle seule.

Pour devenir une preuve, le message doit conserver son contexte : date, point de capture, portion du paquet incluse, compteur de rejet local, interface et version de configuration. Sinon, un code très spécifique devient une alerte sans auteur.

L’admission n’est pas le réassemblage

La RFC 8200, qui a remplacé la RFC 2460, a intégré la règle à la spécification IPv6. Ses schémas séparent clairement les en-têtes présents dans chaque fragment, l’en-tête Fragment, les extensions et la couche supérieure placées dans le premier, puis les données réparties dans les pièces suivantes.

Le réassemblage n’intervient qu’à la destination. Il associe des fragments à partir des adresses source et destination et de l’identifiant de fragmentation. Il calcule leur place par le décalage et leur longueur. Il attend les morceaux manquants, détecte les recouvrements et abandonne après le délai prévu si l’ensemble ne se ferme pas.

Un premier fragment conforme franchit donc un contrôle d’entrée. Il ne promet pas que la dernière pièce arrivera. Il ne garantit pas l’absence de recouvrement, la cohérence des longueurs, le respect de la limite de taille ou la réussite du protocole supérieur. À l’inverse, un pare-feu peut laisser passer des fragments ultérieurs après avoir rejeté le premier : sans la pièce de décalage zéro, la destination ne peut pas reconstruire le datagramme, et la politique peut tout de même être effective.

Il faut trois phrases dans le journal plutôt qu’une seule : la chaîne du premier fragment était complète ; le réassemblage a abouti ou non ; le service a réussi ou échoué. « Le fragment est passé » ne dit laquelle.

Le registre opérationnel à conserver

Une preuve exploitable commence par la forme du paquet. Il faut conserver le décalage, le bit M, l’identifiant de fragmentation, l’ordre des valeurs Next Header, la première couche supérieure atteinte et la longueur observée de la chaîne. Le point de capture est essentiel, car une encapsulation peut modifier ce qu’un autre équipement voit.

Vient ensuite le contexte MTU. La règle impose que la chaîne tienne dans le MTU du chemin. La RFC 7112 fixe une borne de 1 280 octets lorsque l’hôte ne découvre pas ce MTU. Un nouveau tunnel, une baisse du MTU effectif ou une croyance périmée à la source peuvent donc faire apparaître une violation après des mois de fonctionnement.

Le traitement forme une troisième famille : identifiant de l’équipement, interface, version du parseur, révision de la règle, mode de compatibilité, verdict et compteur. La génération du code 3, sa limitation et son observation en forment une quatrième. Les offsets suivants, doublons, recouvrements, délais et résultat du réassemblage en forment une cinquième. Le résultat TCP ou applicatif vient seulement après.

Chaque ligne peut changer sans les autres. Un équipement peut bien filtrer mais mal journaliser. Le code 3 peut disparaître alors que le rejet demeure. Le premier fragment peut être parfait tandis que la dernière pièce se perd. La qualité du registre réside dans cette séparation.

Le faux cousin atomique

La RFC 6946, écrite par Fernando Gont, traite un état voisin mais différent : le fragment atomique. Le paquet comporte un en-tête Fragment, mais son décalage et son bit M valent tous deux zéro. Il est déjà complet et n’attend aucun autre morceau.

Certaines implémentations l’inséraient pourtant dans une file de réassemblage avec d’autres fragments partageant le même triplet source, destination et identifiant. Un attaquant pouvait exploiter ce mélange. La RFC 6946 impose donc de traiter le fragment atomique indépendamment des autres fragments, comportement repris par la RFC 8200.

Cette solution ne remplace pas la RFC 7112. Une chaîne incomplète dans le premier fragment, un fragment atomique et deux fragments qui se recouvrent sont trois états. Les étiqueter tous « trafic fragmenté » efface les transitions nécessaires à l’enquête.

La télémétrie devrait permettre de les reconstruire. Le format du protocole fournit déjà le décalage, le bit M, l’identifiant et la chaîne. C’est la normalisation des journaux, non IPv6, qui les rend parfois invisibles.

Du correctif à la spécification de base

En 2014, la RFC 7112 mettait à jour la RFC 2460. En 2017, la RFC 8200 a remplacé celle-ci et intégré la contrainte dans sa procédure de fragmentation. Elle exige que les extensions après l’en-tête Fragment et l’en-tête de couche supérieure soient placés dans la première pièce ; si celle-ci ne va pas jusque-là, elle devrait être rejetée avec le code 3.

La RFC 9099 a ensuite formulé le conseil d’exploitation : les équipements de sécurité et les destinations devraient laisser tomber les premières pièces qui ne contiennent pas toute la chaîne, transport compris, faute de quoi un acteur hostile peut contourner le filtrage sans état.

Cette trajectoire documentaire ne prouve pas le parc installé. Des commutateurs peuvent avoir une profondeur de parsing limitée. Des pare-feux peuvent conserver un mode ancien. Des hôtes peuvent différer dans la génération d’ICMPv6. Seuls des paquets d’essai, des captures, des compteurs et des résultats de service établissent la réalité locale.

Le standard décrit le test. Le code en fonctionnement remplit la case résultat.

La contribution documentée de Fernando Gont

Fernando Gont partage la signature de la RFC 7112 avec Vishwas Manral et Ron Bonica. Le document a été relu dans le processus de l’IETF et publié sur la Standards Track. Ni cette procédure ni la place d’auteur ne font d’un individu le propriétaire de la règle ou le décideur des réseaux qui l’appliquent.

La RFC 6946 et le profil IETF de Gont donnent toutefois une cohérence au choix du personnage. Le profil recense 40 RFC et des travaux sur la sécurité des protocoles. Dans ces deux textes de fragmentation, le geste est semblable : identifier des états que les implémentations avaient confondus, puis définir une séparation vérifiable.

La première pièce doit montrer l’en-tête qui rend possible une décision locale. Le fragment atomique doit rester hors d’une file qui ne le concerne pas. Dans les deux cas, l’autorité reste dans la fonction : le format offre la preuve, l’équipement applique sa règle, la destination reconstruit et l’application juge le résultat.

Le mérite du mécanisme tient justement à ce qu’il ne demande pas au premier fragment de devenir le paquet entier. Il lui demande seulement de ne pas cacher la nature de ce qui suit.

Sources