2.3. Taille de fenêtre pour les requêtes chevauchantes
2.3. Taille de fenêtre pour les requêtes chevauchantes
La notification SET_WINDOW_SIZE affirme que le point final émetteur est capable de conserver l'état pour de multiples échanges en cours, permettant au destinataire d'envoyer de multiples requêtes avant d'obtenir une réponse à la première. Les données associées à une notification SET_WINDOW_SIZE DOIVENT avoir une longueur de 4 octets et contenir la représentation big endian du nombre de messages que l'émetteur promet de conserver. La taille de fenêtre est toujours de une jusqu'à ce que les échanges initiaux soient terminés.
Un point final IKE DOIT attendre une réponse à chacun de ses messages avant d'envoyer un message ultérieur à moins qu'il n'ait reçu un message Notify SET_WINDOW_SIZE de son pair l'informant que le pair est prêt à maintenir l'état pour de multiples messages en cours afin de permettre un débit plus élevé.
Après qu'une IKE SA est établie, afin de maximiser le débit IKE, un point final IKE PEUT émettre de multiples requêtes avant d'obtenir une réponse à l'une d'elles, jusqu'à la limite fixée par la SET_WINDOW_SIZE de son pair. Ces requêtes peuvent se croiser sur le réseau. Un point final IKE DOIT être prêt à accepter et traiter une requête alors qu'il en a une en cours afin d'éviter un blocage dans cette situation. Un point final IKE peut également accepter et traiter de multiples requêtes alors qu'il en a une en cours.
Un point final IKE NE DOIT PAS dépasser la taille de fenêtre déclarée par le pair pour les requêtes IKE transmises. En d'autres termes, si le répondeur a déclaré une taille de fenêtre de N, alors lorsque l'initiateur doit faire une requête X, il DOIT attendre d'avoir reçu les réponses à toutes les requêtes jusqu'à la requête X-N incluse. Un point final IKE DOIT conserver une copie de (ou être capable de régénérer exactement) chaque requête qu'il a envoyée jusqu'à ce qu'il reçoive la réponse correspondante. Un point final IKE DOIT conserver une copie de (ou être capable de régénérer exactement) le nombre de réponses précédentes égal à sa taille de fenêtre déclarée au cas où sa réponse serait perdue et que l'initiateur en demanderait la retransmission en retransmettant la requête.
Un point final IKE supportant une taille de fenêtre supérieure à un devrait être capable de traiter les requêtes entrantes hors ordre afin de maximiser les performances en cas de défaillances réseau ou de réordonnancement des paquets.
La taille de fenêtre est normalement une propriété (éventuellement configurable) d'une implémentation particulière, et n'est pas liée au contrôle de congestion (contrairement à la taille de fenêtre dans TCP, par exemple). En particulier, ce que le répondeur doit faire lorsqu'il reçoit une notification SET_WINDOW_SIZE contenant une valeur plus petite que celle actuellement en vigueur n'est pas défini. Ainsi, il n'y a actuellement aucun moyen de réduire la taille de fenêtre d'une IKE SA existante ; on ne peut que l'augmenter. Lors du rekeying d'une IKE SA, la nouvelle IKE SA démarre avec une taille de fenêtre de 1 jusqu'à ce qu'elle soit explicitement augmentée en envoyant une nouvelle notification SET_WINDOW_SIZE.
La notification INVALID_MESSAGE_ID est envoyée lorsqu'un Message ID IKE en dehors de la fenêtre supportée est reçu. Ce message Notify NE DOIT PAS être envoyé dans une réponse ; la requête invalide NE DOIT PAS être acquittée. À la place, informez l'autre partie en initiant un échange INFORMATIONAL avec des données de notification contenant le Message ID invalide de quatre octets. L'envoi de cette notification est OPTIONNEL, et les notifications de ce type DOIVENT être limitées en débit.