Zusammenfassung

  • RFC 7112 verlangt, dass das IPv6-Fragment mit Fragment Offset null die vollständige Header-Kette bis zum ersten Upper-Layer-Header enthält. Ein zustandsloser Filter sieht damit Protokoll und gegebenenfalls Ports, bevor er entscheidet.
  • Diese Vollständigkeit betrifft nur die Protokolleinleitung. Quellkonstruktion, Pfad-MTU, Gerätekonfiguration, ICMPv6 Type 4 Code 3, spätere Offsets, Überlappung, Timeout, Wiederzusammensetzung und Anwendungsergebnis bleiben getrennte Nachweise.

Eine Regel ohne ihr entscheidendes Feld

IPv6-Erweiterungsheader liegen zwischen dem Basis-Header und TCP, UDP oder einem anderen Protokoll der oberen Schicht. Jeder Next Header verweist auf das folgende Format. Wird ein langes Paket fragmentiert, kann die Schnittstelle vor dem Transport-Header liegen.

Für eine Firewall, die nur nach Adressen entscheidet, mag das belanglos sein. Eine Regel für einen bestimmten TCP-Port gerät dagegen in ein Dilemma. Leitet das Gerät den unvollständigen Anfang weiter, lässt es möglicherweise einen später sichtbaren, verbotenen Port zu. Verwirft es vorsorglich, trifft es womöglich erlaubten Verkehr. Die konfigurierte Regel ist vorhanden; ihr Tatbestand noch nicht.

Man könnte von jedem Zwischenknoten verlangen, Fragmente wieder zusammenzusetzen. Dann würden aber Zustand, Speicher, Wartezeiten und DoS-Risiken in den gesamten Pfad wandern. RFC 7112 setzt die Pflicht früher an: Der fragmentierende Host muss die gesamte IPv6-Header-Kette in das erste Fragment legen.

Das Fragment muss nicht alles offenlegen. Es muss sich nur bis zu jenem Protokoll vorstellen, dessen Felder ein nachfolgendes Gerät auswerten könnte.

Wo „vollständig“ endet

Die Kette beginnt beim ersten IPv6-Header, folgt null oder mehr Erweiterungsheadern und endet am ersten Header der oberen Schicht. Im Normalfall ist das TCP, UDP oder ICMPv6. Bei IPv6-in-IPv6 gilt der zweite IPv6-Header für diese Definition als Upper-Layer-Header. ESP beendet die Kette ebenfalls; ohne Folgeprotokoll tut es No Next Header.

Die Nutzdaten der oberen Schicht gehören nicht dazu. Der TCP-Header muss im ersten Stück liegen, nicht die gesamte TCP-Nutzlast. RFC 7112 verbietet deshalb weder große Inhalte noch Fragmentierung an sich. Die gemeinsame Header-Strecke muss lediglich in die Pfad-MTU passen.

Diese Begrenzung schützt vor überzogenen Sicherheitsversprechen. Ein sichtbarer Zielport reicht für eine Port-ACL. Er beweist nicht den Inhalt späterer Bytes. Eine syntaktisch korrekte Kette authentifiziert weder die Quelladresse noch einen Benutzer und sagt nichts über dessen Berechtigung aus.

Die Regel liefert ausreichende Evidenz für eine bestimmte Entscheidung. Sie macht diese Evidenz nicht universell.

Offset null bezeichnet Lage, nicht Herkunft

RFC 7112 definiert das erste Fragment mechanisch über den Offset null. Jedes Gerät kann den Wert selbst lesen, ohne eine zentrale Stelle und ohne die Wiederzusammensetzung abzuwarten.

Aber auch ein Angreifer kann null eintragen und eine formal vollständige Kette erzeugen. Fragment Identification und Quelladresse sind keine Signaturen. Der Filter erkennt den Aufbau; nicht die Person oder Organisation dahinter.

Die Behandlung bleibt deshalb lokal. Ein Betreiber erlaubt den sichtbaren Port, ein anderer sperrt ihn. Ein Zwischenknoten aktiviert das Verwerfen unvollständiger Ketten, ein anderer behält einen Kompatibilitätsmodus. Der Zielhost trifft seine eigene Empfangsentscheidung.

