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à où je veux analyser les en-têtes IPv6 pour faire correspondre des éléments tels que les types ICMPv6, les numéros de port TCP / UDP, etc.

Donc, je lis en profondeur le format de paquet IPv6 , et je suis un peu comme ... eh bien ... j'ai en quelque sorte dû le lire encore et encore pour m'assurer que je le lisais correctement. Il me semble que vous devez commencer par l'en-tête fixe de 40 octets et regarder 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 liée, jusqu'à ce que vous atteigniez 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 dans l'en-tête fixe ou dans les en-têtes d'extension. Vous devez disposer d'un tableau des types d'en-têtes d'extension et de leurs tailles afin de pouvoir poursuivre cette liste liée jusqu'à la fin.

Cela me semble être un design étrange, peut-être même insensé. Que faire 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, autoriser le paquet permettrait à un attaquant d'échapper au filtre réseau en incluant un type d'en-tête faux. Mais cela signifie que si le protocole est étendu, chaque élément du 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 sauter un en-tête pour une extension inconnue, car je ne connais pas sa longueur?

Si vous rencontrez quelque chose que vous ne pouvez pas analyser, vous devez prendre votre décision ou effectuer votre action en fonction de ce que vous avez déjà analysé.

La conception est la même parce que dans IPv6, chaque en-tête d'extension "enveloppe" le reste du paquet. Si vous voyez l'en-tête de routage, puis un en-tê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 tout ce dont ils ont besoin est l'en-tête de routage. Les gadgets d'inspection approfondie des paquets et autres ont besoin d'en savoir beaucoup, mais c'est leur destin de toute façon.

Modifié pour ajouter: Cette conception signifie que les boîtiers de médiation ne peuvent changer que ce qu'ils 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. Dans IPv4, il pourrait également supprimer l'extension inconnue et transmettre le reste. IMO cette propriété rend la conception plus plutôt que moins extensible.

Que faire si je rencontre un type d'en-tête d'extension non reconnu?

À partir de la RFC 2460 :

Si, à la suite du traitement d'un en-tête, un nœud doit passer à l'en-tête suivant mais que la valeur de l'en-tête suivant dans l'en-tête actuel n'est pas reconnue par le nœud, il doit rejeter le paquet et envoyer un message ICMP Parameter Problem à la source du paquet , avec une valeur de code ICMP de 1 ("type d'en-tête suivant non reconnu") 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 d'en-tête suivant de zéro dans un 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, car:

1. Seul l'hôte de destination est autorisé à rejeter en fonction des en-têtes d'extensions non reconnus (à l'exception de cette exception mentionnée dans la question que vous avez liée )

2. Si votre nouvel en-tête d'extension est d'une manière ou d'une autre facultatif (cela vaut mieux), vous recevrez une erreur ICMP à ce sujet et 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 des boîtiers de médiation tels que le vôtre pourront travailler, au moins une partie du temps.

Gardez à l'esprit 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. Il devrait être trivial, ou du moins beaucoup plus facile, pour vous de gérer des options de destination inconnues.