Résumé

  • Une remise à clé de l’IKE SA crée de nouveaux SPI, de nouvelles clés et de nouveaux compteurs pour le canal de contrôle. L’IKE SA survivante hérite des Child SA en cours ; elle ne renouvelle pas automatiquement leurs clés de trafic.
  • La remise à clé d’une Child SA possède sa propre lignée et ses propres collisions. Si deux échanges concurrents créent deux candidates, l’association liée au nonce le plus faible est la redondante à fermer, et non la gagnante.
  • La preuve d’une maintenance sûre réunit trois histoires sans les confondre : succession du contrôle, garde de chaque Child SA, puis réception effective des messages protégés et des paquets utiles.

Le mot « rekey » semble décrire un geste unique : remplacer une clé avant son expiration. IKEv2 en fait un terme de famille. Le même échange CREATE_CHILD_SA sert à créer une Child SA, à renouveler une Child SA existante ou à remplacer l’IKE SA elle-même. Ces opérations ne touchent ni les mêmes identifiants, ni les mêmes clés, ni le même trafic.

Cette ambiguïté devient coûteuse au moment où tout paraît normal. Les paquets continuent d’arriver ; le pair reste authentifié ; l’ancien canal de contrôle va disparaître. Si la télémétrie n’a conservé qu’un compteur « rekey », personne ne sait si les Child SA ont été transférées, si leurs clés ont changé, ni si le prochain message de maintenance empruntera le bon successeur.

Tero Kivinen est l’un des cinq auteurs nommés de RFC 7296, avec Charlie Kaufman, Paul Hoffman, Yoav Nir et Pasi Eronen. Cette signature permet d’ancrer l’analyse dans une contribution vérifiable. Elle ne transforme pas une œuvre collective de l’IETF en propriété individuelle, et ne donne aucune autorité sur les choix locaux d’un opérateur.

Le parent de contrôle et les associations de trafic

L’IKE SA protège le dialogue de contrôle. Elle porte les demandes qui créent, renouvellent ou suppriment les Child SA. Ces dernières protègent les paquets AH ou ESP ; une paire couvre généralement les deux sens. La parenté est opérationnelle : le canal IKE organise la vie des associations qui transportent les données.

L’échange initial IKE_AUTH établit habituellement l’IKE SA et une première Child SA. Leur naissance proche masque leur indépendance. RFC 7296 indique pourtant qu’un échec de création de Child ne détruit pas nécessairement l’IKE SA achevée, et qu’un échec ultérieur ne doit pas faire tomber le canal de contrôle.

RFC 6023 va plus loin en permettant une IKE SA authentifiée sans aucune Child SA. Elle peut maintenir la présence du pair, détecter le NAT, transmettre des notifications protégées et créer une Child plus tard. Ce document expérimental est dû à Yoav Nir, Hannes Tschofenig, Hui Deng et Raj Singh, pas à Kivinen. Il sert ici de preuve contextuelle : être authentifié et disposer d’un canal de contrôle ne signifie pas encore transporter du trafic.

Un événement exploitable commence donc par type d’association. Sans cette colonne, « rekey réussi » ne dit même pas quelle couche a changé.

Une succession, pas une modification sur place

RFC 7296 définit la remise à clé comme la création d’une nouvelle SA suivie de la suppression de l’ancienne. C’est un passage de relais make-before-break, non la mise à jour d’une ligne existante. Les identités ancienne et nouvelle doivent rester observables pendant la transition.

Pour une IKE SA, le successeur reçoit de nouveaux SPI, de nouvelles clés et un nouvel espace de Message ID. L’ancienne association conserve ses propres compteurs pour finir ce qui lui reste. Lorsque la succession aboutit, la nouvelle IKE SA hérite de toutes les Child SA attachées à l’ancienne et protège désormais leurs futurs messages de gestion.

Le dernier acte de l’ancienne IKE SA est sa propre demande de suppression. Entre création et effacement, il faut dater au moins l’acceptation du successeur, le rattachement de l’inventaire des Child, le premier échange protégé par le successeur et la suppression du prédécesseur. Un seul horodatage ne révèle ni trou de garde ni destruction prématurée.

