Résumé

  • GTSM vérifie la proximité d’un paquet grâce au TTL IPv4 ou au Hop Limit IPv6 ; il n’authentifie pas l’émetteur et ne remplace pas la protection cryptographique de la session TCP BGP.
  • La réussite dépend du rayon de sauts configuré, du filtrage entrant, de la confiance accordée au voisin direct et du comportement des tunnels.
  • L’assurance du pair exige un reçu commun : valeur de saut observée, interface et tunnel, voisin approuvé, état des clés TCP-AO, session et responsable de chaque contrôle.

L’interconnexion physique vient d’être déplacée. Les deux routeurs BGP continuent d’émettre avec un TTL de 255 et tous les paquets reçus passent le contrôle GTSM. Le dossier de changement affirme alors que le pair distant a été authentifié.

La conclusion dépasse la preuve. Le contrôle indique qu’un paquet est arrivé dans le périmètre de sauts admis. Il ne dit pas quel système autorisé l’a produit, si une machine située sur le même lien pouvait le falsifier, si un tunnel a modifié la distance apparente ni si le segment portait un authentificateur cryptographique valide. La session et GTSM peuvent fonctionner parfaitement tandis que le mot « authentifié » reste injustifié.

La RFC 4271 place BGP au-dessus de TCP. Deux systèmes établissent une connexion TCP avant d’échanger les messages BGP. Il faut donc distinguer quatre questions : le paquet IP vient-il d’une distance plausible ; le segment TCP appartient-il à la connexion protégée ; le voisin configuré a-t-il accepté la session ; et l’organisation qui l’exploite possède-t-elle encore l’autorité d’échanger ces routes ? Un voyant vert ne peut répondre aux quatre.

La RFC 5082 fonde GTSM sur une asymétrie simple. Un pair directement connecté envoie les paquets du protocole avec la valeur maximale, 255. Un routeur qui transfère le paquet réduit cette valeur ; un récepteur qui attend 255 peut donc écarter un trafic probablement émis plus loin. Effectuée près du matériel de ligne, cette classification évite aussi que des paquets forgés consomment les ressources rares du plan de contrôle.

C’est une protection utile. Elle réduit la surface d’attaque et offre un test topologique peu coûteux avant le traitement du protocole. La RFC 7454 recommande donc la sécurité TTL pour les sessions BGP directement connectées.

Mais la limite est nette. La RFC 5082 précise que GTSM ne remplace pas l’authentification et ne protège pas contre l’usurpation ou la répétition effectuée sur le lien. Un appareil voisin compromis est assez proche. Un attaquant présent sur le segment de confiance l’est aussi. Un paquet produit ou décapsulé à une extrémité de tunnel admise peut également paraître assez proche. Le succès établit une proximité configurée, pas l’auteur.

Le mode multi-saut élargit encore l’écart. GTSM peut accepter un rayon de TTL configuré pour des loopbacks ou une session multihop. Chaque saut supplémentaire augmente toutefois le nombre d’endroits d’où un paquet plausible peut provenir. Une modification de topologie peut ainsi changer le sens du contrôle sans changer son seuil numérique.

Les tunnels ajoutent une ambiguïté. La RFC 5082 décrit plusieurs cas IP et MPLS : le TTL interne présenté au pair dépend de l’encapsulation, du mode de propagation et du fait que le décapsulateur soit ou non l’extrémité du protocole. L’intégrité et la terminaison du tunnel font donc partie de la preuve. Une alarme GTSM après migration peut révéler un nouveau chemin ; une réussite ne certifie pas le tunnel.

L’authentification cryptographique des segments répond à une autre question. La RFC 5925 définit TCP-AO pour les connexions longues telles que BGP. Un code d’authentification est calculé sur des éléments liés à la connexion, au moyen de clés maîtresses gérées et de clés de trafic propres à la connexion. Des extensions de numéros de séquence protègent contre la répétition lors du bouclage de l’espace de séquence TCP. Un résultat TCP-AO valide soutient l’affirmation que le segment vient d’un détenteur de la clé acceptée pour cette connexion.

TCP-AO ne supprime pas la gouvernance. Les opérateurs doivent lier une clé à une relation de peering, l’installer aux deux extrémités, définir sa période de validité, coordonner sa rotation et retirer les anciennes clés. Un MAC valide sous une clé qui aurait dû expirer reste cohérent cryptographiquement mais non autorisé sur le plan opérationnel.

Les protections sont plus fortes ensemble parce qu’elles échouent différemment. GTSM filtre tôt les paquets trop éloignés, le filtrage entrant réduit l’usurpation d’adresse, TCP-AO authentifie les segments et la configuration BGP relie la session à la relation prévue. Aucune ne doit emprunter le nom d’une autre.

Sources