Zusammenfassung

  • RFC 2406 zeichnete die ESP-Grenze feldgenau. Im Transportmodus blieb der ursprüngliche IP-Header außerhalb; im Tunnelmodus wurde das innere Datagramm geschützt, doch ein neuer äußerer Header blieb sichtbar. SPI und Sequence Number wurden ebenfalls nicht verschlüsselt.
  • Vertraulichkeit, Authentisierung und Replay-Abwehr waren getrennte Entscheidungen. Die verpflichtende Sequenznummer bewies keine aktivierte Empfangsprüfung, und Padding bot nur begrenzten Schutz vor Längenbeobachtung. Geschützte Nutzlast war kein Beleg für unsichtbare Beziehungen oder Anwendungsannahme.

Ein Tunnel kann die Namen der Reisenden verbergen und trotzdem seine beiden Bahnhöfe zeigen. Genau so schützte ESP ein inneres Datagramm, während das äußere Netz weiterhin wissen musste, wohin es den Tunnelverkehr brachte. Der Inhalt wechselte in einen geheimen Raum; die Hülle blieb Teil des öffentlichen Weges.

RFC 2406 veröffentlichte diese Architektur im November 1998. Das Encapsulating Security Payload bot eine Mischung aus Vertraulichkeit, Datenursprungsprüfung, verbindungsloser Integrität, Replay-Schutz und begrenzter Verkehrsflussvertraulichkeit. Welche Dienste tatsächlich galten, hing von der Security Association und vom Standort der Implementierung ab.

RFC 1827 von 1995 hatte zuvor eine Schale geliefert. Der SPI war das einzige transformunabhängige Pflichtfeld; einzelne Transform-Dokumente ergänzten Algorithmen und Felder. RFC 2406 erklärte, das kombinatorische Wachstum habe eine vollständigere Basisspezifikation nötig gemacht. Sequenznummer, Padding, Next Header, optionale Authentication Data und Verarbeitungsschritte wurden Teil des gemeinsamen Formats.

Gemeinsam bedeutete nicht gleichartig. Vertraulichkeit konnte ohne ESP-Authentisierung gewählt werden. Authentisierung konnte mit NULL-Verschlüsselung ohne Geheimhaltung arbeiten. Mindestens einer dieser Dienste war erforderlich. Replay-Schutz setzte Authentisierung voraus und wurde allein vom Empfänger je SA gewählt.

Auf der Leitung begann das Paket mit einem äußeren IPv4- oder IPv6-Header und Protokollnummer 50. Danach folgten 32-Bit-SPI und 32-Bit-Sequence-Number, anschließend Payload Data, Padding, Pad Length, Next Header und bei Auswahl Authentication Data.

Bei getrennten Algorithmen umfasste die Verschlüsselung Payload Data, Padding, Pad Length und Next Header. Äußerer IP-Header, SPI, Sequenznummer und abschließender ICV blieben außerhalb. Ein expliziter Initialisierungsvektor konnte am Anfang von Payload Data stehen; obwohl oft als Teil des Chiffrats bezeichnet, war er laut RFC gewöhnlich nicht selbst verschlüsselt.

Die Integritätsfläche war anders. Der ICV erfasste SPI, Sequence Number, Payload Data, Padding, Pad Length und Next Header, nicht aber das Feld Authentication Data. Verschlüsselung fand zuerst statt, also sah die Berechnung die geschützten Nutzlastfelder als Chiffrat. Der äußere IP-Header blieb auch von dieser Prüfung ausgenommen.

Im Transportmodus stand ESP hinter dem ursprünglichen IP-Header und vor dem höheren Protokoll. Ursprüngliche Adressen blieben sichtbar. Bei IPv6 lagen Erweiterungsheader vor ESP außerhalb des Schutzes; nach ESP angeordnete Destination Options konnten hineingelangen. Reihenfolge war damit eine Sicherheitsentscheidung.