IKEv2 ne négocie pas une durée de vie commune. Chaque extrémité applique ses règles locales ; la politique la plus courte déclenche souvent la remise à clé. Les seuils de temps, de volume ou d’activité appartiennent donc au reçu local. Le standard coordonne la transition, il ne centralise pas le calendrier.

Hériter ne veut pas dire renouveler les clés de trafic

Une Child SA héritée conserve ses SPI entrants et sortants, ses sélecteurs, ses algorithmes, son époque de clé, ses séquences, son état anti-rejeu, ses compteurs et sa durée de vie. Seule une opération propre à la Child peut remplacer ces éléments.

Ainsi, de nouveaux SPI IKE prouvent le renouvellement du contrôle. Ils ne prouvent pas que les paquets ESP ou AH utilisent de nouvelles clés. Pour soutenir cette seconde affirmation, il faut montrer l’ancien et le nouveau couple de SPI Child, la proposition et les transformations retenues, la nouvelle époque de clé, l’activation puis la suppression du couple remplacé.

La répartition des textes confirme ce découpage. RFC 8247 traite les exigences algorithmiques d’IKEv2 et précise qu’elle ne met pas à jour le chiffrement ESP. RFC 8221 traite séparément ESP et AH. Kivinen figure parmi les auteurs de ces deux RFC, avec des groupes différents ; leur portée est plus importante ici que la biographie : la posture cryptographique du contrôle et celle du plan de données ne tiennent pas dans une case unique.

Une migration peut donc améliorer les algorithmes IKE tout en laissant vivre des Child SA conformes à une époque antérieure. L’inverse est également possible. Un audit de cycle de vie doit conserver deux horloges.

Le pair authentifié n’obtient pas tous les préfixes

L’authentification mutuelle établit l’identité du pair et sécurise la négociation. Elle ne lui donne pas le droit de revendiquer n’importe quel trafic. RFC 4301 place la Peer Authorization Database dans la décision qui borne les sélecteurs proposés pour une Child SA.

Le répondant peut réduire TSi et TSr à ce que sa politique autorise. Lorsqu’une nouvelle IKE SA hérite de la Child, le reçu doit conserver le pair authentifié, le jeu de sélecteurs accepté et la version de politique. La succession du parent ne doit jamais élargir silencieusement la portée de l’enfant.

Trois faits restent distincts : un pair a réussi l’authentification ; une Child SA a été installée ; des sélecteurs précis ont reçu une autorisation locale. Les fusionner transforme une preuve d’identité en licence de routage.

Le principe de spécification initiale minimale de Heng Lu aide à situer la frontière. Les messages et identifiants communs suffisent à coordonner des participants indépendants. Le choix de capacité, de durée et d’autorisation reste chez celui qui supporte la conséquence locale.

Le répondant ne sait pas encore si la réponse est arrivée

Avant d’envoyer une réponse positive, le répondant doit pouvoir accepter les paquets sur la nouvelle SA. L’initiateur peut émettre après avoir traité cette réponse. Le répondant ignore alors si elle a franchi le réseau et si l’autre moitié a bien été installée.

Lors d’une remise à clé Child, il continue donc à émettre sur l’ancienne SA jusqu’à la réception d’un paquet valide sur la nouvelle moitié ou d’une demande IKE fermant l’ancienne. En l’absence de données applicatives, l’initiateur peut envoyer un paquet ESP factice pour signaler sa disponibilité.

Ce paquet prouve un pas de transition, pas une livraison utile. La réponse de création prouve une négociation, pas le chemin retour, le routage, l’état anti-rejeu ou la réussite d’une transaction. La continuité demande des observations séparées.

Le pair et les sous-réseaux ne suffisent pas non plus à identifier une Child. IKEv2 autorise des associations parallèles avec les mêmes extrémités et sélecteurs, notamment pour des services différenciés. Les SPI et la lignée sont la clé d’audit ; agréger par tunnel efface précisément la concurrence qu’il faut expliquer.

Deux remises à clé peuvent courir en même temps

Des politiques de durée proches peuvent amener les deux extrémités à initier simultanément une remise à clé Child. La gigue recommandée réduit la probabilité sans la supprimer. L’état provisoire contient alors l’ancien couple et deux nouveaux couples.

Les paquets entrants doivent être acceptés par toute SA encore valable. Pour choisir la candidate redondante, RFC 7296 compare les quatre nonces des deux échanges, octet par octet. La règle mérite d’être écrite sans raccourci : la SA issue de l’échange qui contient le nonce le plus faible est fermée. Le nonce minimal perd.

