2.9. Traffic Selector Negotiation (Verhandlung von Traffic Selectors)

Empfängt ein RFC4301-konformes IPsec-Subsystem ein IP-Paket, das einem „protect“-Selektor in der SPD entspricht, schützt es das Paket mit IPsec. Ohne bestehende SA erstellt IKE sie. SPD-Pflege liegt außerhalb von IKE (einige Implementierungen aktualisieren die SPD im Zusammenhang mit IKE, siehe 1.1.3).

Traffic-Selector-(TS)-Payloads übermitteln Teile der SPD an den Peer. Sie MÜSSEN von der SPD zu IKE geliefert werden (z. B. PF_KEY [PFKEY], SADB_ACQUIRE). TS-Payloads legen Kriterien für Pakete fest, die über die neue SA laufen.

Das kann zur Konsistenzprüfung oder zur dynamischen SPD-Aktualisierung dienen.

Zwei TS-Payloads erscheinen in jeder Nachricht des Austauschs, der ein Child-SA-Paar erzeugt. Jeder enthält einen oder mehrere Traffic Selectors (Adressbereich IPv4/IPv6, Portbereich, IP-Protokoll-ID).

Der erste ist TSi (Initiator), der zweite TSr (Responder). TSi beschreibt die Quelle vom Initiator des Paares (oder das Ziel zum Initiator). TSr das Ziel zum Responder (oder die Quelle vom Responder). Beispiel: Tunnel 198.51.100.* nach 192.0.2.*: je ein Bereich pro Payload; bei Akzeptanz sendet der Responder identische TS zurück.

IKEv2 erlaubt dem Responder, eine Teilmenge des Vorschlags zu wählen (asymmetrische Konfigurationsupdates oder bewusst verschiedene Richtlinien).

Der Responder verengt die TS auf eine nicht-leere Teilmenge des Vorschlags. Unbekannte Typen werden ignoriert und nicht in der verengten Menge zurückgegeben.

Bei datengetriebener SA-Anforderung SOLLTE der Initiator in TSi und TSr zuerst einen sehr spezifischen TS mit Adressen des auslösenden Pakets setzen, dann breitere Bereiche. Ohne auslösendes Paket (z. B. Start) können die ersten Einträge Bereiche sein.

Verengung durch den Responder:

Kein akzeptabler Teil → TS_UNACCEPTABLE.
Alles akzeptabel → gleiche TSi/TSr zurück.
Erster Selektor akzeptabel → auf Teilmenge verengen, die die erste Wahl des Initiators enthält.
Sonst → irgendeine akzeptable Teilmenge von TSi/TSr.

Mehrere disjunkte akzeptable Teilmengen: Responder wählt willkürlich und KANN ADDITIONAL_TS_POSSIBLE mitschicken (ohne Daten). Nur bei abweichenden Konfigurationen.

Richtlinie verlangt eine SA pro Adresspaar, aber der Initiator lieferte keinen präzisen ersten TS → Responder rät oder SINGLE_PAIR_REQUIRED: Anfrage nur mit einem Adresspaar akzeptabel; Anforderer soll auf konkreten Verkehr eingrenzen.

Wenige Richtlinien verlangen SA pro Paar; wenn nur Teile der TS akzeptabel sind, SOLLTEN Responders verengen statt SINGLE_PAIR_REQUIRED.

2.9.1. Traffic Selectors Violating Own Policy

Der Initiator darf keine TS vorschlagen, die die eigene Richtlinie verletzen, sonst kann gültiger Verkehr verloren gehen. Dekorrelierte Richtlinien [IPSECARCH] verhindern das.

Beispiel: A sendet zu 198.51.100.66 über B mit AES, Rest des /24 mit 3DES; B akzeptiert alles. Schlägt A 3DES mit TSr für das ganze /24 vor, kann B von .66 senden, A verwirft. A hätte TSr aufteilen müssen.

Allgemein: Wenn der Initiator SA für X vorschlägt, aber Teilmenge X' mit dieser SA nicht akzeptiert, wohl aber mit anderer SA', kann gültiger Verkehr verloren gehen.

2.9.2. Traffic Selectors in Rekeying

Rekey ersetzt eine Child-SA: engere Selektoren auf der neuen SA würden auf der alten erlaubten Verkehr auf der neuen verwerfen. Die neue SA DARF keine engeren Selektoren haben. Engerer Bedarf = Richtlinienänderung; alte SA hätte danach gelöscht werden müssen.

Beim Rekey SOLLTE der Initiator dieselben TS wie die alte Child-SA oder eine Obermenge vorschlagen (aktive dekorellierte Richtlinie). Der Responder DARF nicht enger verengen als der aktuell genutzte Umfang.

Da Rekey nicht verengen kann, sind paketbasierte Selektoren nicht nötig und SOLLTEN nicht gesendet werden.