Analyse des en-têtes d'extension IPv6 contenant des extensions inconnues
J'écris un filtre réseau très simple et j'arrive à l'endroit où je veux analyser les en-têtes IPv6 pour les faire correspondre à des types tels que les types ICMPv6, les numéros de port TCP/UDP, etc.
Donc, je lis sur le format de paquet IPv6 en profondeur, et je suis un peu comme ... eh bien ... je devais en quelque sorte le lire encore et encore pour m'assurer que j'étais bien en fait le lire correctement. Il me semble que vous devez commencer par l’en-tête fixe de 40 octets et examiner son champ d’en-tête suivant. Ensuite, vous devez regarder le champ d'en-tête suivant de l'en-tête suivant, et ainsi de suite, comme une liste chaînée, jusqu'à la fin. S'il y a une charge utile, cela suivra.
Le problème est qu'il n'y a pas de champ de longueur ni dans l'en-tête fixe ni dans les en-têtes d'extension. Vous devez disposer d'une table des types d'en-tête d'extension et de leurs tailles afin de pouvoir poursuivre cette liste liée à la fin.
Cela me semble être une conception étrange, peut-être même décoiffée. Que se passe-t-il si je rencontre un type d'en-tête d'extension non reconnu? Que fais-je? Je ne connais pas sa longueur. Je suppose que je dois jeter le paquet et le bloquer, car dans un filtre réseau le laisser passer permettrait à un attaquant de contourner le filtre réseau en incluant un type d'en-tête factice. Mais cela signifie que si le protocole est étendu, chaque logiciel d'analyse d'en-tête IPv6 jamais écrit doit être mis à jour simultanément si la nouvelle extension doit être utilisée.
Alors, comment puis-je analyser les en-têtes IPv6 si je ne connais pas les extensions qu’ils utilisent? Comment puis-je ignorer un en-tête pour une extension inconnue, puisque je ne connais pas sa longueur?
Si vous rencontrez quelque chose que vous ne pouvez pas analyser, vous devez prendre votre décision ou exécuter votre action en fonction de ce que vous avez déjà analysé.
La conception est la même, car dans IPv6, chaque en-tête d’extension "enveloppe" le reste du paquet. Si vous voyez l'en-tête de routage, puis une entête dont vous n'avez jamais entendu parler, puis la charge utile, vous ne pouvez pas analyser la charge utile. La signification de la charge utile dépend en principe de l’en-tête que vous ne savez pas interpréter.
Les routeurs peuvent acheminer de tels paquets car ils n'ont besoin que de l'en-tête de routage. Les gadgets d’inspection approfondie des paquets et autres objets similaires doivent en savoir beaucoup, mais c’est leur destin de toute façon.
Modifié pour ajouter: Cette conception signifie que les boîtes de médiation ne peuvent changer que ce qu’elles savent. Si un boîtier de médiation voit un en-tête qu’il ne connaît pas, il n’a que deux options: rejeter ou transmettre. En IPv4, cela pourrait également supprimer l’extension inconnue et transmettre le reste. OMI cette propriété rend la conception plus plutôt que moins extensible.
Que se passe-t-il si je rencontre un type d'en-tête d'extension non reconnu?
De RFC 246 :
Si, à la suite du traitement d'un en-tête, un nœud doit passer à l'en-tête suivant mais que la valeur du prochain en-tête dans l'en-tête actuel n'est pas reconnue par le nœud, , il doit alors ignorer le paquet et envoie un message Problème de paramètre ICMP à la source du paquet , avec une valeur de code ICMP égale à 1 ("type d'en-tête suivant non reconnu rencontré") et le champ Pointeur ICMP contenant le décalage de la valeur non reconnue dans le paquet d'origine. La même action doit être entreprise si un nœud rencontre une valeur zéro pour l'en-tête de Next dans tout en-tête autre qu'un en-tête IPv6.
Il est (dans le monde réel) impossible d'ajouter un nouvel en-tête d'extension à IPv6.
Incorrect, parce que:
Seul l'hôte de destination est autorisé à rejeter en fonction des en-têtes d'extensions non reconnues (avec cette exception mentionnée dans la question que vous avez liée )
Si votre nouvel en-tête d’extension est en quelque sorte facultatif (cela aurait mieux de l’être), vous recevrez une erreur ICMP à ce sujet et vous pourrez réessayer sans elle.
La mise à jour RFC 6564 couvre ce cas. Il présente exactement le scénario que vous décrivez et propose un format pour tous les nouveaux en-têtes d'extension (le cas échéant) avec lesquels les boîtes de médiation telles que la vôtre seront en mesure de fonctionner, au moins de temps en temps.
N'oubliez pas qu'il n'est pas prévu d'étendre IPv6 en créant de nouveaux en-têtes d'extension, mais en ajoutant de nouvelles options de destination. Cela devrait être trivial, ou du moins beaucoup plus facile, de gérer des options de destination inconnues.