Résumé

  • KeyID désigne le Master Key Tuple qui protège le segment émis ; RNextKeyID indique le MKT que l’émetteur préfère pour les futurs segments reçus. Aucun des deux champs ne transporte un secret ni ne certifie un basculement distant.
  • Une session possède quatre états utiles : la clé sortante courante et la clé entrante préférée à chaque extrémité. Les réduire à une unique « clé active » efface précisément l’asymétrie dont dépend la continuité.
  • La clé ancienne ne peut être retirée qu’après avoir observé le nouvel identifiant, une vérification MAC réussie dans chaque sens, un BGP stable, un test de reconnexion et un état de retour complet.

L’incident ne vient pas d’un secret envoyé en clair ni d’un algorithme faible. Les deux équipes ont reçu les mêmes octets par le canal prévu. Le décalage se trouve dans les noms locaux. Le routeur A attribue au nouveau MKT les SendID et RecvID 42. Le routeur B attribue, selon sa convention, SendID 43 et RecvID 43. Dans les tickets, tout le monde parle de « clé 42 ». Sur le fil, les directions ne racontent plus la même chose.

A choisit ce MKT comme prochaine clé de réception. Il continue d’émettre sous l’ancien KeyID=17, tout en plaçant RNextKeyID=42 dans ses segments. B valide parfaitement leur MAC avec l’ancien MKT. Il cherche ensuite, pour cette paire de sockets, un MKT sortant dont le SendID vaut 42. S’il ne le trouve pas dans l’état effectif attendu, RFC 5925 lui demande simplement de ne rien changer. Cet échec concerne le sens B vers A : B continue d’émettre avec 17. Si B annonce ensuite RNextKeyID=43, A ne peut pas non plus basculer le sens A vers B sans MKT sortant prêt portant SendID 43.

Le tableau de bord a confondu une préférence annoncée avec une livraison. C’est cette confusion, et non la cryptographie, qui rend la suppression dangereuse.

Deux octets, deux sens d’autorité

L’option TCP-AO porte le numéro Kind 29. Elle contient une longueur, KeyID, RNextKeyID et un code d’authentification de message. Sa petite taille dit quelque chose de son mandat : coordonner l’usage de clés déjà présentes, pas créer un protocole de distribution des secrets.

KeyID décrit le segment actuel. À l’émission, il reçoit le SendID du MKT courant. À la réception, l’autre extrémité le rapproche du RecvID d’un MKT et de la paire d’adresses et de ports. Le sens est essentiel : le SendID local doit rencontrer le RecvID distant approprié.

RNextKeyID regarde vers le trafic futur dans l’autre direction. L’émetteur y place le RecvID du MKT qu’il est prêt à utiliser pour valider de futurs segments entrants. Le destinataire de cette annonce vérifie alors s’il possède, localement, un MKT sortant compatible. Ce n’est qu’en cas de correspondance qu’il peut changer sa clé courante.

Ces identifiants ne sont pas des empreintes. Ils n’ont aucune propriété cryptographique, aucune valeur réservée et aucun ordre temporel. Les nombres peuvent différer entre les deux sens. Deux valeurs égales ne prouvent pas que les secrets, les algorithmes, les durées ou la portée sont identiques. Une étiquette commune ne garantit pas un contenu commun.

Il faut donc lire RNextKeyID avec précision : « voici le RecvID que je préfère si tu disposes déjà du MKT sortant correspondant ». Rien dans cet octet ne livre la clé, ne confirme sa garde ni n’ordonne au pair de l’adopter.

Le MKT donne son sens à l’identifiant

Un Master Key Tuple n’est pas une simple ligne « numéro + mot de passe ». Il associe le matériel secret à un identifiant de connexion TCP : adresses locales et distantes, ports, éventuellement plages ou masques propres à l’implémentation. Il contient aussi SendID, RecvID, fonction de dérivation, algorithme MAC et règle d’inclusion des autres options TCP. Le système de gestion peut y ajouter des périodes de validité.

Pour un segment entrant, RFC 5925 exige une correspondance avec exactement un MKT au moyen de la paire de sockets et du KeyID. Le même secret placé dans un autre VRF, une autre famille d’adresses, une autre direction ou sous un autre RecvID ne constitue pas la même capacité opérationnelle.

La politique d’inclusion des options est elle aussi bilatérale. TCP-AO protège toujours ses propres champs, en mettant provisoirement le champ MAC à zéro pendant le calcul. Selon le MKT, les autres options TCP sont incluses ou exclues. Un désaccord sur ce choix, sur la longueur du MAC ou sur l’algorithme suffit à faire échouer la vérification malgré des octets maîtres identiques.

