1.3.1. Créer de nouvelles SA enfants avec l'échange CREATE_CHILD_SA

1.3.1. Créer de nouvelles SA enfants avec l'échange CREATE_CHILD_SA

Une SA enfant peut être créée en envoyant une requête CREATE_CHILD_SA. La requête CREATE_CHILD_SA pour créer une nouvelle SA enfant est :

Initiator Responder

HDR, SK {SA, Ni, [KEi], TSi, TSr} -->

L'initiateur envoie la ou les offres SA dans la charge utile SA, un nonce dans la charge utile Ni, éventuellement une valeur Diffie-Hellman dans la charge utile KEi, et les sélecteurs de trafic proposés pour la SA enfant proposée dans les charges utiles TSi et TSr.

La réponse CREATE_CHILD_SA pour créer une nouvelle SA enfant est :

                         <--  HDR, SK {SA, Nr, [KEr],
                                  TSi, TSr}

Le répondeur répond (en utilisant le même identifiant de message pour répondre) avec l'offre acceptée dans une charge utile SA, et une valeur Diffie-Hellman dans la charge utile KEr si KEi a été inclus dans la requête et que la suite cryptographique sélectionnée inclut ce groupe.

Les sélecteurs de trafic pour le trafic à envoyer sur cette SA sont spécifiés dans les charges utiles TS de la réponse, qui peuvent être un sous-ensemble de ce que l'initiateur de la SA enfant a proposé.

La notification USE_TRANSPORT_MODE PEUT être incluse dans un message de requête qui inclut également une charge utile SA demandant une SA enfant. Elle demande que la SA enfant utilise le mode transport plutôt que le mode tunnel pour la SA créée. Si la requête est acceptée, la réponse DOIT également inclure une notification de type USE_TRANSPORT_MODE. Si le répondeur refuse la requête, la SA enfant sera établie en mode tunnel. Si cela est inacceptable pour l'initiateur, l'initiateur DOIT supprimer la SA. Remarque : sauf lors de l'utilisation de cette option pour négocier le mode transport, toutes les SA enfants utiliseront le mode tunnel.

La notification ESP_TFC_PADDING_NOT_SUPPORTED affirme que le point terminal émetteur n'acceptera pas les paquets contenant du bourrage de confidentialité du flux de trafic (TFC) sur la SA enfant en cours de négociation. Si aucun des points terminaux n'accepte le bourrage TFC, cette notification est incluse à la fois dans la requête et dans la réponse. Si cette notification n'est incluse que dans l'un des messages, le bourrage TFC peut encore être envoyé dans l'autre direction.

La notification NON_FIRST_FRAGMENTS_ALSO est utilisée pour le contrôle de la fragmentation. Voir [IPSECARCH] pour une explication plus complète. Les deux parties doivent accepter l'envoi de fragments non initiaux avant que l'une ou l'autre ne le fasse. Elle n'est activée que si la notification NON_FIRST_FRAGMENTS_ALSO est incluse à la fois dans la requête proposant une SA et dans la réponse l'acceptant. Si le répondeur ne souhaite pas envoyer ou recevoir de fragments non initiaux, il omet simplement la notification NON_FIRST_FRAGMENTS_ALSO de sa réponse, mais ne rejette pas la création de toute la SA enfant.

Une notification IPCOMP_SUPPORTED, traitée dans la section 2.22, peut également être incluse dans l'échange.

Une tentative échouée de créer une SA enfant NE DEVRAIT PAS démonter la SA IKE : il n'y a aucune raison de perdre le travail effectué pour mettre en place la SA IKE. Voir la section 2.21 pour une liste des messages d'erreur qui peuvent se produire si la création d'une SA enfant échoue.