Zum Hauptinhalt springen

2.9. Aushandlung von Traffic-Selektoren

2.9. Aushandlung von Traffic-Selektoren​

Wenn ein RFC 4301-konformes IPsec-Subsystem ein IP-Paket empfängt, das mit einem "protect"-Selektor in seiner Security Policy Database (SPD) übereinstimmt, schützt das Subsystem dieses Paket mit IPsec. Wenn noch keine SA existiert, ist es die Aufgabe von IKE, sie zu erstellen. Die Wartung der SPD eines Systems liegt außerhalb des Bereichs von IKE, obwohl einige Implementierungen ihre SPD möglicherweise im Zusammenhang mit der Ausführung von IKE aktualisieren (Beispielszenario siehe Abschnitt 1.1.3).

Traffic Selector (TS)-Payloads ermöglichen es Endpunkten, einen Teil der Informationen aus ihrer SPD an ihre Peers zu kommunizieren. Diese MÜSSEN von der SPD an IKE übergeben werden (z. B. verwendet die PF_KEY-API [PFKEY] die Nachricht SADB_ACQUIRE). TS-Payloads legen die Auswahlkriterien für Pakete fest, die über die neu eingerichtete SA weitergeleitet werden. Dies kann in einigen Szenarien als Konsistenzprüfung dienen, um sicherzustellen, dass die SPDs konsistent sind. In anderen leitet es die dynamische Aktualisierung der SPD.

In den Nachrichten des Austauschs, der ein Child-SA-Paar erstellt, erscheinen jeweils zwei TS-Payloads. Jeder TS-Payload enthält einen oder mehrere Traffic-Selektoren. Jeder Traffic-Selektor besteht aus einem Adressbereich (IPv4 oder IPv6), einem Portbereich und einer IP-Protokoll-ID.

Der erste der beiden TS-Payloads wird TSi (Traffic Selector-initiator) genannt. Der zweite wird TSr (Traffic Selector-responder) genannt. TSi gibt die Quelladresse des vom Initiator des Child-SA-Paars weitergeleiteten Verkehrs (oder die Zieladresse des an den Initiator weitergeleiteten Verkehrs) an. TSr gibt die Zieladresse des an den Responder des Child-SA-Paars weitergeleiteten Verkehrs (oder die Quelladresse des vom Responder weitergeleiteten Verkehrs) an. Wenn beispielsweise der ursprüngliche Initiator die Erstellung eines Child-SA-Paars anfordert und den gesamten Verkehr aus dem Subnetz 198.51.100.* auf der Initiatorseite in das Subnetz 192.0.2.* auf der Responderseite tunneln möchte, würde der Initiator in jedem TS-Payload einen einzelnen Traffic-Selektor aufnehmen. TSi würde den Adressbereich (198.51.100.0 - 198.51.100.255) angeben und TSr den Adressbereich (192.0.2.0 - 192.0.2.255). Unter der Annahme, dass der Vorschlag für den Responder akzeptabel war, würde er identische TS-Payloads zurücksenden.

IKEv2 erlaubt dem Responder, eine Teilmenge des vom Initiator vorgeschlagenen Verkehrs auszuwählen. Dies kann geschehen, wenn die Konfigurationen der beiden Endpunkte aktualisiert werden, aber nur ein Ende die neuen Informationen erhalten hat. Da die beiden Endpunkte von unterschiedlichen Personen konfiguriert werden können, kann die Inkompatibilität selbst bei Fehlerfreiheit über einen längeren Zeitraum bestehen bleiben. Es erlaubt auch bewusst unterschiedliche Konfigurationen, wie etwa wenn ein Ende so konfiguriert ist, dass es alle Adressen tunneln und vom anderen Ende die aktuelle Liste erwartet.

