Résumé

  • Le RFC 2385 faisait valider chaque segment TCP par les deux extrémités au moyen d’un secret partagé et imposait le rejet silencieux d’un échec.
  • Pour tenir dans l’espace d’options TCP, il ne transportait aucun identifiant d’algorithme ou de clé : une empreinte correcte attestait un segment, pas l’autorité d’une route ni la fraîcheur de l’état cryptographique.

Défendre la transition TCP

BGP bénéficiait de la livraison ordonnée de TCP, mais dépendait aussi de son état. Un RST forgé, avec des adresses et un numéro de séquence plausibles, pouvait fermer la connexion. La conséquence ne s’arrêtait pas au transport : le routeur pouvait réinitialiser sa session et retirer temporairement les routes apprises.

L’option Kind 19 associait à chaque segment un condensat MD5 de 16 octets. Le calcul couvrait le pseudo-en-tête IPv4, l’en-tête TCP sans ses options et avec une somme nulle, les données et un secret connu des deux extrémités. Si le calcul local ne correspondait pas, le récepteur devait jeter le segment sans répondre.

Cette discipline réduisait l’injection de RST. Elle ne certifiait pourtant ni l’opérateur, ni l’AS, ni l’origine d’un préfixe. Elle ne prouvait pas qu’une UPDATE avait franchi la politique d’importation, atteint la RIB, été programmée dans la FIB ou transporté un paquet. Le condensat fermait une porte du transport ; il ne devenait pas l’autorité du routage.

L’état que le paquet ne nommait pas

Le secret n’était pas défini sur le fil. La configuration choisissait ce que l’application pouvait fournir à TCP. L’option n’avait pas de numéro de clé. Deux opérateurs pouvaient donc être certains d’avoir « changé la clé » tout en vérifiant des états différents.

Le RFC permettait un changement pendant la connexion si les deux côtés le synchronisaient. Il signalait aussitôt le problème des retransmissions : un segment calculé sous l’ancien secret pouvait arriver après le basculement du récepteur. Sans identifiant, le segment ne disait pas quelle époque devait le vérifier.

L’usage même de l’option n’était pas négocié. La politique locale décidait. Un SYN/ACK non signé ne provoquait pas de repli ; il était ignoré et la connexion échouait. Cette règle empêchait un pair non authentifié d’ordonner une dégradation. Elle déplaçait cependant le diagnostic vers les opérateurs : option absente, mauvais secret, activation désynchronisée et paquet forgé pouvaient tous finir en silence.

Le coût d’un octet absent

Un en-tête TCP complet ne peut dépasser 60 octets. Après les 20 octets fixes, MSS, échelle de fenêtre, horodatage et autres options se partagent 40 octets. L’option MD5 en prenait 18. Dans l’exemple le plus chargé du RFC, les options du SYN remplissaient exactement les 40 octets.

Les inquiétudes sur MD5 existaient déjà. Le format déployé n’avait pourtant aucun champ de type d’algorithme. Le document expliquait qu’un octet supplémentaire produirait une option de 19 octets, probablement alignée à 20. Dans ce budget minuscule, deux octets effectifs semblaient chers.

La décision facilita la pratique immédiate. Elle retira au format la capacité de désigner son successeur. Changer d’algorithme exigeait une nouvelle option et un nouvel accord d’interopérabilité. L’Errata 4432 corrigea plus tard « mots de 32 octets » en « mots de 32 bits ». Le RFC 6691 corrigea le calcul MSS : c’est l’émetteur qui retranche les options de sa charge utile. Aucune correction ne rendit l’algorithme visible.

La gestion de clé n’avait pas disparu

Le RFC 3562 recommanda des clés de 12 à 24 octets, peu partagées et changées au moins tous les 90 jours. Ces exigences révèlent le travail laissé hors du paquet. Une clé courte pouvait être devinée ; une clé commune à plusieurs peerings transformait une fuite en panne collective ; un changement mal coordonné interrompait la session.

Le RFC 5925 remplaça finalement TCP MD5 par TCP-AO. Il ajouta l’agilité d’algorithme, KeyID, l’indication de clé suivante, une dérivation liée à la connexion et une protection contre les rejeux. Il ne distribua pas pour autant les secrets et ne transforma pas l’authentification TCP en autorisation de route.

Une autre étude de la liste BTW traite déjà de l’époque de clé TCP-AO. Le sujet présent s’arrête avant elle : le RFC 2385 rendit une preuve exécutable, mais omit l’état commun nécessaire pour dire comment la remplacer.

Une preuve mince, pas une preuve totale

Le mécanisme était utile parce qu’il était étroit. Une empreinte valide disait que ce segment correspondait au secret choisi localement. Elle ne disait pas quel secret, depuis quand, pour combien de peerings, ni si la route portée par le flux devait être acceptée.

L’histoire ne condamne pas un choix ancien avec des ressources modernes. Elle montre une contrainte de conception. Une spécification minimale doit rester assez petite pour être déployée, mais assez explicite pour que des implémentations indépendantes puissent changer de compatibilité sans deviner un état caché. Le RFC 2385 protégea le segment ; l’octet absent enferma l’évolution dans un autre protocole.

Sources