Analyse des en-têtes d'extension IPv6 contenant des extensions inconnues

Question

Je suis en train d'écrire un très simple filet de filtre, et arriver là où je veux analyser les en-têtes IPv6 pour correspondre à des choses comme ICMPv6 types, TCP/UDP numéros de port, etc.

Donc, je suis en train de lire à propos de l' IPv6 format des paquets en profondeur, et je suis un peu comme... eh bien... j'ai eu à le lire, encore et encore pour s'assurer que j'étais en train de lire ce droit. Il me semble que vous devez commencer avec les 40 octets en-tête fixe et de regarder son champ en-tête suivant. Ensuite, vous avez à regarder du côté de l'en-tête du champ en-tête suivant, et ainsi de suite, comme une liste liée, jusqu'à ce que vous atteignez la fin. Si il y a de la charge utile, il va suivre.

Le problème est qu'il n'y a pas de champ de longueur, soit dans l'en-tête fixe ou les en-têtes d'extension. Vous devez avoir un tableau d'en-tête d'extension types et tailles de sorte que vous pouvez chasser cette liste liée à la fin.

Ce qui me frappe comme une étrange et peut-être même écervelé de conception. Que faire si je rencontre une inconnue en-tête d'extension type? Que dois-je faire? Je ne sais pas sa longueur. Je suppose que je dois jeter le paquet et de le bloquer, car dans un filet de filtre permettant le paquet à travers permettrait à un attaquant d'échapper au filet de filtre en y incluant un faux type d'en-tête. Mais cela signifie que si le protocole est jamais étendu, chaque élément de l'en-tête IPv6 d'analyse des logiciels jamais écrites doivent être simultanément mis à jour 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 me passer d'un en-tête pour un inconnu extension, puisque je ne connais pas sa longueur?

Answer 1

Que faire si je rencontre une inconnue en-tête d'extension type?

À partir de la RFC 2460:

Si, en tant que résultat du traitement d'un en-tête, un noeud est nécessaire de procéder pour la prochaine tête de mais la Prochaine valeur d'en-Tête dans le courant de l'en-tête est non reconnue par le nœud, il doit rejeter le paquet et envoyer un ICMP Problème de Paramètre message à la source du paquet, avec un Code ICMP valeur de 1 (non reconnu"en-Tête Suivant le type de rencontre") et la ICMP Pointeur de champ contenant le décalage de la non reconnu valeur dans le paquet d'origine. La même action devrait être prise si un nœud rencontre un en-Tête Suivant la valeur de zéro dans un en-tête d'autres que un en-tête IPv6.

Answer 2

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

Le design est de cette façon parce qu'en IPv6, chaque en-tête d'extension "enveloppe" le reste du paquet. Si vous voyez l'en-tête de routage, puis quelques-tête, vous n'avez jamais entendu parler, la charge utile, alors vous ne peut pas analyser la charge utile. Le sens de la charge repose en principe sur l'en-tête, vous ne savez pas comment l'interpréter.

Les routeurs peuvent itinéraire de tels paquets, parce que tous ils ont besoin est l'en-tête de routage. L'inspection approfondie des paquets de gadgets et d'autres choses de ce genre ont besoin de savoir beaucoup de choses, mais alors que c'est leur destin de toute façon.

Edité pour ajouter: grâce à Cette conception, middleboxes ne peut changer ce qu'ils savent. Si un middlebox voit un en-tête, il ne sait pas, alors il n'a que deux options: la Rejeter ou la transmettre. En IPv4, il pourrait également supprimer l'inconnu de l'extension et de la passer sur le reste. IMO cette propriété rend la conception plus plutôt que moins extensible.

Answer 3

Il est dans le monde réel) impossible d'ajouter une nouvelle extension de l'en-tête IPv6.

Incorrect, parce que:

1. Seul l'hôte de destination est autorisé à rejeter basé sur méconnue des extensions d'en-têtes (avec une exception mentionnée dans la question que vous avez lié)

2. Si votre nouvelle extension d'en-tête est d'une certaine façon facultative (il vaut mieux), vous recevrez une erreur ICMP à ce sujet et d'essayer à nouveau sans elle.

Answer 4

La mise à jour de la RFC 6564 couvre ce cas. Elle définit exactement le scénario que vous décrivez et met en avant un format pour les nouveaux en-têtes d'extension (si jamais défini) qui middleboxes comme le vôtre sera en mesure de travailler avec, au moins de temps en temps.

Gardez à l'esprit qu'il n'est pas prévu d'étendre l'IPv6 par la création de nouveaux en-têtes d'extension, mais par l'ajout de nouvelles Options de Destination. Il doit être facile, ou au moins beaucoup plus facile pour vous de traiter avec des inconnus d'options de destination.