Les primitives de chiffrement protègent les datagrammes IP contre l'interception et la falsification. Les algorithmes modernes calculent une valeur de contrôle d'intégrité (ICV) qui valide l'authenticité de chaque trame individuelle. Cependant, authentifier des paquets de manière isolée ne protège pas les protocoles sans connexion contre les attaques par rejeu.

Sans un séquençage d'état rigoureux, un adversaire positionné sur le trajet réseau peut capturer des paquets chiffrés valides et transmettre des doublons vers la passerelle de destination. Ces paquets dupliqués réussissent la vérification cryptographique, gaspillent les cycles processeur, déstabilisent les automates d'états et provoquent des dénis de service. Pour éliminer cette vulnérabilité, le standard IPsec Encapsulating Security Payload (ESP, RFC 4303) impose un compteur séquentiel et un mécanisme de fenêtre glissante anti-rejeu.

Le rôle des numéros de séquence dans les tunnels chiffrés

Les tunnels sans connexion encapsulent les datagrammes IP de couche 3 dans des en-têtes IP ou UDP externes. Les routeurs intermédiaires aiguillant les paquets sur des chemins multiples, les flux arrivent fréquemment dans le désordre ou subissent des duplications passagères.

Au sein d'une association de sécurité IPsec (Security Association, SA), l'émetteur assigne un numéro de séquence strictement croissant à chaque paquet ESP transmis. Ce numéro remplit deux missions clés :

  1. Fournir une source d'entropie unique pour les vecteurs d'initialisation (IV) et nonces AEAD, évitant la réutilisation de flux de clés.
  2. Permettre à la passerelle réceptrice d'identifier les trames dupliquées et de rejeter les paquets situés hors de la plage acceptable.
+-----------------------------------------------------------------------------+
|                ENCAPSULATION D'UN PAQUET IPSEC ESP (RFC 4303)               |
+-----------------------------------------------------------------------------+
| En-tête IP externe | SPI (32 bits) | Numéro de séquence (32 bits) | Données |
+-----------------------------------------------------------------------------+

L'émetteur ne décrémente jamais la valeur du compteur au cours de la durée de vie d'une SA active. Dès que le compteur atteint son plafond, le système doit renégocier une nouvelle SA via IKEv2 avant d'émettre des données supplémentaires.

Mécanisme de la fenêtre glissante anti-rejeu IPsec ESP (RFC 4303)

Le réseau acheminant les paquets avec des retards variables, le récepteur IPsec ne peut pas rejeter aveuglément tout paquet ayant un numéro inférieur au précédent. La RFC 4303 décrit un algorithme de fenêtre glissante utilisant un masque de bits de largeur $W$, couramment configuré entre 32 et 1024 bits.

       <- Paquets obsolètes rejetés -> | <- Fenêtre glissante (Largeur W) -> | <- Futurs ->
  ... ---------------------------------+-------------------------------------+------------> Espace
                                       ^                                     ^
                                  (M - W + 1)                                M (Plus grand reçu)

Le nœud récepteur conserve deux variables fondamentales :

  • $M$ : le numéro de séquence le plus élevé ayant été validé avec succès.
  • Un masque binaire de taille $W$ : consignant l'état des $W - 1$ numéros précédant $M$.

Progression de la fenêtre et suivi d'état du masque de bits

À l'arrivée d'un paquet ESP portant le numéro $S$, le moteur anti-rejeu évalue $S$ par rapport aux bornes de la fenêtre avant d'engager le déchiffrement :

  • Cas 1 ($S > M$) : Le paquet est plus récent que tous les précédents. Le récepteur vérifie l'ICV. En cas de succès, la fenêtre avance en décalant le masque vers la gauche de $(S - M)$ crans, met à jour $M = S$ et positionne le bit $S$ à 1.
  • Cas 2 ($M - W + 1 \le S \le M$) : Le paquet se situe dans la fenêtre glissante. Le récepteur vérifie le bit à l'indice $(M - S)$. Si ce bit est déjà actif, le paquet est rejeté comme duplicata. S'il est libre, l'ICV est validée puis le bit passe à 1.
  • Cas 3 ($S < M - W + 1$) : Le paquet se situe à gauche de la fenêtre. Le récepteur l'écarte immédiatement sans déchiffrement et incrémente le compteur de rejets.

