5.1. Traffic Selector Authorization (Autorisierung der Traffic Selectors)
5.1. Traffic Selector Authorization (Autorisierung der Traffic Selectors)
IKEv2 stützt sich bei der Festlegung, welche Arten von Child-SAs ein Peer anlegen darf, auf Informationen in der PAD (Peer Authorization Database, Peer-Autorisierungsdatenbank). Dieser Prozess ist in Abschnitt 4.4.3 von [IPSECARCH] beschrieben. Wenn ein Peer die Erstellung einer Child-SA mit bestimmten Traffic Selectors anfordert, muss die PAD „Child SA Authorization Data“ enthalten, die die von IKEv2 authentifizierte Identität mit den für Traffic Selectors zulässigen Adressen verknüpft.
Die PAD könnte beispielsweise so konfiguriert sein, dass die authentifizierte Identität „sgw23.example.com“ Child-SAs für 192.0.2.0/24 anlegen darf – dieses Sicherheitsgateway ist dann ein gültiger „Vertreter“ für diese Adressen. Host-zu-Host-IPsec erfordert ähnliche Einträge, etwa die Verknüpfung von „fooserver4.example.com“ mit 198.51.100.66/32, was bedeutet, dass diese Identität ein gültiger „Eigentümer“ oder „Vertreter“ der betreffenden Adresse ist.
Wie in [IPSECARCH] festgestellt, „ist es notwendig, diese Beschränkungen bei der Erstellung von Child-SAs zu erzwingen, um zu verhindern, dass ein authentifizierter Peer IDs vortäuscht, die anderen legitimen Peers zugeordnet sind“. Im obigen Beispiel verhindert eine korrekte PAD-Konfiguration, dass sgw23 Child-SAs mit Adresse 198.51.100.66 anlegt, und verhindert, dass fooserver4 Child-SAs mit Adressen aus 192.0.2.0/24 anlegt.
Es ist wichtig zu beachten, dass das bloße Senden von IKEv2-Paketen mit einer bestimmten Adresse keine Erlaubnis bedeutet, Child-SAs mit dieser Adresse in den Traffic Selectors anzulegen. Selbst wenn sgw23 seine IP-Adresse als 198.51.100.66 vortäuschen könnte, könnte er keine Child-SAs erstellen, die zum Datenverkehr von fooserver4 passen.
Die IKEv2-Spezifikation legt nicht genau fest, wie IP-Adresszuweisung mit Konfigurationsnutzlasten mit der PAD zusammenspielt. Unsere Interpretation: Wenn ein Sicherheitsgateway eine Adresse per Konfigurationsnutzlast zuweist, legt es gleichzeitig einen temporären PAD-Eintrag an, der die authentifizierte Peer-Identität mit der neu zugewiesenen inneren Adresse verknüpft.
Es wurde erkannt, dass die korrekte Konfiguration der PAD in manchen Umgebungen schwierig sein kann. Wird IPsec beispielsweise zwischen zwei Hosts genutzt, deren Adressen dynamisch per DHCP (Dynamic Host Configuration Protocol) vergeben werden, ist es extrem schwierig sicherzustellen, dass die PAD für jede IP-Adresse den richtigen „Eigentümer“ angibt. Dazu bräuchte es einen Mechanismus, der Adresszuweisungen sicher vom DHCP-Server übermittelt und mit IKEv2-authentifizierten Identitäten verknüpft.
Aufgrund dieser Einschränkung haben einige Hersteller ihre PADs so konfiguriert, dass ein authentifizierter Peer Child-SAs mit Traffic Selectors anlegen darf, die dieselbe Adresse enthalten, die für IKEv2-Pakete verwendet wurde. In Umgebungen mit möglicher IP-Spoofing (d. h. fast überall) erlaubt dies praktisch jedem Peer, Child-SAs mit beliebigen Traffic Selectors anzulegen. Dies ist in den meisten Fällen keine angemessene oder sichere Konfiguration. Siehe [H2HIPSEC] für eine ausführliche Diskussion sowie zu den Grenzen von Host-zu-Host-IPsec im Allgemeinen.