3.4.3. Vérification du numéro de séquence

Toutes les implémentations AH DOIVENT prendre en charge le service anti-rejeu, bien que son utilisation puisse être activée ou désactivée par le récepteur sur une base par SA. L'anti-rejeu est applicable aux SA unicast ainsi qu'aux SA multicast. Cependant, cette norme ne spécifie aucun mécanisme pour fournir l'anti-rejeu pour une SA multi-émetteurs (unicast ou multicast). En l'absence de négociation (ou de configuration manuelle) d'un mécanisme anti-rejeu pour une telle SA, il est recommandé que la vérification du numéro de séquence par l'émetteur et le récepteur pour la SA soit désactivée (via négociation ou configuration manuelle), comme noté ci-dessous.

Si le récepteur n'active pas l'anti-rejeu pour une SA, aucune vérification entrante n'est effectuée sur le numéro de séquence. Cependant, du point de vue de l'émetteur, la valeur par défaut est de supposer que l'anti-rejeu est activé au niveau du récepteur. Pour éviter que l'émetteur ne fasse une surveillance inutile du numéro de séquence et une configuration de SA (voir section 3.3.2, "Génération du numéro de séquence"), si un protocole d'établissement de SA tel que IKE est employé, le récepteur DEVRAIT notifier l'émetteur, lors de l'établissement de la SA, si le récepteur ne fournira pas de protection anti-rejeu.

Si le récepteur a activé le service anti-rejeu pour cette SA, le compteur de paquets de réception pour la SA DOIT être initialisé à zéro lorsque la SA est établie. Pour chaque paquet reçu, le récepteur DOIT vérifier que le paquet contient un numéro de séquence qui ne duplique pas le numéro de séquence de tout autre paquet reçu pendant la durée de vie de cette SA. Cela DEVRAIT être la première vérification AH appliquée à un paquet après qu'il a été associé à une SA, pour accélérer le rejet des paquets en double.

Les doublons sont rejetés par l'utilisation d'une fenêtre de réception glissante. La façon dont la fenêtre est implémentée est une question locale, mais le texte suivant décrit la fonctionnalité que l'implémentation doit présenter.

Le bord "droit" de la fenêtre représente la valeur de numéro de séquence la plus élevée et validée reçue sur cette SA. Les paquets qui contiennent des numéros de séquence inférieurs au bord "gauche" de la fenêtre sont rejetés. Les paquets tombant dans la fenêtre sont vérifiés par rapport à une liste de paquets reçus dans la fenêtre.

Si l'option ESN est sélectionnée pour une SA, seuls les 32 bits de poids faible du numéro de séquence sont explicitement transmis, mais le récepteur emploie le numéro de séquence complet calculé en utilisant les 32 bits de poids fort pour la SA indiquée (de son compteur local) lors de la vérification du numéro de séquence reçu par rapport à la fenêtre de réception. En construisant le numéro de séquence complet, si les 32 bits de poids faible transportés dans le paquet sont inférieurs en valeur aux 32 bits de poids faible du compteur de numéro de séquence du récepteur, le récepteur suppose que les 32 bits de poids fort ont été incrémentés, passant à un nouveau sous-espace de numéro de séquence. (Cet algorithme accommode des écarts de réception pour une seule SA aussi grands que 2**32-1 paquets. Si un écart plus grand se produit, des vérifications heuristiques supplémentaires pour la re-synchronisation du compteur de numéro de séquence du récepteur PEUVENT être employées, comme décrit dans l'Annexe B.)

Si le paquet reçu tombe dans la fenêtre et n'est pas un doublon, ou si le paquet est à droite de la fenêtre, alors le récepteur procède à la vérification de l'ICV. Si la validation de l'ICV échoue, le récepteur DOIT rejeter le datagramme IP reçu comme invalide. Ceci est un événement auditable. L'entrée du journal d'audit pour cet événement DEVRAIT inclure la valeur SPI, la date/heure, l'adresse source, l'adresse de destination, le numéro de séquence, et (dans IPv6) l'ID de flux. La fenêtre de réception n'est mise à jour que si la vérification de l'ICV réussit.

Une taille de fenêtre MINIMALE de 32 paquets DOIT être prise en charge, mais une taille de fenêtre de 64 est préférée et DEVRAIT être employée comme valeur par défaut. Une autre taille de fenêtre (plus grande que le MINIMUM) PEUT être choisie par le récepteur. (Le récepteur NE notifie PAS l'émetteur de la taille de la fenêtre.) La taille de la fenêtre de réception devrait être augmentée pour les environnements à plus haute vitesse, indépendamment des problèmes d'assurance. Les valeurs pour les tailles de fenêtre de réception minimales et recommandées pour les appareils à très haute vitesse (par exemple, multi-gigabit/seconde) ne sont pas spécifiées par cette norme.