2.25. Collisions d'échanges

Comme les échanges IKEv2 peuvent être initiés par l'un ou l'autre pair, il est possible que deux échanges affectant la même SA se chevauchent partiellement. Cela peut conduire à une situation où les informations d'état de la SA ne sont pas temporairement synchronisées, et un pair peut recevoir une requête qu'il ne peut pas traiter normalement.

De toute évidence, l'utilisation d'une taille de fenêtre supérieure à 1 conduit à des situations plus complexes, en particulier si les requêtes sont traitées hors ordre. Cette section se concentre sur les problèmes qui peuvent surgir même avec une taille de fenêtre de 1, et recommande des solutions.

Une notification TEMPORARY_FAILURE DOIT être envoyée lorsqu'un pair reçoit une requête qui ne peut pas être complétée en raison d'une condition temporaire telle qu'une opération de rekeying. Lorsqu'un pair reçoit une notification TEMPORARY_FAILURE, il NE DOIT PAS réessayer immédiatement l'opération ; il DOIT attendre que l'émetteur puisse terminer l'opération ayant causé la condition temporaire. Le destinataire PEUT réessayer la requête une ou plusieurs fois sur une période de plusieurs minutes. Si un pair continue de recevoir TEMPORARY_FAILURE sur le même IKE SA après plusieurs minutes, il DEVRAIT conclure que les informations d'état ne sont pas synchronisées et fermer le IKE SA.

Une notification CHILD_SA_NOT_FOUND DOIT être envoyée lorsqu'un pair reçoit une requête de rekeying d'une Child SA qui n'existe pas. La SA que l'initiateur a tenté de rekeyer est indiquée par le champ SPI dans le payload Notify, qui est copié depuis le champ SPI dans la notification REKEY_SA. Un pair recevant une notification CHILD_SA_NOT_FOUND DEVRAIT supprimer silencieusement la Child SA (si elle existe encore) et envoyer une requête pour créer une nouvelle Child SA à partir de zéro (si la Child SA n'existe pas encore).

2.25.1. Collisions lors du rekeying ou de la fermeture de Child SA

Si un pair reçoit une requête de rekeying d'une Child SA qu'il est en train d'essayer de fermer, il DEVRAIT répondre avec TEMPORARY_FAILURE. Si un pair reçoit une requête de rekeying d'une Child SA qu'il est en train de rekeyer, il DEVRAIT répondre comme d'habitude, et DEVRAIT se préparer à fermer les SA redondantes plus tard en fonction des nonces (voir section 2.8.1). Si un pair reçoit une requête de rekeying d'une Child SA qui n'existe pas, il DEVRAIT répondre avec CHILD_SA_NOT_FOUND.

Si un pair reçoit une requête de fermeture d'une Child SA qu'il est en train d'essayer de fermer, il DEVRAIT répondre sans payload Delete (voir section 1.4.1). Si un pair reçoit une requête de fermeture d'une Child SA qu'il est en train de rekeyer, il DEVRAIT répondre comme d'habitude, avec un payload Delete. Si un pair reçoit une requête de fermeture d'une Child SA qui n'existe pas, il DEVRAIT répondre sans payload Delete.

Si un pair reçoit une requête de rekeying du IKE SA, et qu'il est en train de créer, rekeyer ou fermer une Child SA de ce IKE SA, il DEVRAIT répondre avec TEMPORARY_FAILURE.

2.25.2. Collisions lors du rekeying ou de la fermeture de IKE SA

Si un pair reçoit une requête de rekeying d'un IKE SA qu'il est en train de rekeyer, il DEVRAIT répondre comme d'habitude, et DEVRAIT se préparer à fermer les SA redondantes et à déplacer les Child SA héritées plus tard en fonction des nonces (voir section 2.8.2). Si un pair reçoit une requête de rekeying d'un IKE SA qu'il est en train d'essayer de fermer, il DEVRAIT répondre avec TEMPORARY_FAILURE.

Si un pair reçoit une requête de fermeture d'un IKE SA qu'il est en train de rekeyer, il DEVRAIT répondre comme d'habitude, et oublier sa propre requête de rekeying. Si un pair reçoit une requête de fermeture d'un IKE SA qu'il est en train d'essayer de fermer, il DEVRAIT répondre comme d'habitude, et oublier sa propre requête de fermeture.

Si un pair reçoit une requête de création ou de rekeying d'une Child SA alors qu'il est en train de rekeyer le IKE SA, il DEVRAIT répondre avec TEMPORARY_FAILURE. Si un pair reçoit une requête de suppression d'une Child SA alors qu'il est en train de rekeyer le IKE SA, il DEVRAIT répondre comme d'habitude, avec un payload Delete.