TCP-AO RFC 5925 : sécurité des sessions BGP, rotation MKT et authentification

Le protocole de passerelle frontière (BGP-4, RFC 4271) coordonne l'acheminement global sur Internet, maintenant des sessions d'interconnexion TCP persistantes sur le port 179 entre systèmes autonomes (AS). Les routeurs situés sur les points d'échange Internet (IXP), les passerelles multi-cloud et les réseaux dorsaux s'appuient sur ces liaisons pour échanger les tables de routage (NLRI). En l'absence de vérification cryptographique, le trafic du plan de contrôle demeure vulnérable aux paquets falsifiés, aux réinitialisations imprévues et au détournement de session.

Pendant plusieurs décennies, les ingénieurs réseau ont employé la RFC 2385 (option de signature TCP MD5). Néanmoins, les faiblesses architecturales de la RFC 2385 empêchaient le renouvellement des clés sans interruption de service, provoquant des ruptures de sessions BGP et des instabilités de routage à grande échelle. L'IETF a normalisé la RFC 5925 définissant l'Option d'Authentification TCP (TCP-AO), accompagnée de la RFC 5926 pour les suites cryptographiques. TCP-AO résout ces limites historiques grâce aux tuples de clés maîtresses (MKT), aux numéros de séquence étendus, à l'agilité algorithmique et à la rotation des clés sans aucune perte de paquets.

La fragilité du routage de cœur : détournement TCP RST et obsolescence du MD5 RFC 2385

Les piles TCP classiques vérifient la validité des segments via le quadruplet IP et la fenêtre glissante des numéros de séquence. Sur les liaisons à très haut débit, un attaquant hors-chemin capable d'estimer un numéro de séquence dans la fenêtre de réception peut injecter des paquets TCP RST ou SYN falsifiés (RFC 4953, RFC 5961). À la réception d'un segment RST valide dans la fenêtre, la pile ferme immédiatement le socket. Pour une session BGP, cette fermeture déclenche un retrait immédiat des routes et propage une instabilité critique à travers les réseaux de transit.

La RFC 2385 (Option Kind 19) a introduit la signature des segments par hachage MD5 avec un secret partagé. Malgré son adoption massive, la RFC 2385 présente des limites majeures :

1. Obsolescence cryptographique : L'algorithme MD5 est vulnérable aux collisions. La RFC 2385 applique un hachage direct sans structure HMAC standard, ce qui ne répond plus aux critères modernes de sécurité.
2. Absence d'agilité algorithmique : L'algorithme MD5 est figé dans la spécification. Toute migration vers un chiffrement plus robuste exige une option TCP distincte.
3. Le dilemme de rotation des clés : L'en-tête de la RFC 2385 ne comporte aucun champ d'identification de clé. Le remplacement d'un secret partagé exige une mise à jour parfaitement simultanée sur les deux routeurs. Si un équipement bascule tandis que des paquets portant l'ancienne signature sont encore en transit, la vérification échoue et la session BGP s'interrompt.
4. Vulnérabilité au rejeu intra-session : La RFC 2385 ne protège pas contre le rejeu de segments lorsque l'espace de numérotation boucle ou lors de reconnexions successives.

Architecture de la RFC 5925 : structure de l'en-tête de l'option d'authentification TCP

La RFC 5925 instaure l'option TCP Kind 29 pour remplacer le Kind 19. Conçu avec des champs explicites pour la gestion des clés et la protection anti-rejeu, l'en-tête TCP-AO propose une structure optimisée :

+---------------+---------------+---------------+---------------+
|  Kind = 29    |  Length = 16  |   KeyID       |  NextKeyID    |
+---------------+---------------+---------------+---------------+
|                Code d'authentification de message (MAC)       |
|                         (96 bits / 12 octets)                 |
+---------------+---------------+---------------+---------------+

Rôles précis des champs :

• Kind (1 octet) : Fixé à 29, identifiant la protection selon la RFC 5925.
• Length (1 octet) : Longueur totale de l'option (4 octets d'en-tête plus la longueur du MAC ; 16 octets pour un MAC de 96 bits).
• KeyID (1 octet) : Identifie le tuple de clé maîtresse (MKT) utilisé par l'émetteur pour générer le MAC du segment présent.
• NextKeyID (1 octet) : Indique au routeur distant le MKT souhaité pour signer les prochains segments de réponse, servant de canal de coordination en bande.
• MAC (12 octets) : Empreinte cryptographique calculée sur le pseudo-en-tête TCP, l'en-tête TCP (avec options neutralisées) et la charge utile.

