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

113

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?

networking ip ipv6

— AdamIerymenko
source

10

Sur la base de cette question, il semble que je ne suis pas stupide et oui, je lis bien: il est (dans le monde réel) impossible d'ajouter un nouvel en-tête d'extension à IPv6. stackoverflow.com/questions/9847923/…

— AdamIerymenko

10

Et oui, il semble également que le calcul de la longueur de l'en-tête nécessite un parcours de liste chaînée: stackoverflow.com/questions/14762193/ ... Ne vous méprenez pas. IPv6 est génial et indispensable. Mais cela semble toujours osé.

— AdamIerymenko

3

La spécification (liée dans le commentaire du haut) indique que les routeurs ne sont pas censés regarder les en-têtes, donc ne devraient pas se soucier des en-têtes que vous ajoutez. Seul le nœud de destination est censé regarder les en-têtes.

— Anders E. Andersen

2

Juste une note: "hair-brained" est une orthographe assez déroutante, et "hare-brained" devrait être préféré (source: tfd )

— pzkpfw

2

Dans la mesure où il n'y a qu'une seule orthographe correcte, qui est 'lièvre'

— Alan B

33

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.

— arnt
source

97

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.

— Oliver Charlesworth
source

15

Bien. Je pensais que je perdais la tête. Alors oui, c'est vraiment une conception complètement non extensible ... du moins sans signalisation intrabande et autres hacks. C'est excusable dans un protocole d'application où vous contrôlez les deux extrémités et ne devez tenir compte que des nouvelles versions de votre application, mais pas dans quelque chose conçu pour durer ... des centaines d'années?

— AdamIerymenko

8

Avoir la capacité d'ignorer les en-têtes inconnus entraînerait des problèmes beaucoup plus compliqués. (Et si un proxy intermédiaire modifiait les en-têtes TCP sans connaissance d'un en-tête ESP encapsulant?) La simplicité l'emporte sur "extensible" dans ce cas!

— jman

4

@Max IPv6 a littéralement assez d'adresses pour en attribuer une à chaque atome de la Terre. Il n'y a pas de grille-pain connecté à Internet qui épuisera cet espace.

— Tyler McHenry

8

@Max Je ne dirai pas que nous n'aurons absolument jamais besoin d'IPv7, mais avec IPv6, nous avons suffisamment d'espace d'adressage pour donner à chaque millimètre cube de l'atmosphère terrestre (130000 km de haut) une adresse unique ... 100000 fois plus. Donc, je veux dire, une fois que nous commencerons à coloniser d'autres galaxies, nous pourrions avoir quelque chose à craindre, mais d'ici là, nous devrions être plutôt bons.

— cincodenada

4

Un peu de contexte manque:

With one exception, extension headers are not examined or processed by any node along a packet's delivery path, until the packet reaches the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field of the IPv6 header.

— Tobu

28

Il est (dans le monde réel) impossible d'ajouter un nouvel en-tête d'extension à IPv6.

Incorrect, car:

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 )
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.

— Andreas Klöckner
source

1

Et vous êtes certain que ce paquet ICMP passera par le NAT à l'expéditeur réel?

— Dexter

5

@Dexter ipv6 va tuer NAT ... j'espère

— Janus Troelsen

2

@Dexter: Ces paquets ICMP doivent arriver pour un certain nombre de raisons. Par exemple, si le MTU du tube a diminué (peut-être qu'une encapsulation de paquets s'est produite à cause de PPPoE ou d'un VPN) et que le paquet envoyé est trop volumineux, un paquet ICMP sera renvoyé indiquant que le paquet est trop volumineux.

— Bill Lynch

4

@JanusTroelsen tout le monde ne partage pas vos espoirs.

— Dexter

4

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.

— Michael Hampton
source