Im Tunnelmodus wurde das gesamte ursprüngliche IP-Datagramm einschließlich innerem Header geschützt. Ein neuer äußerer Header adressierte aber die Tunnelenden. Beobachter verloren möglicherweise die Endteilnehmer, sahen weiterhin Gateways, Zeit, Größen und Mengen. Eine verborgene Beziehung wurde durch eine sichtbare Beziehung getragen.

Darum nannte RFC 2406 Verkehrsflussvertraulichkeit begrenzt. Sie erforderte Tunnelmodus und wirkte am besten an einem Security Gateway, das viele Teilnehmerströme aggregierte. Zusätzliches Padding konnte Nutzlastlängen unschärfer machen, kostete jedoch Bandbreite und verbarg weder Takt noch Volumen oder äußere Endpunkte vollständig.

Die Sequenznummer trennte Anwesenheit von Wirkung. Der Sender musste sie immer einsetzen und erhöhen. Der Empfänger durfte Replay-Prüfung dennoch deaktivieren. Eine steigende Zahl in einem Mitschnitt belegte deshalb keinen ausgeführten Sliding-Window-Entscheid.

Bei aktivem Replay-Schutz musste auch Authentisierung aktiv sein, weil eine ungeschützte Nummer veränderbar wäre. Der Empfänger konnte eine alte Zahl vorläufig ablehnen, durfte sein Fenster aber erst nach erfolgreichem ICV fortschreiben. Der belastbare Nachweis verband richtige SA, authentisierte Nummer und lokale Fensterentscheidung. Der Mitschnitt enthielt nur einen Teil.

Auch die Verarbeitungsfolge hielt die Richtlinie getrennt. Vor ESP musste die IPsec-Implementierung nach RFC 2401 eine passende SA auswählen. Erst danach kamen Kapselung, Padding, Verschlüsselung und optionale Authentisierung. Fragmentierung folgte dem ESP-Schritt. Eingangs musste zuerst zusammengesetzt werden; ein weiterhin fragmentiertes Paket war zu verwerfen.

Der Empfänger suchte aus Zieladresse, ESP und SPI eine gerichtete SA. Diese bestimmte Schlüssel, Algorithmen und Prüfungen. Ohne gültige SA wurde verworfen. Bei Authentisierung sollte der ICV vor Freigabe entschlüsselter Daten bestätigt sein. Ein gültiges ESP-Ergebnis ersetzte weder Eingangsrichtlinie noch Anwendungsergebnis.

Ohne Authentisierung konnte ein falsches SA-Mapping oder beschädigtes Chiffrat ungültige Ausgabe erzeugen, die IPsec nicht zwingend erkannte. Spätere Protokolle mussten sie entdecken. Parallelität von Entschlüsselung und Prüfung änderte daran nichts: Vor Abschluss der Verifikation durfte Klartext nicht weitergegeben werden.

„Auditierbar“ bedeutete ebenfalls nicht „protokolliert“. Systeme mit Audit-Funktion mussten ESP einbeziehen und die Steuerung erlauben; nicht jedes System musste Audit implementieren. Fehlende SA, unerwartetes Fragment, Sequenzüberlauf und ICV-Fehler konnten Ereignisse sein. Ob ein brauchbarer Datensatz erhalten blieb, entschied der Betrieb.

RFC 4303 ersetzte RFC 2406 im Jahr 2005. Es bewahrte die Grundtrennung von sichtbaren Feldern, Verschlüsselung, Integrität, Transport- und Tunnelmodus sowie empfangsseitigem Replay-Entscheid und ergänzte Extended Sequence Numbers, kombinierte Modi und ausdrückliches TFC-Padding. RFC 2406 ist daher Designgeschichte, keine heutige Algorithmusempfehlung.

Lu Hengs Maßstab der laufenden Wirkung verhindert die falsche Abkürzung. „ESP aktiviert“ sagt nicht, welcher Modus, welche Dienste, welche SA und welches Empfangsfenster wirklich wirkten oder was außen sichtbar und später angenommen wurde. Die Norm bot die Möglichkeit; erst der ausgeführte Pfad lieferte das Ergebnis.

Quellen