Genau das macht die Bedingung für eine dünne gemeinsame Schicht geeignet. Das Format ist gemeinsam und lokal prüfbar; die Richtlinie bleibt bei den Teilnehmern. Weder Standardisierungsorganisation noch Autor erben daraus Betriebsgewalt.

Drei Rollen, verschiedene Normwörter

Beim Sender ist die Formulierung eindeutig: Fragmentiert ein Host, muss die vollständige Kette in das erste Fragment. Das ist die Konstruktionspflicht.

Ein empfangender Host sollte ein unvollständiges erstes Fragment verwerfen und sollte, unter den allgemeinen ICMPv6-Regeln, einen Fehler senden. Für Rückwärtskompatibilität darf eine Implementierung eine Annahmeoption bereitstellen.

Ein Zwischenknoten wie Router oder Firewall darf verwerfen und darf den Fehler senden. Unterstützt er das Verwerfen, sollte er dessen Ein- und Ausschalten konfigurierbar machen. Aus dieser Staffelung wird weder ein universelles Zwangsfilter noch völlige Beliebigkeit.

Ein Vorfall muss die tatsächlich handelnde Rolle benennen. Gerät, Schnittstelle, Softwarestand, Parser, Regelrevision, Kompatibilitätsschalter und Beobachtungspunkt gehören zur Aussage. „Durch RFC 7112 blockiert“ ersetzt diese Daten nicht.

Code 3 benennt den Grund

Verwirft ein Host oder Zwischenknoten aus diesem Grund und signalisiert den Vorgang, verwendet er ICMPv6 Parameter Problem, Type 4, Code 3, Pointer null. Die IANA-Beschreibung nennt ausdrücklich die unvollständige IPv6-Header-Kette im ersten Fragment.

Der eigene Code schafft einen potenziellen Beleg. Entwickler können die zitierte Paketstelle mit dem erzeugten Fragment vergleichen. Betreiber können Anstiege mit einem Betriebssystem-Release, einer Tunneländerung oder einer neuen Erweiterungskette abgleichen. Tests können vollständige und absichtlich abgeschnittene Varianten gegenüberstellen.

Der Beleg ist nicht garantiert. Zwischenknoten müssen ihn nicht senden. ICMPv6-Regeln, Rate Limits und Rückwegfilter können ihn unterdrücken. Bei gefälschter Quelle landet er womöglich beim falschen Empfänger.

Kein Code 3 bedeutet daher nicht automatisch Annahme. Ein beobachteter Code identifiziert auch nicht von selbst das sendende Gerät. Erst Zeit, Schnittstelle, Capture, zitiertes Paket, lokaler Zähler und Konfigurationsversion machen ihn zurechenbar.

Der Pfad-MTU gehört in die Akte

Wenn alle Header bis zur oberen Schicht in das erste Fragment müssen, darf ihre Gesamtlänge die Pfad-MTU nicht überschreiten. RFC 7112 verlangt von Hosts ohne Pfad-MTU-Ermittlung eine Begrenzung auf 1280 Byte.

Eine Verletzung kann deshalb mehrere Ursachen haben. Ein absichtlicher Umgehungsversuch ist eine. Ein neues Overlay mit kleinerer effektiver MTU, ein veralteter Cache oder eine ungewöhnlich lange Erweiterungskette sind andere.

Der aktuelle MTU-Wert nach dem Vorfall ist nicht zwingend der Wert, den der Sender beim Bau verwendete. Erforderlich sind Zeitbezug, Tunnelstufe und möglichst eine Messung nahe der Quelle. Sonst wird aus einem Konstruktionsfehler vorschnell ein Sicherheitsurteil.

Header-Sicherheit und Größenplanung treffen sich an derselben Grenze. Das Monitoring sollte diese Verbindung abbilden.

Eingangskontrolle ist noch keine Wiederzusammensetzung

RFC 8200 übernahm die Regel in die IPv6-Basisspezifikation. Sein Modell trennt Header, die in jedem Fragment vorkommen, den Fragment-Header, die im ersten Fragment liegenden weiteren Erweiterungs- und Upper-Layer-Header sowie die verteilten Daten.

Am Ziel beginnt ein anderer Vorgang. Fragmente werden anhand von Quelle, Ziel und Fragment Identification zugeordnet. Offsets und Längen bestimmen ihre Position. Fehlen Teile 60 Sekunden lang, wird abgebrochen. Unzulässige Längen führen zu Fehlern. Bei Überlappung muss das gesamte Datagramm verworfen werden; exakte Dubletten dürfen separat erkannt und entfernt werden.

