Zusammenfassung

  • Die Fassung 08 des IPSECME-Arbeitsgruppenentwurfs vom 1. Oktober nennt nun ausdrücklich eine geschützte IKE-Nachricht auf einer neuen TCP-Verbindung mit anderer Quell-IP-Adresse und/oder anderem Port. Diese Verbindung dient allein der IKE SA; Quelladresse und Port der zugehörigen ESP SAs dürfen nicht wegen ihr geändert werden.
  • Bei erwartetem Verkehr in beide Richtungen kann das Ausbleiben eingehender ESP-Pakete auf ein mögliches Erreichbarkeitsproblem hinweisen. Ein verschlüsselter ESP-Ping bleibt eine alternative Prüfung. Weder Schweigen noch ein erfolgreicher IKE-Austausch sind allein ein Beweis über den Datenpfad.

Ein funktionierender Kontrollkanal ist noch kein funktionierender Tunnel. IKEv2 handelt Sicherheitsassoziationen aus und hält sie aufrecht; ESP transportiert die geschützten Pakete. Der Entwurf erlaubt, große IKE-Austausche über TCP zu führen, während ESP nach Möglichkeit direkt über IP oder UDP-Kapselung läuft. Das spart die Nachteile einer gemeinsamen TCP-Strecke für sämtliche Daten. Es trennt aber zugleich Fehlerzustände: Ein Netzgerät kann TCP passieren lassen, UDP verwerfen oder seine NAT-Zuordnung früher löschen.

Der konkrete Versionsunterschied liegt in Abschnitt 3.6. Fassung 07 sprach von einer geschützten IKE-Nachricht mit neuer Quelladresse oder neuem Port. Fassung 08 nennt den Fall einer neuen TCP-Verbindung mit geänderter Quell-IP und/oder geändertem Port. Ein Host außerhalb des NAT nutzt diese Verbindung nur für die IKE SA und darf die Quell-IP oder den Port keiner von ihr erzeugten ESP SA verändern. Kommt dagegen ein ESP-Paket von einem neuen Absender an und besteht die Integritätsprüfung, greift eine eigene Regel für den ESP-Zustand. Diese beiden Beobachtungen haben unterschiedliche Reichweite; das eine Ereignis darf nicht ungeprüft den Endpunkt des anderen Pfads umschreiben.

Die Idee getrennter Transporte selbst stand schon in früheren Fassungen. Der Initiator kann SEPARATE_TRANSPORTS in IKE_SA_INIT über UDP 4500 anbieten und nach Bestätigung durch den Responder spätere IKE-Nachrichten auf TCP verlagern. Bei einer bereits großen ersten Nachricht kann er auch auf TCP beginnen. ESP bleibt bei erfolgreicher Aushandlung auf direktem IP oder UDP, sofern erreichbar. Bestätigt ein über TCP kontaktierter Responder die Trennung nicht, müssen IKE und ESP gemeinsam TCP gemäß dem bestehenden RFC 9329 verwenden. Wer diesen Entwurf als neue Oktober-Erfindung beschreibt, übersieht die eigentliche Präzisierung.

Die zweite Änderung betrifft die Diagnose. Bei erwarteten bidirektionalen Daten ist fehlender eingehender ESP-Verkehr ein Hinweis auf ein mögliches Problem. Der bisher erwähnte verschlüsselte ESP-Ping bleibt als zusätzliche Prüfmöglichkeit bestehen. Ein untätiger Dienst, absichtlich einseitiger Verkehr oder ein falsch gewählter Messpunkt können ebenfalls Stille erzeugen. Der Entwurf weist deshalb nicht automatisch einer Firewall oder einem NAT die Schuld zu und berichtet auch keinen konkreten Sicherheitsvorfall.

Die NAT- und Erreichbarkeitsregeln im weiteren Text waren bereits angelegt. Eine IKE-TCP-Verbindung hält die UDP-NAT-Zuordnung des ESP-Pfads nicht offen; dafür sind eigenständige Keepalives nötig. Beginnt IKE über TCP, beweist die erfolgreiche Verhandlung die ESP-Erreichbarkeit nicht. Nach dem Aufbau der Child SA soll der Initiator ESP prüfen, sofern nicht andere Evidenz vorliegt. Lässt sich die Erreichbarkeit nicht bestätigen, muss er die IKE SA löschen und sie über TCP neu aufbauen, ohne den getrennten ESP-Transport erneut anzubieten.

Das ist eine Reaktion auf die Datenpfadprüfung, keine pauschale Folgerung aus einem erfolgreichen Handshake.

Datatracker führt das Dokument als aktiven Internet-Draft der Arbeitsgruppe mit beantragter Veröffentlichung. Ein verabschiedeter RFC ist es nicht; der Notify-Wert steht im Text noch auf Zuweisung. Für Produkteinsatz oder tatsächliche Ausfälle liefern die geprüften Quellen keinen Beleg. Berichtenswert ist die enger gezogene Grenze zwischen neuer Kontrollverbindung und unverändertem Datenzustand.

Quellen