Règles de rejet des paquets ESP obsolètes et dupliqués

Le filtrage préalable au déchiffrement apporte une rentabilité majeure. En vérifiant la validité temporelle du numéro avant d'exécuter des calculs cryptographiques lourds, la passerelle bloque les paquets de rejeu malveillants avec une consommation CPU infime.

Les tentatives de saturation de ressources ciblant la passerelle VPN sont neutralisées dès l'entrée sur l'interface réseau. Les paquets légitimes retardés par des variations réseau restent acceptés tant que leur retard ne dépasse pas la profondeur $W$.

Épuisement de l'espace de séquence 32 bits à très haut débit

La spécification IPsec historique (RFC 2401) allouait 32 bits au numéro de séquence ESP. Un espace de 32 bits autorise $2^{32} - 1 \approx 4.29 \times 10^9$ paquets avant rebouclage. Cette limite devient critique sur les liens multifibres modernes :

Débit de liaison Taille de paquet Débit en paquets Temps avant épuisement 32 bits
1 Gbit/s 1400 octets 89.2 Kpps 13.3 heures
10 Gbit/s 1400 octets 892.8 Kpps 80.0 minutes
40 Gbit/s 1400 octets 3.57 Mpps 20.0 minutes
100 Gbit/s 1400 octets 8.92 Mpps 8.0 minutes
100 Gbit/s 64 octets 148.8 Mpps 28.8 secondes

Lorsqu'une SA épuise son espace séquentiel sans prise en charge des numéros étendus, la transmission s'interrompt le temps qu'IKEv2 négocie une nouvelle SA. Ces renégociations répétées surchargent le processeur et génèrent des micro-coupures de service.

Numéros de séquence étendus ESN : intégrité 64 bits sans surcoût

Les standards RFC 4303 et RFC 4304 introduisent les numéros de séquence étendus (Extended Sequence Numbers, ESN), élargissant l'espace à 64 bits ($2^{64} - 1 \approx 1.84 \times 10^{19}$ paquets). À 100 Gbit/s avec des trames minimales, un compteur 64 bits garantit des millénaires d'acheminement ininterrompu.

L'atout majeur d'ESN réside dans la préservation stricte du format de paquet sur le câble. L'en-tête ESP continue d'acheminer uniquement les 32 bits de poids faible ($Seq_{low}$).

+-----------------------------------------------------------------------------+
|               ARCHITECTURE DES NUMÉROS DE SÉQUENCE ÉTENDUS (ESN)            |
+-----------------------------------------------------------------------------+
| Transmis sur le réseau :    [ SPI (32 bits) ] [ Numéro séquentiel bas 32 b ]|
| Conservé en mémoire :       [ Numéro séquentiel haut 32 bits ]              |
| Couvert par l'ICV :         [ 32 bits hauts implicites ] + [ Trame ESP ]    |
+-----------------------------------------------------------------------------+

Reconstruction des bits de poids fort via l'état implicite

Comme seul $Seq_{low}$ voyage sur le câble, le récepteur déduit les 32 bits de poids fort ($Seq_{high}$) à partir de la position de la fenêtre :

  1. Si $Seq_{low} \ge M_{low}$, le paquet appartient au cycle courant, donc $Seq_{high} = M_{high}$.
  2. Si $Seq_{low} < M_{low}$ tout en restant dans la fenêtre, le récepteur associe $Seq_{low}$ à $M_{high}$.
  3. Quand $M_{low}$ s'approche de $2^{32} - 1$, le système détermine si le paquet ouvre le cycle $M_{high} + 1$ ou constitue un retardataire du cycle $M_{high}$.

Pour écarter toute désynchronisation hostile, l'ICV englobe la valeur 64 bits complète. Si un tiers tente d'injecter des numéros falsifiés lors de la transition, la vérification d'intégrité échoue immédiatement et le paquet est détruit.

Routage multi-files RSS et désordonnancement sur passerelle multicœur

