B3. Gestion de la perte de synchronisation
S'il y a une perte de paquets non détectée de 2^32 paquets consécutifs ou plus sur une seule SA, alors l'émetteur et le récepteur perdront la synchronisation des bits de poids fort, c'est-à-dire que les équations de l'Annexe B2.2. ne parviendront pas à produire la valeur correcte. À moins que ce problème ne soit détecté et traité, les paquets ultérieurs sur cette SA échoueront aux vérifications d'authentification et seront rejetés. La procédure suivante DEVRAIT être implémentée par toute implémentation IPsec (ESP ou AH) qui prend en charge l'option ESN.
Notez que ce type de perte de trafic étendue semble peu probable si une fraction significative du trafic sur la SA en question est TCP, car la source ne parviendrait pas à recevoir des ACK et cesserait d'envoyer bien avant que 2^32 paquets n'aient été perdus. De plus, pour toute application bidirectionnelle, même celles fonctionnant au-dessus d'UDP, une telle panne prolongée entraînerait probablement le déclenchement d'une forme de temporisation. Cependant, une application unidirectionnelle, fonctionnant sur UDP, pourrait manquer de retour qui provoquerait la détection automatique d'une perte de cette ampleur, d'où la motivation pour développer une méthode de récupération pour ce cas.
La solution que nous avons choisie a été sélectionnée pour:
- minimiser l'impact sur le traitement du trafic normal.
- éviter de créer une opportunité pour une nouvelle attaque par déni de service telle qu'elle pourrait se produire en permettant à un attaquant de forcer la diversion de ressources vers un processus de re-synchronisation.
- limiter le mécanisme de récupération au récepteur car l'anti-rejeu est un service uniquement pour le récepteur, et l'émetteur n'est généralement pas conscient que le récepteur utilise des numéros de séquence à l'appui de ce service optionnel. Il est préférable que les mécanismes de récupération soient locaux au récepteur. Cela permet également une compatibilité ascendante.
B3.1. Déclenchement de la re-synchronisation
Pour chaque SA, le récepteur enregistre le nombre de paquets consécutifs qui échouent à l'authentification. Ce comptage est utilisé pour déclencher le processus de re-synchronisation, qui devrait être effectué en arrière-plan ou en utilisant un processeur séparé. La réception d'un paquet valide sur la SA réinitialise le compteur à zéro. La valeur utilisée pour déclencher le processus de re-synchronisation est un paramètre local. Il n'y a aucune exigence de prendre en charge des valeurs de déclenchement distinctes pour différentes SA, bien qu'un implémenteur puisse choisir de le faire.
B3.2. Processus de re-synchronisation
Lorsque le point de déclenchement ci-dessus est atteint, un paquet "mauvais" est sélectionné pour lequel l'authentification est réessayée en utilisant des valeurs successivement plus grandes pour la moitié supérieure du numéro de séquence (Seqh). Ces valeurs sont générées en incrémentant de un pour chaque nouvelle tentative. Le nombre de nouvelles tentatives devrait être limité, au cas où il s'agirait d'un paquet du "passé" ou d'un faux paquet. La valeur limite est un paramètre local. (Parce que la valeur Seqh est implicitement placée après la charge utile AH (ou ESP), il peut être possible d'optimiser cette procédure en exécutant l'algorithme d'intégrité sur le paquet jusqu'au point final de la charge utile, puis en calculant différents ICV candidats en variant la valeur de Seqh.) L'authentification réussie d'un paquet via cette procédure réinitialise le comptage d'échecs consécutifs et définit la valeur de T à celle du paquet reçu.
Cette solution nécessite un support uniquement de la part du récepteur, permettant ainsi une compatibilité ascendante. De plus, parce que les efforts de re-synchronisation se produiraient soit en arrière-plan, soit utiliseraient un processeur supplémentaire, cette solution n'impacte pas le traitement du trafic et une attaque par déni de service ne peut pas détourner les ressources du traitement du trafic.