2.19. Anfordern einer internen Adresse in einem fernen Netzwerk
2.19. Anfordern einer internen Adresse in einem fernen Netzwerk
Am häufigsten im Szenario Endpunkt-zu-Sicherheitsgateway auftretend, kann ein Endpunkt eine IP-Adresse im durch das Sicherheitsgateway geschützten Netzwerk benötigen und diese dynamisch zugewiesen bekommen müssen. Eine Anforderung für eine solche temporäre Adresse kann in jede Anfrage zur Erstellung einer Child-SA (einschließlich der impliziten Anfrage in Nachricht 3) eingeschlossen werden, indem ein CP-Payload beigefügt wird. Beachten Sie jedoch, dass üblicherweise nur eine einzige IP-Adresse während des IKE_AUTH-Austauschs zugewiesen wird. Diese Adresse besteht mindestens bis zur Löschung der IKE-SA.
Diese Funktion stellt die Adresszuweisung an einen IPsec-Remote-Access-Client (IRAC) bereit, der versucht, in ein durch einen IPsec-Remote-Access-Server (IRAS) geschütztes Netzwerk zu tunneln. Da der IKE_AUTH-Austausch eine IKE-SA und eine Child-SA erstellt, MUSS der IRAC die von der IRAS kontrollierte Adresse (und optional weitere Informationen über das geschützte Netzwerk) im IKE_AUTH-Austausch anfordern. Die IRAS kann eine Adresse für den IRAC aus beliebig vielen Quellen wie einem DHCP/BOOTP (Bootstrap Protocol)-Server oder ihrem eigenen Adresspool beziehen.
Initiator Responder
HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, CP(CFG_REQUEST), SAi2, TSi, TSr} --> <-- HDR, SK {IDr, [CERT,] AUTH, CP(CFG_REPLY), SAr2, TSi, TSr}
In allen Fällen MUSS der CP-Payload vor dem SA-Payload eingefügt werden. In Variationen des Protokolls, in denen es mehrere IKE_AUTH-Austausche gibt, MÜSSEN die CP-Payloads in die Nachrichten eingefügt werden, die die SA-Payloads enthalten.
CP(CFG_REQUEST) MUSS mindestens ein INTERNAL_ADDRESS-Attribut (entweder IPv4 oder IPv6) enthalten, darf (MAY) aber eine beliebige Anzahl zusätzlicher Attribute enthalten, die der Initiator in der Antwort zurückhaben möchte.
Zum Beispiel Nachricht vom Initiator zum Responder:
CP(CFG_REQUEST)= INTERNAL_ADDRESS() TSi = (0, 0-65535,0.0.0.0-255.255.255.255) TSr = (0, 0-65535,0.0.0.0-255.255.255.255)
HINWEIS: Traffic-Selektoren enthalten (Protokoll, Portbereich, Adressbereich).
Nachricht vom Responder zum Initiator:
CP(CFG_REPLY)= INTERNAL_ADDRESS(192.0.2.202) INTERNAL_NETMASK(255.255.255.0) INTERNAL_SUBNET(192.0.2.0/255.255.255.0) TSi = (0, 0-65535,192.0.2.202-192.0.2.202) TSr = (0, 0-65535,192.0.2.0-192.0.2.255)
Alle zurückgegebenen Werte sind implementierungsabhängig. Wie im obigen Beispiel zu sehen, KANN die IRAS auch andere Attribute senden, die nicht in CP(CFG_REQUEST) enthalten waren, und KANN nicht unterstützte optionale Attribute ignorieren.
Der Responder DARF KEIN CFG_REPLY senden, ohne zuvor ein CP(CFG_REQUEST) vom Initiator erhalten zu haben, weil wir nicht wollen, dass die IRAS eine unnötige Konfigurationssuche durchführt, falls der IRAC die ANTWORT nicht verarbeiten kann.
Im Fall, dass die Konfiguration der IRAS die Verwendung von CP für eine bestimmte Identität IDi verlangt, der IRAC jedoch versäumt hat, ein CP(CFG_REQUEST) zu senden, MUSS die IRAS die Anfrage fehlschlagen lassen und die Erstellung der Child-SA mit einem FAILED_CP_REQUIRED-Fehler beenden. FAILED_CP_REQUIRED ist für die IKE-SA nicht fatal; es führt lediglich zum Fehlschlag der Child-SA-Erstellung. Der Initiator kann dies korrigieren, indem er später eine neue Configuration-Payload-Anfrage startet. Es sind keine Daten mit dem FAILED_CP_REQUIRED-Fehler verbunden.