Zusammenfassung

  • RFC 1701 stellte in Aussicht, die vier Oktette der Key zur Authentisierung einer Paketquelle zu verwenden, definierte aber weder Erzeugung und Verteilung noch Schutz und Prüfung dieser Behauptung.
  • RFC 2890 machte daraus einen logischen Flow-Identifier innerhalb eines Tunnels und erklärte ausdrücklich, dass Key trotz ihres Namens keinerlei Sicherheitsfunktion besitzt. Sequence Number liefert Ordnung, nicht zuverlässige Zustellung.
  • Eine beliebige eingespeiste Sequence kann den Empfängerzustand vorziehen und echte Folgepakete alt aussehen lassen. Vertrauenswürdig werden K und S erst, wenn ein unabhängiger Mechanismus GRE-Header und Nutzlast gemeinsam schützt.

Ein Feldname ist noch keine Fähigkeit

Wer in einer Konfiguration das Wort Key liest, denkt an ein Geheimnis, einen Berechtigungsnachweis oder wenigstens an etwas, das nicht jeder kopieren kann. Ein gleiches Zahlenfeld wird dadurch leicht mit einem berechtigten Gegenüber gleichgesetzt. GRE bietet ein selten klares Gegenbeispiel.

RFC 1701 beschrieb 1994 eine allgemeine Kapselung eines Netzschichtprotokolls in einem anderen. Auf einen Delivery Header folgten GRE Header und Payload. Optional waren Prüfsumme, Routing-Information, Key und Sequence Number vorgesehen.

Die Key, so hieß es, könne vom Empfänger zur Authentisierung der Quelle verwendet werden. Die Verfahren zur Feststellung dieser Echtheit blieben vollständig außerhalb des Dokuments. Es gab keine Ableitung des Werts, keinen Austausch, keine Bindung an ein Endpunktepaar, keinen Änderungsschutz und keine Regel zur Erneuerung. Das Paket führte eine Zahl mit, aber nicht den Nachweis, der dieser Zahl Autorität gegeben hätte.

Auch Sequence Number blieb eine offene Schnittstelle. Sie konnte die Sendereihenfolge erkennen lassen; Erzeugung und Empfangssemantik waren jedoch nicht festgelegt. Ein gemeinsames Layout garantiert noch keine gemeinsame Zustandsentscheidung.

Der standardisierte Kern war absichtlich schmal

RFC 2784 nahm im März 2000 die Schnittmenge der bereits von mehreren Anbietern eingesetzten GRE-Verfahren. Der Basiskopf behielt das Checksum-Present-Bit, Version und Protocol Type. Letzterer benennt die Art der inneren Nutzlast. Er sagt nicht, warum sie in den Tunnel aufgenommen werden durfte.

Die früheren optionalen Bitpositionen wurden zur Kompatibilitätsgrenze. Ein reiner RFC-2784-Sender setzte reservierte Bits auf null. Ein Empfänger ohne RFC-1701-Unterstützung musste ein Paket verwerfen, wenn eines der Bits 1 bis 5 gesetzt war. Eigene Abschnitte hielten fest, wie alte und neue Implementierungen miteinander umgehen.

Das war keine Geschichtsbereinigung, sondern eine lokale Prüfmöglichkeit. Der Parser entschied nach dem Regelwerk, das er tatsächlich ausführte, nicht nach Hersteller, Gerätenamen oder vermuteter Konfiguration am anderen Ende.

RFC 2890 entzog der Key ihre falsche Größe

Im September desselben Jahres aktualisierte RFC 2890 den Basiskopf. K zeigt eine vier Oktette breite Key an, S eine ebenso breite Sequence Number. Die Positionen entsprachen RFC 1701; ihre Kernwirkung war nun bestimmt.

Der Kapselungspunkt setzt die Key ein. Wie er sie erhält, bleibt außerhalb der Spezifikation. Der Entkapselungspunkt nutzt die Zahl, um innerhalb des Tunnels einen einzelnen logischen Traffic Flow zu erkennen, wenn dem inneren Paket für die lokale Behandlung Kontext fehlt. Pakete eines Flows verwenden denselben Wert.

Dieser Namensraum gehört zum Tunnelkontext. Dieselbe Zahl kann zwischen anderen Endpunkten etwas anderes bedeuten. Sie benennt weder Eigentümer noch Erlaubnis. Sie ist nicht geheim und trägt keine Signatur. Wer ein Paket einfügen oder verändern kann, kann auch vier sichtbare Oktette kopieren.

Die Security Considerations ziehen deshalb eine unmissverständliche Linie: Das Key-Feld ist trotz seines Namens an keinerlei Sicherheit beteiligt. Die Kompatibilität behielt das Wort; die neue Semantik entzog ihm die Rolle eines Ausweises.

Reihenfolge war eine begrenzte Empfängerleistung

