1.4. The INFORMATIONAL Exchange

1.4 The INFORMATIONAL Exchange

À divers moments du fonctionnement d'une IKE SA, les pairs peuvent vouloir échanger des messages de contrôle concernant des erreurs ou des événements. IKE définit pour cela l'échange INFORMATIONAL. Les échanges INFORMATIONAL DOIVENT avoir lieu uniquement après les échanges initiaux et sont protégés cryptographiquement avec les clés négociées. Note : certains messages informationnels, pas des échanges, peuvent être envoyés hors contexte IKE SA. La section 2.21 détaille aussi les messages d'erreur.

Les messages de contrôle relatifs à une IKE SA DOIVENT être envoyés sous cette IKE SA. Ceux relatifs aux Child SAs DOIVENT être envoyés sous l'IKE SA qui les a créées (ou son successeur si l'IKE SA a été rekeyée).

Les messages d'un échange INFORMATIONAL contiennent zéro ou plusieurs charges Notification, Delete et Configuration. Le destinataire d'une requête INFORMATIONAL DOIT envoyer une réponse ; sinon l'émetteur supposera une perte et retransmettra. Cette réponse PEUT être vide. La requête PEUT aussi ne contenir aucune charge ; c'est la manière habituelle de vérifier que l'autre extrémité est vivante.

L'échange INFORMATIONAL est défini comme suit :

Initiator                         Responder
-------------------------------------------------------------------
HDR, SK {[N,] [D,]
    [CP,] ...}  -->
                               <--  HDR, SK {[N,] [D,]
                                        [CP,] ...}

Le traitement dépend des charges présentes.

1.4.1. Deleting an SA with INFORMATIONAL Exchanges

Les SA ESP et AH existent toujours par paires, une par sens. À la fermeture, les deux membres de la paire DOIVENT être fermés (supprimés). Chaque extrémité DOIT fermer ses SA entrantes et laisser l'autre fermer l'autre moitié de chaque paire. Pour supprimer une SA, on envoie un échange INFORMATIONAL avec une ou plusieurs charges Delete listant les SPI (tels qu'attendus dans les en-têtes entrants). Le destinataire DOIT fermer les SA indiquées. On n'envoie jamais les Delete des deux côtés d'une SA dans un seul message. Pour plusieurs SA, on inclut les Delete pour la moitié entrante de chaque paire.

Normalement, la réponse contient les Delete des SA appariées dans l'autre sens. Exception : si les deux extrémités décident indépendamment de fermer et que les requêtes se croisent, un nœud qui reçoit une suppression pour des SA déjà en cours de suppression DOIT supprimer les SA sortantes en traitant la requête et les entrantes en traitant la réponse. Alors la réponse NE DOIT PAS contenir de Delete pour ces SA, pour éviter une double suppression.

Comme pour ESP/AH, les IKE SA se suppriment par échange INFORMATIONAL. Supprimer l'IKE SA ferme implicitement les Child SAs restantes. La réponse à une suppression d'IKE SA est une réponse INFORMATIONAL vide.

Des connexions ESP/AH semi-fermées sont anormales ; un nœud avec audit devrait les journaliser si elles persistent. Aucun délai n'est imposé par cette spécification. Un nœud PEUT refuser les données entrantes sur des connexions semi-fermées mais NE DOIT PAS les fermer unilatéralement et réutiliser les SPI. Si l'état est trop incohérent, un nœud PEUT fermer l'IKE SA comme ci-dessus et reconstruire les SA sur une nouvelle IKE SA propre.