Résumé

  • GTSM fait partir le trafic protégé avec un TTL de 255 et permet au récepteur de comparer la valeur restante à la distance configurée avant le traitement BGP coûteux.
  • Le récepteur peut isoler ou rejeter un paquet trop éloigné, mais un TTL valide n’authentifie ni l’émetteur ni une route et n’arrête pas un adversaire déjà sur le chemin admis.

Un petit champ devient une frontière d’admission

BGP utilise TCP, mais une adresse source plausible ne prouve pas que le paquet vient du voisin configuré. Un attaquant distant peut fabriquer du trafic de contrôle et forcer le routeur à y consacrer du processeur. GTSM exploite une propriété normalement modifiée à chaque saut : le TTL IPv4, ou Hop Limit en IPv6, diminue pendant l’acheminement.

Pour deux pairs directement connectés, l’émetteur fixe la valeur à 255 et le récepteur exige 255 à l’arrivée. Un paquet lancé plus loin ne peut normalement récupérer les unités perdues. En multi-saut, une plage inférieure à 255 peut être configurée, mais chaque saut admis élargit aussi la zone depuis laquelle une valeur crédible peut être produite.

La RFC distingue trois catégories. Trusted désigne un paquet rattaché à une session protégée et reçu dans la plage attendue ; Dangerous, un paquet rattaché mais hors plage ; Unknown, un paquet qu’aucune session protégée n’explique. Ce sont des classifications d’exploitation, non des jugements sur l’intention.

Par défaut, les paquets Dangerous ne devraient pas concurrencer Trusted et Unknown pour les ressources et peuvent être rejetés. Le traitement GTSM ne doit pas éliminer Trusted ou Unknown du seul fait de cette classification. Le pouvoir accordé au récepteur reste donc précis : réserver l’attention du protocole au trafic dont la distance est plausible.

L’autorisation se configure

Pour les protocoles existants, GTSM est facultatif et la RFC 5082 ne définit aucune négociation automatique générique. Les opérateurs l’activent pair par pair ; la RFC 7454 rappelle que les deux extrémités d’une session BGP doivent être configurées. L’accord porte sur la distance, les messages ICMP associés et le traitement d’un changement de chemin.

L’émetteur doit produire les paquets protégés avec 255 sans décrément interne. Le récepteur doit les associer à la bonne session avant d’appliquer sa politique. Les tunnels, la décapsulation et le multi-saut compliquent ce calcul. Une migration peut invalider le seuil alors que l’identité des pairs ne change pas.

Les deux pairs bénéficient d’une moindre concurrence du trafic usurpé pour le processeur et la bande passante du plan de contrôle. Ils assument aussi la configuration, la surveillance et la gestion des changements. Le récepteur doit conserver les observations expliquant chaque classement.

La proximité n’est pas une authentification

Le mot Trusted ne doit pas devenir une conclusion excessive. GTSM ne remplace pas l’authentification. Un attaquant sur le lien ou à l’intérieur du diamètre admis peut encore usurper ou rejouer du trafic. Un TTL conforme ne prouve pas la possession d’une adresse, n’autorise pas un UPDATE et ne valide pas une annonce de route.

Une protection maximale dépend également d’un filtrage d’entrée strict. GTSM réduit les origines plausibles ; il ne répare ni les filtres de préfixes, ni la politique de routage, ni la protection TCP. Une hausse de Dangerous peut révéler une attaque distante, un seuil périmé ou une modification de tunnel. Elle n’identifie pas à elle seule un responsable.

Preuves et limites

La RFC 5082 définit la procédure, les catégories, le traitement des ressources, la configuration et les limites. La RFC 7454 l’applique à la sécurité opérationnelle BGP. Les RFC 4271 et 4272 décrivent la session BGP et ses risques. La lecture en termes de pouvoir et de coût relève de l’analyse.

Ces sources ne prouvent aucun déploiement nommé, aucune distance universelle ni aucune authentification par TTL. Elles ne prétendent pas que GTSM empêche à lui seul les fuites de routes, les annonces fausses ou toutes les réinitialisations.

Sources