S ergänzt einen freilaufenden 32-Bit-Zähler, beginnend bei null und umlaufend modulo 2^32. Der Empfänger merkt sich die Nummer des zuletzt erfolgreich entkapselten Pakets. Ist K vorhanden, gehört dieser Zustand zum durch die Key ausgewählten Flow.

Der direkte Nachfolger ist in der Reihenfolge. Ein alter oder doppelter Wert soll still verworfen werden. Ein Sprung nach vorn zeigt eine Lücke. Der Empfänger darf in einem kleinen Puffer je Flow kurz auf umsortierte Pakete warten. Läuft Zeit oder Platz ab, kann er die Lücke überspringen und mit den vorhandenen Paketen fortfahren.

RFC 2890 nennt das Ergebnis unzuverlässige, aber geordnete Zustellung. Sequence fordert keine fehlende Nutzlast erneut an und verspricht nicht, dass jede Nummer eintrifft. Der Puffer begrenzt nur die Entscheidung zwischen Warten und Weitergehen.

Eine Gesamtordnung des Tunnels entsteht nicht. Pakete ohne S dürfen sich einreihen; verschiedene Keys haben verschiedene Verläufe. Eine Lücke belegt daher nur, dass in diesem Flow-Zustand nicht jede vorherige Nummer erfolgreich entkapselt wurde. Verlust, starke Umordnung, Filterung, Neustart und Nichtsendung bleiben mögliche Ursachen.

Ein erfundener Zukunftswert konnte den Betrieb stoppen

Hat der Empfänger zuletzt 40 akzeptiert, kann ein eingespeistes Paket mit kopierter Key und weit vorausliegender Sequence zuerst eintreffen. Ohne externen Integritätsschutz schreibt es unter Umständen eine falsche Zukunft in den Empfängerzustand. Danach wirken echte Pakete veraltet und werden verworfen.

RFC 2890 beschreibt die Einspeisung beliebiger Sequenzwerte als Denial-of-Service-Gefahr. Als Schutz verlangt das Dokument einen getrennten IP-Sicherheitsmechanismus über GRE-Header und getunnelter Nutzlast. Entscheidend ist die Abdeckung: Gerade K und S, die Klassifikation und Zustand steuern, müssen authentisiert werden.

Sequence ist deshalb für sich kein Replay-Schutz. Ein Replay-Fenster wird erst sinnvoll, nachdem ein Paket als Mitglied einer geschützten Verbindung authentisiert ist. Ohne diese Vorprüfung kann der Angreifer den Maßstab setzen, an dem spätere echte Pakete scheitern.

Verschlüsselung ist wiederum eine andere Eigenschaft. Key verbirgt keine Nutzlast, und Sequence verschleiert kein Verkehrsmuster. Ob ein äußerer Schutz Integrität allein oder zusätzlich Vertraulichkeit liefert, entscheidet die Sicherheitsbeziehung.

Eine spätere Aktualisierung blieb bei ihrer eigenen Aufgabe

RFC 9601 von 2024 ist die zweite verzeichnete Aktualisierung von RFC 2784. Sie ordnet GRE als Shim zwischen IP-Headern den modernen Regeln für Explicit Congestion Notification zu und verlangt eine sichere Ingress-Konfiguration bei IPv4 oder IPv6 als äußerem Delivery Protocol.

Damit wächst die Key nicht. ECN überträgt Überlastungsinformation, Key wählt den Flow-Kontext, Sequence ordnet dort empfangene Pakete, und ein äußerer Schutz prüft Herkunft und Integrität. Ein Tunnel kann alle Pflichten gleichzeitig erfüllen; keine übernimmt die Beweiskraft der anderen.

RFC 9601 hält außerdem fest, dass GRE selbst keinen dynamischen Aufbau und keine eigene Konfiguration aushandelt. Statische Einstellungen oder andere Control-Plane-Protokolle schaffen die Beziehung. Ein Mitschnitt zeigt K und S, aber nicht den Auftrag, der den Wert zuwies oder den Peer zuließ.

Betriebsdaten müssen Ursache und Wirkung getrennt halten

Steigende Out-of-Sequence-Zähler können Umordnung, Duplikate, Puffermangel, Neustart, uneinheitliche Konfiguration oder Angriff bedeuten. Sie belegen zunächst nur eine Empfängerentscheidung. Für die Ursache braucht es den äußeren Endpunktkontext, die Key-Zuordnung, den vorherigen Zustand, Paketdaten und das Ergebnis des Integritätsschutzes.

Die dauerhafte Leistung von RFC 2890 ist diese Verkleinerung der Behauptung. Key liefert Kontext. Sequence liefert eine bedingte Ordnung. Sicherheit beginnt erst bei einem Verfahren, das Ursprung und Unverändertheit tatsächlich prüfen kann.

Quellen