it-swarm.com.de

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.

Also lese ich etwas über das IPv6-Paketformat und ich mag ... nun ... ich musste es irgendwie immer und immer wieder lesen, um sicherzugehen, dass ich es war eigentlich richtig lesen. Es sieht für mich so aus, als müsste man 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 ansehen und so weiter, wie eine verknüpfte Liste, bis Sie das Ende erreicht haben. Wenn es Nutzlast gibt, wird es folgen.

Das Problem ist, dass es weder im festen Header noch in den Erweiterungsheadern ein Längenfeld gibt. Sie müssen über eine Tabelle mit Typen von Erweiterungsheadern und deren Größen verfügen, damit Sie diese verknüpfte Liste bis zum Ende verfolgen können.

Das kommt mir seltsam vor, vielleicht sogar wie ein Hasenhirn. Was ist, wenn ich auf einen nicht erkannten Erweiterungsheadertyp stoße? Was mache ich? Ich kenne seine Länge nicht. Ich schätze, ich muss das Paket auswerfen und blockieren, da ein Angreifer in einem Netzfilter, der das Paket durchlässt, dem Netzfilter entgehen kann, indem er einen falschen Header-Typ einfügt. Wenn das Protokoll jedoch jemals erweitert wird, muss jedes einzelne Stück IPv6-Header-Parsing-Software, das jemals geschrieben wurde, gleichzeitig aktualisiert werden, wenn die neue Erweiterung verwendet werden soll.

Wie kann ich IPv6-Header analysieren, wenn ich nicht weiß, welche Erweiterungen sie verwenden? Wie kann ich einen Header für eine unbekannte Erweiterung überspringen, da ich die Länge nicht kenne?

111
AdamIerymenko

Wenn Sie auf etwas stoßen, das Sie nicht analysieren können, müssen Sie Ihre Entscheidung treffen oder Ihre Aktion auf der Grundlage dessen 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 einige Header, von denen Sie noch nie gehört haben, dann die Payload, dann können Sie die Payload nicht analysieren. Die Bedeutung der Nutzdaten hängt im Prinzip von dem Header ab, den Sie nicht interpretieren können.

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

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

33
arnt

Was ist, wenn ich auf einen nicht erkannten Erweiterungstyp stoße?

From RFC 246 :

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

95

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

Falsch, weil:

  1. Nur der Zielhost darf aufgrund nicht erkannter Erweiterungsheader ablehnen (mit der Ausnahme, die in die Frage, die Sie verknüpft haben ).

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

28

Das Update RFC 6564 behandelt diesen Fall. Es beschreibt genau das Szenario, das Sie beschreiben, und gibt ein Format für alle neuen Erweiterungsheader (falls jemals definiert) an, mit denen Middleboxes 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 für Sie trivial oder zumindest viel einfacher sein, mit unbekannten Zieloptionen umzugehen.

4
Michael Hampton