Un inventaire exploitable doit donc conserver la paire d’adresses et de ports, l’instance de routage, SendID, RecvID, l’algorithme, la longueur du MAC, la politique d’options, la durée, le rôle courant ou prochain, et l’époque de connexion. « Clé 42 installée » n’est qu’un résumé ; il ne permet pas de reconstruire la décision.

Le secret maître n’est pas la clé de trafic

TCP-AO dérive des clés de trafic à partir du MKT et du contexte de connexion. Les adresses, les ports et, une fois la connexion établie, les numéros de séquence initiaux des deux sens participent au calcul. Les clés sont directionnelles et distinguent les SYN des segments ultérieurs.

La même clé maîtresse produit donc des clés de trafic différentes selon le pair, la direction et l’époque TCP. Une reconnexion n’est pas une reprise cryptographique transparente, même si la paire d’adresses et de ports semble identique. Les nouveaux numéros initiaux modifient le contexte.

Les Sequence Number Extensions prolongent l’espace des séquences pour protéger une connexion durable lorsque le compteur TCP sur 32 bits reboucle. Chaque sens maintient son propre état, initialisé à l’établissement. Une capture isolée, détachée de son époque de connexion, ne suffit pas à expliquer un échec de MAC.

Cette dérivation limite la réutilisation et améliore la résistance au rejeu. Elle oblige aussi l’enquête à aller au-delà de « l’empreinte du secret est identique ». La panne peut résider dans les identifiants, la portée de socket, l’algorithme, les options, la longueur du MAC ou l’état de connexion.

Une relève comporte quatre transitions, pas un bouton

Chaque extrémité maintient au plus un current_key, utilisé pour les segments sortants, et un rnext_key, préféré pour les segments entrants. Une seule session BGP porte donc quatre pointeurs matériels.

La relève sûre commence par la distribution. Le nouveau MKT devient réellement disponible pour la réception sur A et B, tandis que l’ancien reste valide. Une configuration sauvegardée ne prouve pas que le processus TCP l’a liée à la connexion active.

Vient ensuite la première direction. A annonce son nouveau RecvID. B résout cette demande dans sa base locale puis, s’il trouve le MKT, change sa clé sortante. Le premier segment de B portant le nouveau KeyID, validé par A, prouve cette moitié du passage.

La direction inverse suit son propre calendrier. B annonce sa préférence de réception ; A change sa sortie après résolution locale. Pendant un intervalle parfaitement légitime, B peut donc émettre sous la nouvelle époque tandis qu’A utilise encore l’ancienne.

Enfin vient le retrait. Une période de recouvrement couvre retransmissions, délai de télémétrie, reconnexion et retour. L’ancien MKT n’est supprimé qu’après preuve que plus aucun chemin utile ne l’emploie.

Un écran qui affiche une seule clé active transforme cette matrice en fiction. Il faut au minimum voir le KeyID A vers B, le RNextKeyID annoncé par A, le KeyID B vers A, le RNextKeyID annoncé par B et, à chaque extrémité, le MKT réellement résolu.

L’absence de basculement protège l’autonomie locale

Un segment peut être valablement authentifié avec l’ancienne clé tout en annonçant un RNextKeyID inconnu. Dans ce cas, le pair ne bascule pas. Ce comportement est important : une valeur distante ne peut pas contraindre un routeur à employer une clé absente ou non approuvée.

Le signal commun reste minimal. Chaque participant interprète la demande à partir de son propre état vérifiable. La compatibilité permet le changement ; l’annonce ne crée pas l’obligation.

Les opérations doivent donc observer la conséquence réelle. Après une annonce, le KeyID sortant du pair a-t-il changé ? Le bon compteur MAC progresse-t-il sous le nouveau MKT ? Les compteurs de clé inconnue ou de mauvais MAC restent-ils stables ? Sans réponse, la relève est incomplète même si BGP demeure Established.

La continuité est parfois trompeuse. Elle prouve que l’ancien contexte fonctionne encore. Elle ne dit rien de la capacité à survivre à sa suppression.

La distribution et le retrait vivent hors de TCP-AO

RFC 5925 suppose qu’un mécanisme manuel ou un protocole hors bande fournisse les MKT. L’option ne transporte pas le secret et ne définit pas le coffre, l’API, l’autorité d’approbation ou le canal chiffré. Elle ne coordonne pas non plus la suppression des MKT périmés.

RFC 6518 replace cette séparation dans le cycle de vie. Des clés limitées dans le temps réduisent l’exposition, mais des changements manuels trop fréquents peuvent accroître les erreurs et les fuites. Le transport doit savoir changer sans faire tomber l’adjacence ; le système de gestion doit rendre la fraîcheur praticable. RFC 7211 recommande notamment de rendre une nouvelle clé valide à la réception avant de l’activer à l’émission, de contrôler la cohérence de la table et d’avertir avant expiration.

