Résumé

  • Un pair protégé par GTSM émet ses paquets avec un TTL ou un Hop Limit de 255 ; le destinataire n’admet que les valeurs compatibles avec la distance réseau approuvée.
  • Cette vérification peut écarter tôt des paquets usurpés venus de loin. Elle n’authentifie ni l’émetteur ni le contenu TCP/BGP et ne remplace ni le filtrage d’entrée, ni TCP-AO, ni la politique de routage.
  • La preuve utile relie les deux sens : valeur de départ, valeur reçue, seuil réellement appliqué, premier compteur de rejet, état TCP, état BGP et résultat de routage.

La facilité serait de passer immédiatement de hops 2 à hops 3. La session remonterait et l’incident semblerait clos. Or ce chiffre n’est pas un simple paramètre de disponibilité. Il dessine le diamètre depuis lequel un paquet peut présenter une distance plausible. L’élargir d’un saut restaure un chemin légitime tout en élargissant la surface des sources capables de franchir le même test.

255 n’est pas une identité

Le TTL IPv4 et le Hop Limit IPv6 sont des champs sur huit bits. Chaque routeur qui transfère le paquet réduit normalement la valeur. GTSM choisit donc le maximum, 255, au départ. Sur un lien direct, le pair reçoit 255. Sur un trajet routé, la valeur restante traduit le nombre de sauts consommés.

Ce résidu permet une conclusion limitée : « le paquet n’a vraisemblablement pas parcouru plus de distance que le seuil autorisé ». Il ne permet pas de conclure : « ce paquet vient bien de l’organisation attendue ». Un attaquant éloigné ne peut pas compenser les décréments au-delà du plafond de 255. Un attaquant placé sur le même lien que le pair légitime peut, lui, présenter la même valeur.

Les interfaces d’exploitation matérialisent cette idée de différentes façons. La documentation Cisco citée exprime un minimum reçu égal à 255 moins le nombre de sauts configuré. FRRouting expose neighbor PEER ttl-security hops NUMBER et documente, dans la version citée, une incompatibilité avec ebgp-multihop. Ces détails doivent rester attribués aux implémentations. L’invariant opératoire consiste à calculer la plage attendue puis à l’observer réellement sur chaque plateforme.

Le lieu du rejet compte autant que le rejet

RFC 5082 vise aussi la protection des ressources rares du plan de contrôle. Avant même qu’un UPDATE soit analysé, le routeur peut avoir transféré le paquet vers son processeur, alimenté une file, cherché une socket et traité des drapeaux TCP. Rejeter un faux trafic seulement dans le démon BGP protège moins qu’un classement effectué au plus près du matériel de ligne.

Le standard distingue trois catégories. Un paquet associé à une session protégée et conforme au seuil est « Trusted ». Le même paquet hors plage est « Dangerous ». Un paquet que GTSM ne sait pas rattacher à une session est « Unknown ». Ces termes n’accordent aucune vérité au contenu : « Trusted » signifie uniquement que le test de distance a réussi.

L’exploitation doit donc conserver une chaîne de compteurs. Où le paquet apparaît-il pour la dernière fois : plan de transfert, filtre du plan de contrôle, noyau, socket TCP ou processus BGP ? Un compteur de rejet dans BGP prouve une décision tardive. Il ne prouve pas que la CPU a été préservée. La promesse de résistance au déni de service dépend du premier endroit où la concurrence pour les ressources est réellement évitée.

Un accord manuel produit quatre réalités

Pour BGP, GTSM n’est pas une capacité générique négociée automatiquement par RFC 5082. Les deux opérateurs configurent leurs extrémités. Il faut distinguer la topologie voulue, le nombre de sauts configuré, le trajet observé et le seuil effectivement appliqué.

Ces quatre éléments coïncident le jour de la recette. Ils divergent après une bascule, une migration vers des loopbacks, un changement de constructeur, une nouvelle chaîne de services ou une différence entre IPv4 et IPv6. Une ligne de configuration correcte ne démontre ni que les paquets partent à 255, ni que le pair les reçoit dans la plage, ni que le filtre est actif.

Même l’état Established est une preuve insuffisante. Il indique que des paquets ont traversé les couches nécessaires à un instant donné. Une protection désactivée des deux côtés peut aboutir au même résultat. Pour prouver GTSM, il faut aussi prouver le négatif : un paquet situé juste au-delà du diamètre doit disparaître exactement au point prévu.

Le multihop transforme la distance en budget de confiance

Le cas le plus net reste le voisin direct. Le pair légitime remet 255 ; tout routage ordinaire fait baisser ce chiffre. RFC 5082 limite son énoncé d’applicabilité le plus ferme aux topologies intrinsèquement bornées et souligne la clarté du cas à un saut.