Le créateur du couple survivant supprime l’ancien couple remplacé. Le créateur du couple redondant supprime sa propre candidate. Les candidats et leurs propriétaires doivent rester dans l’historique, même si l’interface finale n’en montre qu’un.

Une demande tardive peut viser une SA déjà remplacée et recevoir CHILD_SA_NOT_FOUND. Dans cette course, la notification peut être bénigne. Sans SPI cible, ordre d’arrivée et lignée, une alerte la prendrait à tort pour la preuve qu’aucun renouvellement n’a eu lieu.

La collision IKE décide aussi de la garde

Une remise à clé simultanée de l’IKE SA produit l’ancienne association et deux successeurs possibles. La candidate liée au nonce le plus faible est également celle qu’il faut fermer. La survivante doit reprendre toutes les Child SA.

La comparaison des nonces ne suffit donc pas. Avant de supprimer l’ancien contrôle, les deux pairs doivent observer le même successeur et le même inventaire de Child rattachées. Une Child absente ou supplémentaire est un échec de garde même si l’échange cryptographique a répondu avec succès.

Dans une course asymétrique, une demande de rekey peut arriver pendant la fermeture de l’ancienne IKE SA. RFC 7296 prévoit TEMPORARY_FAILURE, puis permet au pair d’abandonner sa tentative lorsque la suppression ancienne arrive. Ce résultat temporaire décrit une résolution ordonnée ; il ne signifie pas nécessairement une panne.

RFC 9370 ajoute les échanges de clés multiples et IKE_FOLLOWUP_KE, tout en exigeant que les collisions soient résolues avant la poursuite des échanges complémentaires. Ce texte appartient à un autre groupe de sept auteurs. Il montre surtout qu’un voyant « succès » perd encore de l’information lorsque la chaîne négociée s’allonge.

Trois journaux pour une conclusion vérifiable

Le journal de lignée du contrôle conserve identité du pair, SPI IKE anciens et nouveaux, propositions, algorithmes, nonces, Message ID, déclencheur local, collision, choix du successeur, première utilisation et suppression ancienne. Il répond à la question : qui est devenu le parent de contrôle ?

Le journal de garde énumère chaque Child, ses deux SPI, ses sélecteurs, la décision PAD/SPD, le mode, les algorithmes, l’époque de clé, la durée locale, l’ancien parent, le nouveau parent, l’héritage ou le remplacement et la suppression. Il dit ce qui a déménagé et ce qui a réellement reçu de nouvelles clés.

Le journal d’exécution observe les paquets acceptés sur les anciens et nouveaux couples, les séquences, le rejeu, les causes de perte, le paquet factice éventuel, le premier trafic utile bidirectionnel et la continuité vue par l’application. Il distingue disponibilité cryptographique et service rendu.

La primauté du code en fonctionnement de Heng Lu prend ici une forme concrète : le texte normalise le passage de relais, mais seuls des états et paquets observables montrent ce qui fonctionne. Une IKE SA nouvelle n’est pas un reçu de renouvellement de toutes les Child ; un flux vivant n’est pas la preuve que son futur contrôle possède le bon parent.

Attribution sans souveraineté

Au 31 août 2026, la fiche IETF de Tero Kivinen le présente comme coprésident d’IPsecme, membre de la Tools Team, relecteur et secrétaire de la Security Area Directorate. Elle recense 16 RFC et aucun Internet-Draft actif. Ce sont des faits datés, non une certification universelle.

RFC 7296 compte cinq auteurs. RFC 8247 et RFC 8221 ont chacune leur groupe. RFC 6023 et RFC 9370 ne sont pas de Kivinen. Conserver ces signatures évite qu’une contribution technique traçable devienne une prétention à posséder le protocole.

Le registre IANA joue le même rôle limité : il garantit un vocabulaire sans collision pour échanges, charges utiles, transformations et notifications. Il ne prouve ni adoption, ni conformité d’un produit, ni réussite d’un trafic.

L’auteur rend une règle inspectable ; l’opérateur reste responsable de ses temporisations, de sa politique, de son déploiement et de ses preuves. C’est précisément parce que l’autorité est limitée que la coordination peut rester commune.

Sources