2.1. Utilisation des temporisateurs de retransmission
2.1. Utilisation des temporisateurs de retransmission
Tous les messages dans IKE existent par paires : une requête et une réponse. La mise en place d'une IKE SA consiste normalement en deux échanges. Une fois l'IKE SA établie, chaque extrémité de l'Association de Sécurité peut initier des requêtes à tout moment, et il peut y avoir beaucoup de requêtes et de réponses « en vol » à un moment donné. Mais chaque message est étiqueté comme une requête ou une réponse, et pour chaque échange, une extrémité de l'Association de Sécurité est l'initiateur et l'autre est le répondeur.
Pour chaque paire de messages IKE, l'initiateur est responsable de la retransmission en cas d'expiration de délai. Le répondeur NE DOIT JAMAIS retransmettre une réponse à moins qu'il ne reçoive une retransmission de la requête. En ce cas, le répondeur DOIT ignorer la requête retransmise sauf dans la mesure où elle provoque une retransmission de la réponse. L'initiateur DOIT mémoriser chaque requête jusqu'à ce qu'il reçoive la réponse correspondante. Le répondeur DOIT mémoriser chaque réponse jusqu'à ce qu'il reçoive une requête dont le numéro de séquence est supérieur ou égal au numéro de séquence de la réponse plus la taille de sa fenêtre (voir Section 2.3). Afin de permettre d'économiser la mémoire, les répondeurs sont autorisés à oublier la réponse après un délai de plusieurs minutes. Si le répondeur reçoit une requête retransmise pour laquelle il a déjà oublié la réponse, il DOIT ignorer la requête (et ne pas, par exemple, tenter de construire une nouvelle réponse).
IKE est un protocole fiable : l'initiateur DOIT retransmettre une requête jusqu'à ce qu'il reçoive une réponse correspondante ou considère que l'IKE SA a échoué. Dans ce dernier cas, l'initiateur abandonne tout l'état associé à l'IKE SA et à toute Child SA négociée à l'aide de cette IKE SA. Une retransmission de l'initiateur DOIT être identique bit à bit à la requête originale. C'est-à-dire que tout ce qui commence à l'en-tête IKE (le SPI de l'initiateur IKE SA) DOIT être identique bit à bit ; les éléments le précédant (tels que les en-têtes IP et UDP) n'ont pas à être identiques.
Les retransmissions de la requête IKE_SA_INIT nécessitent un traitement spécial. Lorsqu'un répondeur reçoit une requête IKE_SA_INIT, il doit déterminer si le paquet est une retransmission appartenant à une IKE SA « à demi ouverte » existante (auquel cas le répondeur retransmet la même réponse), ou une nouvelle requête (auquel cas le répondeur crée une nouvelle IKE SA et envoie une réponse neuve), ou s'il appartient à une IKE SA existante où la requête IKE_AUTH a déjà été reçue (auquel cas le répondeur l'ignore).
Il n'est pas suffisant d'utiliser le SPI de l'initiateur et/ou l'adresse IP pour différencier ces trois cas car deux pairs différents derrière un même NAT pourraient choisir le même SPI d'initiateur. À la place, un répondeur robuste effectuera la recherche de l'IKE SA en utilisant le paquet entier, son hash, ou le payload Ni.
La politique de retransmission pour les messages unidirectionnels est quelque peu différente de celle des messages normaux. Comme aucun accusé de réception n'est jamais envoyé, il n'y a aucune raison de retransmettre gratuitement les messages unidirectionnels. Étant donné que tous ces messages sont des erreurs, il est logique de les envoyer une seule fois par paquet « fautif », et de ne les retransmettre que si d'autres paquets fautifs sont reçus. Toujours, il est également logique de limiter les retransmissions de tels messages d'erreur.