Analysieren von IPv6-Erweiterungsheadern mit unbekannten Erweiterungen

Ich schreibe einen sehr einfachen Netzfilter und komme dahin, wo ich IPv6-Header analysieren möchte, um Dinge wie ICMPv6-Typen, TCP / UDP-Portnummern usw. abzugleichen.

Ich lese also ausführlich über das IPv6-Paketformat und ich denke, ich musste es immer wieder lesen, um sicherzugehen, dass ich es tatsächlich richtig gelesen habe. Mir scheint, Sie müssen mit dem festen 40-Byte-Header beginnen und sich das nächste Header-Feld ansehen. Dann müssen Sie sich das nächste Headerfeld des nächsten Headers usw. wie eine verknüpfte Liste ansehen, bis Sie das Ende erreichen. Wenn es Nutzlast gibt, wird es folgen.

Das Problem ist, dass weder im festen Header noch im Erweiterungsheader ein Längenfeld vorhanden ist. Sie müssen eine Tabelle mit Erweiterungsheadertypen und deren Größen haben, damit Sie diese verknüpfte Liste bis zum Ende verfolgen können.

Dies scheint mir ein seltsames, möglicherweise sogar hasenhirniges Design zu sein. Was passiert, wenn ich auf einen nicht erkannten Erweiterungsheadertyp stoße? Was mache ich? Ich weiß nicht, wie lang es ist. Ich denke, ich muss das Paket wegwerfen und blockieren, da in einem Netzfilter, der das Paket durchlässt, ein Angreifer dem Netzfilter ausweichen kann, indem er einen falschen Headertyp hinzufügt. Dies bedeutet jedoch, dass, wenn das Protokoll jemals erweitert wird, jede einzelne jemals geschriebene IPv6-Header-Parsing-Software gleichzeitig aktualisiert werden muss, wenn die neue Erweiterung verwendet werden soll.

Wie kann ich IPv6-Header analysieren, wenn ich die verwendeten Erweiterungen nicht kenne? Wie kann ich einen Header für eine unbekannte Erweiterung überspringen, da ich deren Länge nicht kenne?

Wenn Sie auf etwas stoßen, das Sie nicht analysieren können, müssen Sie Ihre Entscheidung treffen oder Ihre Aktion basierend auf dem ausführen, was Sie bereits analysiert haben.

Das Design ist so, weil in IPv6 jeder Erweiterungsheader den Rest des Pakets "umschließt". Wenn Sie den Routing-Header sehen, dann einen Header, von dem Sie noch nie gehört haben, dann die Nutzlast, dann können Sie die Nutzlast nicht analysieren. Die Bedeutung der Nutzlast hängt im Prinzip von dem Header ab, den Sie nicht interpretieren können.

Router können solche Pakete weiterleiten, da sie lediglich den Routing-Header benötigen. Deep Packet Inspection Gadgets und dergleichen müssen viel wissen, aber das ist sowieso ihr Schicksal.

Bearbeitet, um hinzuzufügen: Dieses Design bedeutet, dass Middleboxes nur das ändern können, was sie wissen. Wenn eine Middlebox einen Header sieht, den sie nicht kennt, hat sie nur zwei Möglichkeiten: Ablehnen oder Weitergeben. In IPv4 könnte es auch die unbekannte Erweiterung entfernen und den Rest weitergeben. IMO macht diese Eigenschaft das Design mehr als weniger erweiterbar.

Was passiert, wenn ich auf einen nicht erkannten Erweiterungsheadertyp stoße?

Aus RFC 2460 :

Wenn ein Knoten infolge der Verarbeitung eines Headers zum nächsten Header wechseln muss, der Wert für den nächsten Header im aktuellen Header jedoch vom Knoten nicht erkannt wird, sollte er das Paket verwerfen und eine ICMP-Parameterproblemmeldung an die Quelle senden des Pakets mit einem ICMP-Code-Wert von 1 ("nicht erkannter nächster Header-Typ gefunden") und dem ICMP-Zeigerfeld, das den Versatz des nicht erkannten Werts innerhalb des ursprünglichen Pakets enthält. Dieselbe Aktion sollte ausgeführt werden, wenn ein Knoten in einem anderen Header als einem IPv6-Header auf den Wert Next Header von Null stößt.

Es ist (in der realen Welt) unmöglich, IPv6 einen neuen Erweiterungsheader hinzuzufügen.

Falsch, weil:

1. Nur der Zielhost darf basierend auf nicht erkannten Erweiterungsheadern ablehnen (mit der einen Ausnahme, die in der von Ihnen verknüpften Frage erwähnt wird ).

2. Wenn Ihr neuer Erweiterungsheader in irgendeiner Weise optional ist (es sollte besser sein), erhalten Sie einen ICMP-Fehler darüber und können es ohne ihn erneut versuchen.

Das Update RFC 6564 deckt diesen Fall ab. Es beschreibt genau das von Ihnen beschriebene Szenario und legt ein Format für alle neuen Erweiterungsheader (falls vorhanden) fest, mit denen Middleboxen wie Ihre zumindest zeitweise arbeiten können.

Beachten Sie, dass IPv6 nicht durch Erstellen neuer Erweiterungsheader, sondern durch Hinzufügen neuer Zieloptionen erweitert werden soll. Es sollte trivial oder zumindest viel einfacher sein, mit unbekannten Zieloptionen umzugehen.