Résumé

  • La RFC 9827 renomme le Transform Type 5 et ses identifiants 0 et 1, mais ne change ni les bits AH/ESP ni leur traitement. Elle transforme un choix ESN en vocabulaire général des propriétés de séquence.
  • Les identifiants 0 et 1 garantissent, à l’entrée du réseau, un compteur croissant, sans bouclage et unique à l’échelle de la SA. Ils rendent l’anti-rejeu possible ; ils ne prouvent pas qu’un récepteur l’utilise.
  • La génération par l’émetteur, le flux agrégé, l’observation à l’arrivée, l’authentification, la fenêtre locale et le rejet effectif sont autant de faits distincts. L’IV implicite et AGGFRAG ajoutent encore leurs propres exigences.

Un changement de nom qui réduit une confusion

La RFC 9827, publiée sur le Standards Track en novembre 2025, paraît minuscule. Elle renomme « Extended Sequence Numbers » en « Sequence Numbers ». La valeur 0 devient « 32-bit Sequential Numbers » et la valeur 1 « Partially Transmitted 64-bit Sequential Numbers ». Aucun octet n’est ajouté ; le traitement AH et ESP reste identique.

Cette sobriété est précisément son intérêt. L’ancien nom présentait le choix comme une simple opposition entre compteur 32 bits et ESN. Or IKEv2 négocie ici un ensemble de propriétés : taille logique, partie transmise, croissance, bouclage et unicité. D’autres formats peuvent conserver un champ sans garantir son unicité, transmettre davantage de bits, ou même ne plus avoir de numéro visible.

Le registre IANA matérialise ce futur. Les valeurs 0 et 1 conservent leurs contrats. La RFC 9838 a ajouté la valeur 2, « 32-bit Unspecified Numbers » : le champ est présent mais l’unicité de la SA n’est pas garantie. Les valeurs 3 à 1023 restent non attribuées et 1024 à 65535 sont réservées à l’usage privé. Une même famille de transform peut donc exprimer des propriétés incompatibles avec des usages de sécurité différents.

La bonne question d’exploitation n’est plus « ESN est-il pris en charge ? ». Elle devient : « quelle propriété exacte a été négociée, à quel périmètre, et quelle preuve ferme chaque étape suivante ? »

La propriété appartient aux paquets à l’entrée

La définition centrale de la RFC 9827 vise les propriétés des numéros de séquence des paquets IPsec d’une SA au moment où ces paquets entrent dans le réseau.

Le numéro peut être logique. Avec la valeur 1, seuls les 32 bits faibles voyagent ; les 32 bits forts sont reconstruits par le récepteur à partir de son historique authentifié. La propriété porte également sur l’ensemble des paquets de la SA, non sur la bonne conduite isolée de chaque émetteur. Deux moteurs ou deux émetteurs multicast peuvent chacun incrémenter sans faute leur compteur local et néanmoins choisir la même valeur sous la même SA.

Enfin, le point d’observation est antérieur aux effets du réseau. Une duplication en transit transforme un paquet unique à l’entrée en deux observations au récepteur. Le réordonnancement brise l’ordre d’arrivée sans briser l’ordre de génération. Une perte crée un trou. Un miroir ou deux points de capture peuvent compter deux fois le même objet.

La norme place donc chaque affirmation chez l’acteur capable de la tenir. L’émetteur contrôle l’allocation et l’injection. Le réseau transforme le trajet. Le récepteur contrôle sa décision locale. Dans l’esprit de la primauté du code en fonctionnement défendue par Heng Lu, une étiquette documente une réalité bornée ; elle ne crée pas les résultats qui se produisent après cette frontière.

« Adapté à l’anti-rejeu » n’est pas « anti-rejeu activé »

La valeur 0 décrit un compteur 32 bits croissant, transmis dans le champ Sequence Number, unique pendant la vie de la SA et interdit de bouclage. La valeur 1 décrit le même engagement sur 64 bits, avec seulement la moitié basse sur le fil. Ces deux contrats sont adaptés à la protection contre le rejeu.

Ils ne commandent pas la politique du destinataire. Les RFC 4301, 4302 et 4303 rendent le service anti-rejeu optionnel, SA par SA, au choix de chaque récepteur. Tous les produits conformes doivent savoir le mettre en œuvre, mais un récepteur peut le désactiver. Dans ce cas, aucun contrôle entrant du numéro n’est effectué.

S’il est actif, le contrôle utilise une fenêtre glissante. Les valeurs à gauche sont trop anciennes ; une valeur déjà marquée dans la fenêtre est un doublon ; une valeur plus récente et authentifiée peut déplacer le bord droit. La taille de cette fenêtre est locale et n’est pas annoncée à l’émetteur. Deux récepteurs d’un même flux peuvent donc tolérer un réordonnancement différent sans violer le contrat négocié.

Le mot « authentifiée » est essentiel. Un contrôle préliminaire peut éviter un calcul cryptographique coûteux pour un numéro manifestement ancien, mais l’état durable ne doit avancer qu’après vérification d’intégrité. Sinon, une valeur élevée falsifiée pourrait évincer les paquets valides. Avec ESN, l’historique authentifié sert aussi à reconstruire les bits forts absents. Même sans filtrage anti-rejeu, cette reconstruction exige l’authentification ; elle ne prouve toujours pas que le paquet est nouveau.