Les passerelles actuelles répartissent le trafic entrant entre les cœurs CPU grâce au Receive Side Scaling (RSS). Sur des flux ouverts, le RSS calcule un hachage sur cinq champs. Mais dans les paquets ESP chiffrés, les ports de transport restent masqués à l'intérieur du tunnel.

Les cartes réseau calculent donc leur empreinte RSS uniquement d'après l'IP source, l'IP destination et le champ SPI 32 bits.

[ Flux de paquets ESP ] ---> [ Hachage RSS matériel (IP + SPI) ]
                                      |
                      +---------------+---------------+
                      v                               v
               [ Cœur CPU 0 ]                  [ Cœur CPU 1 ]
               (Chiffrement)                   (Chiffrement)
                      \                               /
                       +-------------> <-------------+
                                      |
                      [ Arrivée désordonnée des paquets ]
                                      v
                    [ Contrôle de la fenêtre anti-rejeu ]

Conflits de verrous et pertes de paquets avec fenêtres classiques

Lorsque plusieurs cœurs processeur traitent en parallèle les trames d'une même SA à haut débit, de petites variations d'exécution provoquent un désordonnancement. Un paquet confié au Cœur 1 peut arriver au moteur anti-rejeu avec des centaines de numéros d'avance sur celui du Cœur 0.

Si la largeur $W$ de la fenêtre conserve sa valeur par défaut de 32 ou 64 paquets, ce décalage entraîne des rejets destructeurs :

  • Le Cœur 1 propulse $M$ de 120 positions vers l'avant.
  • Le Cœur 0 livre ensuite un paquet retardé $S < M - W + 1$.
  • La passerelle qualifie par erreur ce paquet légitime d'obsolète et le jette.

Ces faux rejets déclenchent des retransmissions rapides TCP et effondrent la fenêtre de congestion. Les techniciens réseau peuvent contrôler leurs adresses publiques avec l'outil mon adresse IP.

Masques extensibles : optimisation RFC 6479 pour tunnels haute charge

L'algorithme de fenêtre glissante classique opère un décalage linéaire du masque binaire lors de l'arrivée d'un numéro plus récent. Pour des fenêtres de 32 ou 64 bits, l'opération s'effectue en une instruction machine (bitmask <<= shift).

Pour absorber le désordonnancement multicœur, il faut porter $W$ à 1024 ou 4096 paquets. Décaler un bloc de 4096 bits pour chaque paquet entrant saturerait le bus mémoire et saturerait le cache L1/L2.

La RFC 6479 résout cette difficulté par un tampon circulaire sans décalage binaire :

+-----------------------------------------------------------------------------+
|               TAMPON CIRCULAIRE DE MASQUE DE REJEU SELON RFC 6479           |
+-----------------------------------------------------------------------------+
| Bloc 0 (64 bits) | Bloc 1 (64 bits) | ... | Bloc N (64 bits)                |
+-----------------------------------------------------------------------------+
         ^                                      ^
   Index : (Seq / 64) % Nb_blocs          Pointeur de position courante

Dans la spécification RFC 6479 :

  • Le masque est fractionné en mots machine fixes de 32 ou 64 bits.
  • Le numéro du paquet est projeté vers un index de mot par arithmétique modulaire : index = (seq / 64) % nb_blocs.
  • Lorsque la fenêtre avance, l'algorithme réinitialise uniquement les mots traversés par le pointeur, évitant toute copie de mémoire de masse.
  • La recherche s'opère en temps constant $O(1)$, quelle que soit la largeur du tampon.

Configuration des fenêtres anti-rejeu sous Linux XFRM et BSD

Les systèmes d'exploitation modernes intègrent les commandes requises pour ajuster la taille de la fenêtre et activer ESN.

Sous Linux, le sous-système XFRM gère les états de sécurité via l'outil iproute2. Pour configurer une SA avec un tampon circulaire de 1024 paquets et ESN 64 bits :

# Configuration d'un état XFRM avec fenêtre de 1024 paquets et indicateur ESN
ip xfrm state add src 198.51.100.1 dst 203.0.113.1 \
    proto esp spi 0x1a2b3c4d reqid 1 mode tunnel \
    replay-window 1024 flag esn \
    aead "rfc4106(gcm(aes))" 0x0123456789abcdef0123456789abcdef01234567 128

