Résumé

  • RFC 9611 autorise plusieurs Child SA ayant les mêmes TSi/TSr afin que des CPU ou files distincts disposent de clés et de compteurs de séquence indépendants, sans verrou partagé.
  • SA_RESOURCE_INFO signale l’appartenance au groupe ; sa donnée facultative ne sert qu’au débogage. Elle ne commande pas le CPU du pair. TS_MAX_QUEUE refuse seulement de nouveaux membres pour la combinaison de sélecteurs concernée.
  • La capacité exige d’autres preuves : installation entrante et sortante, liaison locale à la ressource, répartition des paquets, compteurs de rejeu et de perte, comportement au rekey et à la suppression, puis débit utile constaté.

Le nombre de SA donne une impression d’abondance. Huit lignes sont visibles, huit négociations ont abouti, les Traffic Selectors sont identiques. Pourtant, sept lignes peuvent rester presque inactives pendant que la première porte tout le trafic.

Ce n’est pas nécessairement une faute de protocole. RFC 9611 répond à une contrainte précise : partager un compteur de séquence et un état cryptographique entre de nombreux CPU impose des verrous qui détruisent une partie du parallélisme. Créer plusieurs Child SA régulières permet à chacune de posséder ses clés, son SPI et son espace de séquence. Le groupe partage une politique de trafic, pas une mémoire cryptographique.

L’échange IKEv2 apporte donc une déclaration utile et limitée. Le pair sait que les SA supplémentaires ne sont pas des doublons accidentels. Il ne sait pas comment l’autre machine distribue ses paquets, quelles files existent réellement, ni si un accélérateur traite le flux prévu.

Une politique commune, plusieurs réalités locales

Les membres du groupe doivent conserver les propriétés négociées par la première Child SA : algorithmes, TSi et TSr, mode, compression et enveloppe de sécurité. Cette égalité empêche qu’un ajout de capacité modifie discrètement la politique. Elle ne prouve pas que les deux extrémités ont le même nombre de ressources.

Un pair plus petit peut décider de ne pas installer une copie sortante qu’il n’utilisera jamais. Il doit néanmoins installer toutes les SA entrantes acceptées, car l’autre extrémité peut envoyer sur chacune. Une vue symétrique au niveau IKE peut ainsi cacher une installation asymétrique parfaitement permise.

La donnée facultative de SA_RESOURCE_INFO renforce cette séparation. Elle devrait distinguer les membres d’un même groupe, mais le pair ne doit l’employer que pour le débogage. Écrire le numéro réel du CPU révélerait l’architecture et pourrait aider à corréler une attaque avec une ressource. Surtout, cet identifiant ne possède aucune sémantique interopérable : il n’est ni une instruction de placement, ni une autorisation, ni une preuve d’exécution.

Le compteur indépendant est le mécanisme, pas le résultat

RFC 4303 relie les séquences ESP au traitement anti-rejeu. RFC 6479 montre que cette fenêtre est elle-même un élément d’implémentation mesurable. RFC 9611 ne contourne pas la sécurité ; il crée plusieurs domaines valides afin d’éviter qu’un compteur sortant unique impose une sérialisation globale.

Le document cite un gain observé, de 5 Gbit/s avec un CPU à 40–60 Gbit/s avec 25 à 30 CPU. Ce chiffre explique la motivation. Il n’engage aucun autre matériel, pilote, algorithme, taille de paquet ou distribution de flux. Une preuve locale doit rapprocher octets et paquets par SA, occupation des CPU ou files, échecs anti-rejeu, pertes, latence et débit reçu par l’application.

Une hausse agrégée peut masquer une direction encore sérielle. Une bonne répartition des CPU peut accroître le désordre et faire apparaître une limite de fenêtre de rejeu. Un accélérateur peut accepter plusieurs contextes mais conserver une seule file chaude. Le benchmark n’a de valeur que s’il nomme ces conditions.

La création à la demande produit ses propres pointes

Les SA peuvent être créées au démarrage ou lorsqu’un paquet déclenche un besoin. Pendant le tour d’aller-retour de négociation, une SA générique accessible à tous les CPU peut assurer la continuité. Le paquet peut aussi être relayé vers un CPU déjà équipé, au prix d’un surcoût.

Deux pairs peuvent déclencher simultanément des créations. Le paquet initial traverse la première SA ; sa réponse provoque une acquisition inverse. Lors d’un rekey, les nouvelles SA coexistent un temps avec les anciennes. Une limite égale au nombre physique de CPU bloquerait donc des transitions normales. RFC 9611 recommande au moins le double pour absorber ces cas.

Quand la combinaison TSi/TSr atteint sa limite, TS_MAX_QUEUE dit exactement cela. NO_ADDITIONAL_SAS serait trop large et pourrait laisser croire qu’aucune autre SA, même avec d’autres sélecteurs, n’est admise. La précision de l’erreur protège les choix futurs.

Supprimer n’explique pas comment revenir

Une SA liée à une ressource inactive peut être supprimée. Mais une implémentation dont les messages d’acquisition ne contiennent aucune identité de CPU ou de file peut perdre le signal nécessaire pour la recréer. La relever immédiatement risque une boucle si le pair la supprime encore ; ne jamais la relever laisse les deux machines sur la seule SA initiale.

La suppression prouve qu’un état a été retiré. Elle ne constitue pas une politique de restauration. Il faut un propriétaire, un déclencheur, un délai et un critère de retour à l’équilibre. RFC 2367 fournit le contexte de SADB_ACQUIRE; RFC 9611 recommande d’étendre localement ce déclencheur avec l’identité de ressource. Cette identité reste locale : elle sert à reconnecter la demande au moteur IKE, non à donner au pair un droit sur le matériel.

Le périmètre de confiance décide de l’admission

Le dispositif vise surtout des passerelles à fort volume dont les administrateurs entretiennent déjà une relation de confiance. Une multitude de SA consomme de l’état et peut ralentir la recherche dans la SAD. La demande distante a donc un coût local, ce qui justifie une limite par paire de sélecteurs.

Cette économie change dans un VPN d’accès distant : beaucoup de clients, moins de confiance réciproque et une possibilité plus forte de multiplier l’état. RFC 9611 déconseille les SA par CPU dans ce contexte et déconseille leur activation par défaut. Une optimisation entre passerelles ne doit pas devenir un multiplicateur de ressources piloté par un client.

La chaîne de réception crédible contient alors neuf pièces : intention de groupe, négociation, clés et séquences indépendantes, installation entrante, installation sortante, placement local, distribution des paquets, cycle rekey/suppression, débit livré. Aucune pièce ne peut emprunter le statut de la précédente.

Sources