Ce découplage entre l'identifiant de clé et l'état interne de la liaison autorise la gestion conjointe de plusieurs clés actives par socket.

Tuples de clés maîtresses (MKT) et algorithmes cryptographiques : spécifications RFC 5926

La configuration de la RFC 5925 repose sur le concept de Tuple de Clé Maîtresse (Master Key Tuple, MKT). Chaque MKT formalise une association de sécurité complète entre pairs BGP :

• Périmètre de liaison : Adresses IP source et destination, préfixes réseau et ports TCP optionnels.
• Identifiants de clé : SendID (KeyID émis vers l'extérieur) et RecvID (KeyID attendu en réception).
• Clé maîtresse : Chaîne secrète pré-partagée à haute entropie.
• Suite cryptographique : Algorithme d'authentification et fonction de dérivation définis dans la RFC 5926.

Fonctions de dérivation de clés de trafic (KDF) via primitives pseudo-aléatoires

Afin de préserver le secret maître, TCP-AO ne signe jamais directement les paquets sur le câble avec la clé maîtresse. La RFC 5926 prescrit l'usage de fonctions de dérivation de clés (KDF) basées sur des fonctions pseudo-aléatoires (PRF) :

Traffic_Key = PRF(Master_Key, Context_String)

La chaîne de contexte agrège les variables dynamiques de connexion :

Context = Direction || Send_ISN || Recv_ISN || Algorithm_ID

Grâce à la prise en compte des numéros de séquence initiaux (ISN) et du sens de transmission, chaque session dispose de clés de trafic unidirectionnelles distinctes. La compromission d'une clé de session n'expose pas la clé maîtresse et interdit toute falsification du flux inverse.

Analyse comparative : AES-128-CMAC face à HMAC-SHA-1-96 dans le silicium ASIC

La RFC 5926 impose la prise en charge de deux suites cryptographiques : AES-128-CMAC-96 et HMAC-SHA-1-96 :

Sur les routeurs de cœur de réseau, AES-128-CMAC procure un débit optimal sans gigue de traitement.

Résolution du dilemme de rotation des clés : migration sans coupure ni battement BGP

L'avantage opérationnel déterminant de la RFC 5925 réside dans la rotation transparente des clés. Les normes de sécurité exigent un renouvellement régulier des identifiants, mais l'ancienne RFC 2385 imposait des coupures réseau. TCP-AO élimine ce problème via une séquence coordonnée :

1. Pré-déploiement : Les équipes provisionnent un nouveau MKT (KeyID = 2) sur les deux routeurs tandis que la production transite sur le MKT (KeyID = 1).
2. Notification d'intention : Le routeur A configure son socket pour émettre NextKeyID = 2, tout en conservant KeyID = 1 pour ses signatures sortantes.
3. Alignement du pair : Le routeur B lit NextKeyID = 2, active son MKT-2 local, signe désormais ses segments avec KeyID = 2 et confirme NextKeyID = 2.
4. Convergence finale : Le routeur A constate que les paquets reçus utilisent KeyID = 2 et bascule l'ensemble de ses émissions sur KeyID = 2.

Le MKT-1 historique peut alors être désactivé en toute sécurité sans interruption de session ni perte de paquets BGP.

Mécanisme anti-rejeu : numéros de séquence étendus et résistance aux chemins furtifs

Sur les liaisons 100 Gb/s et 400 Gb/s, l'espace 32 bits des numéros de séquence TCP boucle en quelques secondes. Ce bouclage rapide expose les échanges à des réinjections de paquets capturés antérieurement.

La RFC 5925 neutralise ce risque grâce aux extensions de numéros de séquence (Sequence Number Extensions, SNE) :

• L'en-tête TCP transmis conserve le numéro standard sur 32 bits (SEQ).
• La pile du noyau incrémente en interne un compteur d'extension de 32 bits (SNE).
• Dès que SEQ bascule de 0xFFFFFFFF à 0x00000000, le noyau incrémente automatiquement SNE.
• Le calcul du MAC englobe la valeur concaténée sur 64 bits (SNE || SEQ), interdisant tout rejeu à travers les cycles.

Par ailleurs, TCP-AO protège contre les chemins furtifs. Les segments SYN désynchronisés visant à provoquer un RST sont validés par rapport au MKT initial et rejetés avant d'altérer l'état du socket.

Implémentation dans le noyau Linux : CONFIG_TCP_AO et architecture de l'API Socket

Les déploiements open source utilisaient historiquement MD5 par manque de prise en charge dans Linux. Depuis le noyau Linux 6.7, l'option CONFIG_TCP_AO est intégrée à la branche principale, offrant les mêmes capacités que les systèmes d'exploitation propriétaires.

Options de sockets du noyau et enregistrement des tuples MKT via Setsockopt

Les applications gèrent les MKT via des appels setsockopt définis dans <linux/tcp.h> :

struct tcp_ao_add cmd;
memset(&cmd, 0, sizeof(cmd));

cmd.tcpa_addr.ss_family = AF_INET;
((struct sockaddr_in *)&cmd.tcpa_addr)->sin_addr.s_addr = inet_addr("198.51.100.1");
cmd.set_current = 1;
cmd.keyid = 1;
cmd.next_keyid = 1;
cmd.alg_name = "cmac(aes128)";
cmd.keylen = 16;
memcpy(cmd.key, "SharedMasterSecret", 16);

setsockopt(sockfd, IPPROTO_TCP, TCP_AO_ADD_KEY, &cmd, sizeof(cmd));

Le noyau contrôle les paramètres, associe l'enregistrement MKT au socket et génère les clés de trafic lors de la phase d'établissement.

Interopérabilité avec FRRouting, BIRD et les démons de routage d'entreprise

Les suites logicielles actuelles exploitent nativement ces commandes système :

• FRRouting (FRR) : Offre des directives sous router bgp pour lier identifiant de clé, algorithme et secret partagé à un voisin spécifique.
• BIRD Internet Routing Daemon : Permet la configuration déclarative des liaisons TCP-AO au sein des instances BGP.
• Compatibilité multi-constructeurs : Les routeurs Linux récents établissent des interconnexions conformes à la RFC 5925 avec les systèmes Cisco IOS-XR et Juniper Junos.

Comparaison de défense en profondeur : TCP-AO, GTSM (RFC 5082) et tunnels IPsec

La protection du plan de contrôle réclame une sélection adaptée selon l'architecture :

Le mécanisme GTSM (RFC 5082) est très efficace en liaison directe (TTL = 255) mais inopérant sur les sessions eBGP multi-sauts. IPsec assure la confidentialité mais pénalise le MTU. TCP-AO apporte un compromis rigoureux pour l'intégrité de transport à vitesse nominale.

Infrastructure RiceGuard : renforcement du plan de contrôle BGP sur les bordures multi-cloud

VPNRice sécurise les flux de ses utilisateurs grâce à l'architecture RiceGuard. Sous les tunnels chiffrés des clients opère un réseau Anycast mondial interconnecté aux opérateurs de premier niveau (Tier 1) et aux points d'échange IXP.

Préserver la haute disponibilité d'Anycast exige un plan de contrôle BGP inaltérable :

1. Suppression des battements de session : En appliquant TCP-AO sur ses liaisons de transit, les nœuds RiceGuard rejettent les paquets RST falsifiés émis depuis l'extérieur.
2. Renouvellement automatisé des MKT : Les contrôleurs d'orchestration planifient le renouvellement des clés via le signalement NextKeyID de la RFC 5925, écartant toute interruption de service.
3. Architecture de défense graduée : Les annonces BGP sont protégées par TCP-AO, tandis que les données utilisateurs transitent au sein de tunnels WireGuard optimisés pour une faible latence.

Ce schéma garantit la stabilité du routage face aux perturbations survenant sur les réseaux de transit tiers.

Checklist de migration en production : transition du TCP MD5 vers la RFC 5925

Pour réussir la modernisation de leurs infrastructures dorsales, les équipes d'ingénierie peuvent suivre ces étapes :

• Validation du système : S'assurer que les serveurs Linux exécutent le noyau 6.7 ou supérieur avec CONFIG_TCP_AO = y. Vérifier la conformité des routeurs physiques.
• Définition de la matrice MKT : Construire un tableau d'attribution associant KeyID, adresses IP des pairs et clés partagées d'au moins 128 bits.
• Standardisation du chiffrement : Adopter AES-128-CMAC-96 en priorité pour l'accélération matérielle ASIC ; réserver HMAC-SHA-1-96 aux seuls équipements historiques.
• Migration initiale planifiée : Fixer une fenêtre pour convertir les sessions RFC 2385 existantes vers TCP-AO ; les rotations ultérieures seront réalisées à chaud.
• Automatisation du cycle de vie : Déployer des scripts déclenchant la transition vers NextKeyID en amont des dates d'expiration des clés.
• Surveillance télémétrique : Collecter les compteurs de rejets dans /proc/net/netstat (TCPAOBadKey, TCPAOGood et TCPAORequired) pour identifier immédiatement toute injection malveillante.