Pour observer les paquets rejetés sur une passerelle Linux :

# Vérification des compteurs de rejet anti-rejeu sous Linux
ip -s xfrm state show spi 0x1a2b3c4d

Les informations affichées précisent la valeur de replay-window et le compteur d'erreurs replay. Si ce compteur s'incrémente lors de charges élevées sans trace d'attaque, la fenêtre configurée est trop étroite pour compenser le désalignement des cœurs.

Sous FreeBSD et OpenBSD, le réglage s'effectue via les variables sysctl du noyau :

# Ajustement de la profondeur de fenêtre IPsec sous BSD
sysctl net.inet.ipsec.esp_replaywindow=1024

Avec des démons comme StrongSwan, ESN s'active dans la configuration Child SA de phase 2 en ajoutant le modificateur esn (esp=aes256gcm128-esn!).

Comment RiceGuard résout le désordonnancement sans faille de rejeu

VPNRice intègre le moteur RiceGuard sur l'ensemble de ses serveurs passerelles mondiaux. Plutôt que d'imposer un arbitrage pénalisant entre filtrage strict et débit multicœur, RiceGuard met en œuvre un pipeline à tolérance dynamique.

[ Trafic utilisateur ] -> [ Affinité de flux RiceGuard ] -> [ Cœurs de chiffrement ]
                                 |
                                 v
            [ Matrice 4096 bits RFC 6479 ] -> [ Acheminement fluide sans rejet ]
  1. Affinité processeur par flux : RiceGuard analyse les identifiants de flux applicatifs avant encapsulation, affectant chaque session TCP ou UDP à un cœur processeur dédié. Cela préserve l'ordre séquentiel des paquets.
  2. Matrice adaptative 4096 bits : Lors de fluctuations sur les liaisons de transit BGP, RiceGuard adapte automatiquement son masque jusqu'à 4096 paquets selon la méthode RFC 6479, éradiquant les rejets accidentels.
  3. Synchronisation matérielle ESN : Les passerelles synchronisent les compteurs 64 bits directement sur puces cryptographiques dédiées, éliminant les baisses de débit à 100 Gbit/s.

Pour sécuriser vos échanges avec une stabilité exemplaire sur ordinateur et smartphone, installez l'application officielle.

Télécharger VPNRice.

Les spécialistes réseau gérant des liaisons inter-centres de données peuvent consulter notre dossier sur la détection de pannes en moins d'une seconde avec BFD et explorer le fonctionnement des fenêtres glissantes dans WireGuard. Par ailleurs, découvrez nos recommandations sur le contrôle de congestion TCP BBR.

Liste de contrôle pour passerelles IPsec à haut débit

La mise en place d'une protection anti-rejeu performante sur infrastructure critique impose une méthodologie rigoureuse :

  • Validation de la négociation ESN : Vérifiez que la configuration IKEv2 active ESN sur l'ensemble des propositions ESP Child SA afin d'empêcher l'épuisement du compteur 32 bits.
  • Élargissement de la fenêtre : Portez la largeur de fenêtre par défaut de 32/64 à au moins 512 ou 1024 paquets sur les liaisons supérieures ou égales à 1 Gbit/s.
  • Activation des masques RFC 6479 : Contrôlez que le noyau utilise un tableau circulaire pour éviter toute dégradation CPU liée aux décalages de mémoire.
  • Alignement du hachage RSS : Paramétrez les files d'attente réseau ou déployez l'encapsulation UDP (NAT-T RFC 3948) pour ventiler uniformément les flux symétriques sur les files matérielles.
  • Surveillance des erreurs de rejeu : Supervisez les métriques XfrmInReplayError (Linux SNMP) ou netstat -s -p esp dans Prometheus pour isoler les faux rejets dus aux gigue réseau.
  • Maintien impératif de l'ICV : Ne désactivez jamais la protection anti-rejeu (replay-window 0) dans le seul but de masquer le désordonnancement, sous peine d'exposer la passerelle à de graves dénis de service.