Ein vollständiger erster Header garantiert weder das letzte Stück noch überschneidungsfreie Daten. Eine erfolgreiche Wiederzusammensetzung garantiert noch keinen TCP- oder Anwendungserfolg.

Umgekehrt kann eine Firewall das erste Fragment verwerfen und spätere weiterleiten. Ohne Offset null kann das Ziel das Original nicht bilden. Die Zahl weitergeleiteter Folgefragmente ist daher kein Beweis für die Zulassung des Datagramms.

Die Akte braucht drei Ergebnisse: Header-Ketten-Prüfung, Reassembly und Dienst. Sie dürfen nicht in einem Status „Fragment erlaubt“ verschwinden.

Das atomare Fragment wartet nicht

RFC 6946, dessen Autor Fernando Gont ist, behandelt ein Fragment mit Fragment-Header, aber Offset null und M-Bit null. Dieses atomare Fragment ist bereits ein vollständiges Datagramm und erwartet kein weiteres Stück.

Manche Implementierungen mischten es dennoch in eine Reassembly-Warteschlange mit anderen Fragmenten derselben Quelle, desselben Ziels und derselben Identifikation. Das schuf einen Angriffsvektor. RFC 6946 verlangt unabhängige Verarbeitung; RFC 8200 hat sie übernommen.

Das ist nicht dieselbe Bedingung wie in RFC 7112. Ein unvollständiges erstes Fragment, ein vollständiges atomares Fragment und überlappende Stücke sind verschiedene Zustände. Sie benötigen verschiedene Beweise und Reparaturen.

Wer im Log nur „Fragment Header vorhanden“ speichert, verwirft die Felder, mit denen das Protokoll selbst die Fälle trennt: Offset, M, Identifikation, Kettenende und beobachtete Fragmentzahl.

Vom Zusatz zur Grundspezifikation

RFC 7112 aktualisierte 2014 RFC 2460. RFC 8200 löste den alten Text 2017 ab und schrieb die nach dem Fragment-Header folgenden Erweiterungsheader sowie den Upper-Layer-Header in das erste Fragment. Fehlen sie, soll verworfen und Code 3 gesendet werden.

RFC 9099 übersetzt die Architektur in Betriebspraxis. Firewalls, Sicherheitsgeräte und Ziele sollten erste Fragmente ohne vollständige Kette einschließlich Transport-Header verwerfen; sonst kann ein Angreifer zustandslose Filter umgehen.

Die Dokumentenfolge beweist die Entwicklung der Spezifikation. Sie beweist nicht, dass ein bestimmter ASIC eine lange Kette korrekt parst, ein altes Gerät seinen Kompatibilitätsmodus abgeschaltet hat oder ein Host ICMPv6 wie erwartet sendet.

Gebauter Testverkehr, Captures vor und nach dem Gerät, Zähler, versionierte Regeln und Dienstresultate belegen die lokale Adoption. Veröffentlichung ist eine Testanweisung, kein ausgefülltes Protokoll.

Fernando Gonts dokumentierter Beitrag

Fernando Gont ist einer von drei Autoren von RFC 7112. Vishwas Manral und Ron Bonica stehen ebenso im Dokument; der Standards-Track-Status beruht auf IETF-Prüfung und Konsens. Daraus folgt weder Alleinerfindung noch Verfügungsmacht über Implementierungen.

Sein aktuelles IETF-Profil listet 40 RFCs und Arbeiten zur Protokollsicherheit. RFC 6946 zeigt eine verwandte Methode: Zustände, die Implementierungen vermischten, werden getrennt und mit lokal lesbaren Kriterien versehen.

Bei RFC 7112 muss das erste Stück die notwendige Protokollgrenze zeigen. Bei RFC 6946 bleibt das atomare Stück außerhalb fremder Reassembly-Zustände. Das Dokument definiert die Funktion, das Gerät wählt die lokale Behandlung, das Ziel setzt zusammen und die Anwendung liefert das Ergebnis.

Das erste Fragment muss nicht die ganze Geschichte erzählen. Es muss nur ehrlich benennen, welches Protokoll die nächste Maschine vor sich hat.

Quellen