Wenn der Responder eine Teilmenge des vom Initiator vorgeschlagenen Verkehrs auswählt, verengt er die Traffic-Selektoren auf eine Teilmenge des Vorschlags des Initiators (sofern die Menge nicht zur Nullmenge wird). Ist der Typ des vorgeschlagenen Traffic-Selektors unbekannt, ignoriert der Responder diesen Traffic-Selektor, sodass der unbekannte Typ nicht im verengten Satz zurückgegeben wird.

Um dem Responder in diesem Fall die Auswahl des passenden Bereichs zu ermöglichen, SOLLTE der Initiator, wenn er die SA aufgrund eines Datenpakets angefordert hat, als ersten Traffic-Selektor in jedem von TSi und TSr einen sehr spezifischen Traffic-Selektor aufnehmen, der die Adressen im die Anfrage auslösenden Paket enthält. Im Beispiel würde der Initiator in TSi zwei Traffic-Selektoren aufnehmen: der erste enthält den Adressbereich (198.51.100.43 - 198.51.100.43) sowie Quellport und IP-Protokoll aus dem Paket, und der zweite enthält (198.51.100.0 - 198.51.100.255) mit allen Ports und allen IP-Protokollen. Der Initiator würde analog zwei Traffic-Selektoren in TSr aufnehmen. Erstellt der Initiator das Child-SA-Paar nicht als Reaktion auf ein eintreffendes Paket, sondern etwa beim Start, gibt es möglicherweise keine spezifischen Adressen, die er für den initialen Tunnel anderen vorzieht. In diesem Fall können die ersten Werte in TSi und TSr Bereiche statt spezifischer Werte sein.

Der Responder führt die Verengung wie folgt durch:

o Erlaubt die Richtlinie des Responders nicht, einen Teil der vorgeschlagenen Traffic-Selektoren zu akzeptieren, antwortet er mit einer TS_UNACCEPTABLE-Benachrichtigung.

o Erlaubt die Richtlinie des Responders den gesamten von TSi und TSr abgedeckten Verkehr, ist keine Verengung nötig, und der Responder KANN dieselben TSi- und TSr-Werte zurückgeben.

o Erlaubt die Richtlinie des Responders die Annahme des ersten Selektors von TSi und TSr, dann MUSS der Responder die Traffic-Selektoren auf eine Teilmenge verengen, die die Erstwahl des Initiators einschließt. Im obigen Beispiel könnte der Responder mit TSi gleich (198.51.100.43 - 198.51.100.43) mit allen Ports und allen IP-Protokollen antworten.

o Erlaubt die Richtlinie des Responders nicht die Annahme des ersten Selektors von TSi und TSr, verengt der Responder auf eine akzeptable Teilmenge von TSi und TSr.

Bei der Verengung können mehrere akzeptable Teilmengen existieren, deren Vereinigung jedoch nicht akzeptabel ist. In diesem Fall wählt der Responder willkürlich eine davon und KANN eine ADDITIONAL_TS_POSSIBLE-Benachrichtigung in die Antwort aufnehmen. Die ADDITIONAL_TS_POSSIBLE-Benachrichtigung besagt, dass der Responder die vorgeschlagenen Traffic-Selektoren verengt hat, dass aber andere Traffic-Selektoren ebenfalls akzeptabel gewesen wären, wenn auch nur in einer separaten SA. Es sind keine Daten mit diesem Benachrichtigungstyp verbunden. Dieser Fall tritt nur auf, wenn Initiator und Responder unterschiedlich konfiguriert sind. Einigen sich Initiator und Responder auf die Granularität der Tunnel, wird der Initiator nie einen breiteren Tunnel anfordern, als der Responder akzeptiert.