En multihop, le mécanisme conserve une utilité, mais son autorité change. Un seuil admettant trois sauts écarte les sources plus éloignées ; il ne distingue pas les positions hostiles situées à l’intérieur de ce rayon. RFC 7454 avertit que toute personne dans ce diamètre peut potentiellement usurper la valeur.

Le nombre autorisé doit donc avoir une justification. Un trajet nominal de deux sauts avec une marge de cinq peut couvrir un secours documenté ; il peut aussi provenir d’un modèle copié. Le premier cas est une décision de continuité. Le second est une frontière élargie sans propriétaire.

Chaque sens mérite son propre calcul. L’aller peut compter deux routeurs, le retour trois. Un SYN atteint B, tandis que le SYN-ACK est rejeté par A. Un groupe ECMP peut alterner entre deux valeurs. Mesurer une seule direction ou une seule occurrence fabrique une certitude fictive.

Les tunnels changent la signification du saut

Un tunnel peut transporter un paquet interne sans toucher à son TTL, recopier des valeurs ou les propager selon son modèle. Un paquet ayant traversé une longue infrastructure peut ainsi ressortir près du pair avec un TTL interne élevé. La distance visible ne décrit alors plus la distance réelle de l’injecteur.

RFC 5082 traite la confiance dans les extrémités et l’intégrité du tunnel comme des hypothèses de sécurité. Il faut documenter le type d’encapsulation, le lieu de décapsulation, les personnes capables d’injecter au point d’entrée, les valeurs interne et externe, ainsi que la validation de source à la sortie. « Un tunnel vaut un saut » n’est pas une preuve.

Les fragments créent une autre zone aveugle. Un fragment non initial ne contient pas l’en-tête TCP permettant de l’associer à la session BGP. L’attente de réassemblage peut consommer les ressources que GTSM devait préserver. Le MTU, la politique de fragments et les messages ICMP associés font donc partie de la recette.

Quatre contrôles, quatre questions

GTSM demande si la distance du paquet est compatible avec la relation. Le filtrage d’entrée demande si l’adresse source est plausible sur cette interface. TCP-AO ou un mécanisme cryptographique adapté vérifie l’identité et l’intégrité du segment. La politique BGP décide si le message et la route sont acceptables.

Un attaquant sur le lien peut franchir GTSM mais échouer au filtrage de source. Un attaquant sur le chemin peut respecter le diamètre mais échouer à l’authentification. Un pair correctement authentifié peut annoncer un préfixe interdit ; la politique d’import doit encore le bloquer. Enfin, un trafic « Unknown » peut exiger une limitation séparée du plan de contrôle.

Confondre ces colonnes conduit soit à exagérer GTSM en l’appelant authentification, soit à le mépriser parce qu’il ne fait pas tout. Sa valeur est plus précise : il élimine tôt une classe de trafic dont la provenance topologique est incompatible, sans centraliser la décision ni interpréter les routes.

Une recette qui ose provoquer l’échec

Avant maintenance, capturer les deux sens et les deux familles. Vérifier que tout paquet protégé part à 255. Associer les valeurs reçues aux chemins ECMP, au trajet nominal et au trajet de secours. Identifier le seuil et le compteur qui matérialisera le premier rejet.

Prévoir ensuite la valeur après changement. Si elle passe de 253 à 252, choisir explicitement entre maintenir la topologie dans la frontière existante ou élargir le diamètre. La décision doit indiquer le bénéfice de disponibilité, la nouvelle exposition et, si elle est temporaire, sa date d’expiration.

Sur une relation canari isolée, envoyer un paquet au-dessus du seuil, un paquet exactement au seuil et un paquet une unité en dessous. Les deux premiers doivent atteindre la couche suivante ; le dernier doit incrémenter le compteur prédit sans apparaître dans TCP ou BGP. Tester séparément l’usurpation locale, une mauvaise clé et une route interdite : chaque cas doit échouer dans une couche différente.

Après la bascule, rapprocher compteurs GTSM, retransmissions TCP, échecs d’authentification, transitions BGP et routes reçues. L’absence de route n’identifie jamais à elle seule le responsable. Le rollback doit rétablir le chemin ou les seuils bilatéraux documentés, sans désactiver silencieusement la protection sur une extrémité.

Le paquet reçu à 252 n’est pas faux par nature. Il contredit un contrat qui exigeait 253. Toute la discipline de GTSM tient dans cette modestie : la proximité autorise le passage au contrôle suivant ; elle ne prononce ni identité, ni intégrité, ni droit de routage.