Le dossier d’autorité doit relier ces mondes. Il indique qui a généré le secret, par quel canal il est arrivé, où son texte clair pouvait exister, quels identifiants locaux lui ont été attribués, quand commencent les validités réception et émission, quand se termine l’ancienne époque et qui peut revenir en arrière.

Le contrôle opérationnel consiste à pouvoir inspecter l’état effectif des sockets, conserver les preuves, protéger le matériel secret et restaurer la session sans dépendre d’un écran incapable de voir les deux extrémités.

Retirer l’ancienne clé est le bord irréversible

L’activation ajoute une possibilité ; la suppression retire une issue. Tant que l’ancien MKT subsiste, une direction retardataire ou un retour peut encore fonctionner. Une fois supprimé des deux côtés, le défaut de la nouvelle époque devient une panne de transport.

Conserver l’ancien secret indéfiniment serait également mauvais. Une clé compromise reste exploitable aussi longtemps qu’un récepteur l’accepte. Un chevauchement sans fin autorise aussi un retour silencieux vers l’ancien état. La bonne politique est un retrait borné par des preuves.

Définir d’abord la durée : propagation de configuration, retransmissions, retard d’observation, test de reconnexion et fenêtre de retour. Pendant cette durée, mesurer dans chaque sens le dernier segment sous l’ancien KeyID et le premier sous le nouveau. Vérifier la hausse des bons MAC, l’absence de mauvaises signatures et la stabilité BGP. Tester une reconnexion contrôlée, car la sélection des MKT au SYN peut différer de l’état hérité d’une connexion existante.

La suppression s’effectue ensuite sur un pair canari. Les compteurs TCP-AO, les retransmissions, l’état TCP, la machine BGP, les Adj-RIB et les routes sélectionnées doivent rester conformes. Le mécanisme Linux documente même une suppression forcée capable de désigner atomiquement une autre clé courante ; sa documentation avertit qu’elle peut casser la connexion si le pair demande encore l’ancienne clé. Cette possibilité de réparation n’est pas une preuve de sûreté.

Le retour doit décrire un état complet : portée du MKT, SendID, RecvID, algorithme, longueur du MAC, politique d’options, provenance du secret et durées. « Réinstaller 17 » ne suffit pas.

Authentifier le segment n’autorise pas la route

Un MAC valide signifie que le segment correspond au contexte de clé attendu. Il ne prouve ni la propriété du préfixe annoncé, ni la correction de l’AS_PATH, ni l’autorisation de l’opérateur distant. Un pair légitime et authentifié peut se tromper ou mentir.

RFC 4272 sépare clairement les attaques externes contre la session des mauvaises informations envoyées par un véritable pair. RFC 7454 maintient donc des contrôles distincts : protection TCP, GTSM, filtrage du plan de contrôle, filtres de préfixes, max-prefix et politique de chemin.

Cette séparation fournit un diagnostic propre. Un mauvais MAC disparaît avant l’analyse BGP. Une route interdite mais correctement authentifiée doit atteindre la politique d’importation puis y être rejetée. Un événement max-prefix peut fermer volontairement une session cryptographiquement saine. Une alarme unique « sécurité du pair » détruirait cette causalité.

Le canari doit prouver les deux sens et le retrait

Identifier d’abord la session sans ambiguïté : instance, adresses, ports, pair BGP, époque TCP et référence des routes. Lire tous les MKT correspondants sur A et B, avec leurs paramètres et rôles. Comparer le secret par une empreinte protégée ou une vérification contrôlée ; ne jamais le recopier dans le ticket.

Prouver la disponibilité en réception des deux côtés. Faire ensuite annoncer la préférence par A, puis capturer le premier nouveau KeyID réellement émis par B et validé par A. Recommencer dans l’autre sens. Envoyer des KEEPALIVE et une opération BGP bornée, telle qu’un route refresh contrôlé, puis comparer les préfixes reçus et sélectionnés.

Maintenir le chevauchement, tester une nouvelle connexion et démontrer l’absence d’usage de l’ancien KeyID. Supprimer l’ancien MKT dans le périmètre canari, puis répéter les contrôles de transport et de route. Conserver captures, lectures des clés, compteurs et états BGP sous un identifiant d’époque commun.

La vertu de TCP-AO est sa modestie. Deux systèmes gérés indépendamment peuvent coordonner des étiquettes locales sans confier au fil la distribution des secrets. L’erreur apparaît lorsqu’un outil transforme cette coordination étroite en vérité globale.

Une époque de clés devient réelle lorsque les deux extrémités résolvent les étiquettes, que chaque sens émet et vérifie le nouveau contexte, que BGP survit à la connexion, que la dépendance ancienne tombe à zéro et qu’un retour complet demeure possible. Avant cela, 42 est un numéro annoncé, pas une autorité acquise.