A3. Handling Loss of Synchronization due to Significant Packet Loss (Gestion de la perte de synchronisation due à une perte importante de paquets)

A3. Handling Loss of Synchronization due to Significant Packet Loss (Gestion de la perte de synchronisation due à une perte importante de paquets)

S'il y a une perte 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 la Section A2.2. ne parviendront pas à produire la valeur correcte. À moins que ce problème ne soit détecté et résolu, les paquets ultérieurs sur cette SA échoueront aux contrôles 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 est susceptible d'être détecté aux couches supérieures dans la plupart des cas, avant qu'IPsec n'ait à invoquer le type de mécanisme de re-synchronisation décrit en A3.1 et A3.2. Si une fraction importante du trafic sur la SA en question est TCP, la source ne parviendrait pas à recevoir les 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 déclencherait probablement une forme de délai d'expiration. Cependant, une application unidirectionnelle, fonctionnant sur UDP, pourrait manquer de retour d'information 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. Notez que les observations ci-dessus s'appliquent aux SA entre passerelles de sécurité, ou entre hôtes, ou entre hôte et passerelles de sécurité.

La solution que nous avons choisie a été sélectionnée pour:

• minimiser l'impact sur le traitement normal du trafic

• éviter de créer une opportunité pour une nouvelle attaque par déni de service qui pourrait se produire en permettant à un attaquant de forcer la déviation de ressources vers un processus de re-synchronisation

• limiter le mécanisme de récupération au récepteur -- parce que l'anti-rejeu est un service uniquement pour le récepteur, et l'émetteur n'est généralement pas conscient de savoir si le récepteur utilise des numéros de séquence pour prendre en charge 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.