Es ist möglich, dass die Richtlinie des Responders mehrere kleinere Bereiche enthält, die alle vom Traffic-Selektor des Initiators umfasst werden, und dass die Richtlinie des Responders besagt, dass jeder dieser Bereiche über eine andere SA gesendet werden sollte. Das obige Beispiel fortsetzend, könnte der Responder eine Richtlinie haben, diese Adressen zum und vom Initiator zu tunneln, könnte aber verlangen, dass jedes Adresspaar auf einer separat ausgehandelten Child-SA liegt. Hat der Initiator seine Anfrage nicht auf Basis des Pakets erzeugt, sondern etwa beim Start, gäbe es nicht die sehr spezifischen ersten Traffic-Selektoren, die dem Responder bei der Auswahl des korrekten Bereichs helfen. Es gäbe keine Möglichkeit für den Responder zu bestimmen, welches Adresspaar in diesen Tunnel aufgenommen werden sollte, und er müsste raten oder die Anfrage mit einer SINGLE_PAIR_REQUIRED-Benachrichtigung ablehnen.

Der Fehler SINGLE_PAIR_REQUIRED zeigt an, dass eine CREATE_CHILD_SA-Anfrage unannehmbar ist, weil ihr Sender nur Traffic-Selektoren akzeptiert, die ein einzelnes Adresspaar angeben. Vom Anfordernden wird erwartet, dass er mit der Anforderung einer SA nur für den spezifischen Verkehr antwortet, den er weiterzuleiten versucht.

Wenige Implementierungen haben Richtlinien, die separate SAs für jedes Adresspaar erfordern. Daher SOLLTEN Responder, wenn nur einige Teile der vom Initiator vorgeschlagenen TSi und TSr vom Responder akzeptiert werden, die Selektoren auf eine akzeptable Teilmenge verengen, anstatt SINGLE_PAIR_REQUIRED zu verwenden.

2.9.1. Traffic-Selektoren, die gegen die eigene Richtlinie verstoßen​

Beim Erstellen einer neuen SA muss der Initiator vermeiden, Traffic-Selektoren vorzuschlagen, die gegen seine eigene Richtlinie verstoßen. Wird diese Regel nicht befolgt, kann gültiger Verkehr verworfen werden. Wenn Sie die entkorrelierten (decorrelated) Richtlinien aus [IPSECARCH] verwenden, kann dieser Richtlinienverstoß nicht auftreten.

Dies wird am besten an einem Beispiel veranschaulicht. Angenommen, Host A hat eine Richtlinie, deren Wirkung ist, dass Verkehr an 198.51.100.66 über Host B verschlüsselt mit AES gesendet wird, und Verkehr an alle anderen Hosts in 198.51.100.0/24 ebenfalls über B gesendet wird, aber 3DES verwenden muss. Angenommen ferner, Host B akzeptiert jede Kombination aus AES und 3DES.

Wenn Host A nun eine SA vorschlägt, die 3DES verwendet, und ein TSr einschließt, das (198.51.100.0-198.51.100.255) enthält, wird dies von Host B akzeptiert. Nun kann Host B diese SA auch verwenden, um Verkehr von 198.51.100.66 zu senden, aber diese Pakete werden von A verworfen, da er für diesen Verkehr die Verwendung von AES verlangt. Selbst wenn Host A eine neue SA nur für 198.51.100.66 erstellt, die AES verwendet, kann Host B die erste SA für den Verkehr weiterhin frei verwenden. In dieser Situation

hätte Host A bei Vorschlag der SA seiner eigenen Richtlinie folgen und stattdessen ein TSr einschließen sollen, das ((198.51.100.0-198.51.100.65),(198.51.100.67-198.51.100.255)) enthält.

Allgemein gilt: Wenn (1) der Initiator einen Vorschlag "für Verkehr X (TSi/TSr), mache SA" macht, und (2) für eine Teilmenge X' von X der Initiator den Verkehr X' tatsächlich nicht mit SA akzeptiert, und (3) der Initiator bereit wäre, Verkehr X' mit einer SA' (!=SA) zu akzeptieren, kann gültiger Verkehr unnötig verworfen werden, da der Responder entweder SA oder SA' auf Verkehr X' anwenden kann.