La négociation ne possède pas le compteur

Dans IKEv2, les propositions SA contiennent des transforms ordonnés. Avant la nouvelle terminologie, un initiateur acceptant les deux formats proposait généralement les valeurs 0 et 1 ; ne proposer que 1 refusait le compteur ordinaire. La sélection du répondeur fixe le contrat de la Child SA.

Il faut conserver ce reçu : propositions des deux côtés, valeur retenue, identité de la Child SA, direction, SPI, pair, version logicielle et règle de politique. Une configuration souhaitée n’est pas le résultat négocié.

Mais ce résultat ne crée pas le compteur. Sur une passerelle rapide, plusieurs cœurs, files d’accélérateur ou cartes peuvent produire les paquets d’une même SA. Un basculement actif-secours peut transférer la clé sans le dernier seuil attribué. Un redémarrage peut restaurer un état plus ancien. La conformité de chaque moteur local ne prouve pas l’unicité du flux agrégé à l’entrée.

L’évidence utile relie donc la négociation à un propriétaire concret de l’allocation : algorithme de réservation, lots par file, persistance, epoch de démarrage, transfert lors du failover et seuil de rekey. La RFC 4303 dit déjà qu’ESP ne fournit pas de synchronisation pour plusieurs émetteurs sous une SA. La RFC 9827 empêche de masquer cette absence derrière une simple intention d’incrémenter.

Deux paquets identiques, quatre histoires possibles

Deux captures montrent le même SPI et le même numéro. Cela peut être une réutilisation par l’émetteur, une duplication par le réseau, la même trame enregistrée à deux endroits, ou un rejeu hostile. Les octets ne choisissent pas l’explication.

Il faut joindre l’empreinte du paquet à une capture au point d’entrée, au lieu de réception, au résultat d’authentification et à la décision de fenêtre. Pour la valeur 1, les bits forts reconstruits et l’état qui justifie cette reconstruction doivent également être conservés. Un véritable reçu de rejet comprend les bornes de fenêtre avant et après, la décision old/duplicate/new, et le sort du paquet.

L’absence de doublon applicatif ne prouve pas davantage l’anti-rejeu. Il peut ne jamais y avoir eu de copie ; un équipement intermédiaire a pu la supprimer ; la capture peut être incomplète ; le récepteur a pu désactiver le service. Le résultat visible ne remplace pas la décision enregistrée.

L’IV implicite exige l’unicité cryptographique

La RFC 8750 retire huit octets d’IV explicite pour certains modes AEAD en dérivant l’IV du numéro de séquence ESP. Cet IV ne doit jamais se répéter sous une même clé. Si deux émetteurs se chevauchent, désactiver l’anti-rejeu ne supprime pas le danger : le nonce cryptographique a déjà été réutilisé.

La RFC interdit donc l’IV implicite dès qu’un chevauchement est possible et exige un mécanisme d’allocation commun en multicast. Le Transform ID, l’architecture réelle de génération et la limite de rekey forment ensemble la preuve. Une case « chiffrement IIV disponible » n’en remplace aucune.

La RFC 9347 consomme une autre propriété. AGGFRAG/IP-TFS réassemble un paquet intérieur dans l’ordre logique des paquets ESP extérieurs. ESP exige des nombres croissants, mais pourrait légalement n’utiliser que les pairs. AGGFRAG exige une progression exacte de un, tout en définissant le rôle des paquets all-pad. Sa fenêtre de réordonnancement peut être différente de la fenêtre anti-rejeu.

Les valeurs 0 ou 1 sont nécessaires, mais il faut en plus prouver l’absence de trous de génération, la continuité des fragments et la transition entre SA. Les premiers fragments d’un paquet intérieur ne peuvent appartenir à une SA et les suivants à celle issue du rekey.

La valeur 2 donne une conséquence concrète

Avec la RFC 9838, « 32-bit Unspecified Numbers » informe les membres d’un groupe que l’unicité n’est pas garantie. Elle convient aux SA multicast multi-émetteurs pour lesquelles l’anti-rejeu classique n’est pas attendu. Le récepteur conserve son choix local, mais son entrée ne permet plus de promettre une détection fiable des copies.

Les dépendances suivent : pas d’IV implicite si l’unicité manque, pas d’AGGFRAG multi-émetteurs si aucun flux croissant unique n’existe. La présence du champ, la sélection d’un transform et l’activation d’une option de réception deviennent trois faits indépendants.

Huit reçus au lieu d’un voyant

Une affirmation exploitable s’appuie sur huit enregistrements : sémantique IANA ; transform offert et retenu ; propriétaire de génération ; propriété du flux agrégé à l’entrée ; politique du récepteur ; paquets authentifiés observés ; verdict de rejeu ; compatibilité des consommateurs de séquence.

Cette séparation ne rend pas le système plus bureaucratique. Elle évite de demander à une preuve de répondre à une question qu’elle ne mesure pas. La publication de la RFC prouve un langage commun. La négociation prouve un contrat de SA. Le trafic, l’authentification et la fenêtre prouvent l’exécution. Le chiffrement et AGGFRAG ferment leurs propres invariants.

Sources