2.19. Demande d'une adresse interne sur un réseau distant
2.19. Demande d'une adresse interne sur un réseau distant
Se produisant le plus souvent dans le scénario de terminal vers passerelle de sécurité, un terminal peut avoir besoin d'une adresse IP dans le réseau protégé par la passerelle de sécurité et peut avoir besoin que cette adresse soit assignée dynamiquement. Une demande pour une telle adresse temporaire peut être incluse dans toute demande de création d'une Child SA (y compris la demande implicite dans le message 3) en incluant un payload CP. Notez cependant qu'il est habituel de n'assigner qu'une seule adresse IP pendant l'échange IKE_AUTH. Cette adresse persiste au moins jusqu'à la suppression de la IKE SA.
Cette fonction fournit l'allocation d'adresse à un client d'accès distant IPsec (IRAC) essayant de tunnéliser dans un réseau protégé par un serveur d'accès distant IPsec (IRAS). Puisque l'échange IKE_AUTH crée une IKE SA et une Child SA, l'IRAC DOIT demander l'adresse contrôlée par l'IRAS (et optionnellement d'autres informations concernant le réseau protégé) dans l'échange IKE_AUTH. L'IRAS peut obtenir une adresse pour l'IRAC à partir de n'importe quel nombre de sources telles qu'un serveur DHCP/BOOTP (Bootstrap Protocol) ou son propre pool d'adresses.
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}
Dans tous les cas, le payload CP DOIT être inséré avant le payload SA. Dans les variations du protocole où il y a plusieurs échanges IKE_AUTH, les payloads CP DOIVENT être insérés dans les messages contenant les payloads SA.
CP(CFG_REQUEST) DOIT contenir au moins un attribut INTERNAL_ADDRESS (soit IPv4 soit IPv6) mais PEUT contenir tout nombre d'attributs supplémentaires que l'initiateur veut retournés dans la réponse.
Par exemple, message de l'initiateur au répondeur :
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)
NOTE : Les sélecteurs de trafic contiennent (protocole, plage de ports, plage d'adresses).
Message du répondeur à l'initiateur :
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)
Toutes les valeurs retournées seront dépendantes de l'implémentation. Comme on peut le voir dans l'exemple ci-dessus, l'IRAS PEUT également envoyer d'autres attributs qui n'étaient pas inclus dans CP(CFG_REQUEST) et PEUT ignorer les attributs non obligatoires qu'elle ne supporte pas.
Le répondeur NE DOIT PAS envoyer un CFG_REPLY sans avoir d'abord reçu un CP(CFG_REQUEST) de l'initiateur, car nous ne voulons pas que l'IRAS effectue une recherche de configuration inutile si l'IRAC ne peut pas traiter la RÉPONSE.
Dans le cas où la configuration de l'IRAS exige que CP soit utilisé pour une identité donnée IDi, mais que l'IRAC a omis d'envoyer un CP(CFG_REQUEST), l'IRAS DOIT faire échouer la demande, et terminer la création de la Child SA avec une erreur FAILED_CP_REQUIRED. Le FAILED_CP_REQUIRED n'est pas fatal pour la IKE SA ; il provoque simplement l'échec de la création de la Child SA. L'initiateur peut corriger cela en démarrant plus tard une nouvelle demande de payload de configuration. Il n'y a aucune donnée associée à l'erreur FAILED_CP_REQUIRED.