BGP, Internet, anycast et sécurité des annonces

BGP, Internet, anycast et sécurité des annonces

Internet n’a pas de centre ni de table de routage officielle : il est fait de quelques dizaines de milliers de réseaux indépendants qui se racontent mutuellement ce qu’ils savent joindre. Le protocole de ce récit est BGP (Border Gateway Protocol), dans sa version 4 décrite par le RFC (Request for Comments) 4271. Il ne cherche pas le chemin le plus court, mais celui que la politique de chaque réseau préfère, et il fait largement confiance à ce qu’on lui annonce. Ce chapitre explique cette logique, son usage pour l’anycast, puis les incidents qu’elle permet et les protections, toutes partielles, qui les limitent.

Explication de la marmotte

Internet ressemble à un ensemble de villes reliées par des routes, où chaque ville annonce à ses voisines les quartiers qu’elle sait desservir. Ce chapitre montre comment ces annonces décident du chemin suivi par les données, et pourquoi une annonce fausse, par erreur ou par malice, peut détourner une partie du trafic.

→ Lire l’explication complète de la marmotte

Internet comme réseau de réseaux

Systèmes autonomes, préfixes et annonces

Un système autonome (AS, Autonomous System) est un réseau placé sous une politique de routage unique : un fournisseur d’accès, un hébergeur, une université, une grande entreprise. Il est identifié par un numéro, l’ASN (Autonomous System Number), codé sur 16 bits à l’origine puis sur 32 bits (RFC 6793). Les plages 64496 à 64511 sont réservées à la documentation (RFC 5398) et servent aux exemples de ce chapitre ; les plages 64512 à 65534 et 4200000000 à 4294967294 sont privées (RFC 6996).

Chaque AS annonce des préfixes, blocs d’adresses notés en CIDR (Classless Inter-Domain Routing) comme 203.0.113.0/24. L’annonce porte des attributs, dont l’AS_PATH, la liste des AS traversés : chaque AS qui relaie une route y ajoute son numéro. Cette liste sert à la fois de métrique grossière et d’anti-boucle, puisqu’un AS rejette une route contenant déjà son propre numéro.

Les sessions BGP s’établissent sur TCP (Transmission Control Protocol), port 179, entre voisins configurés explicitement. Une session entre deux AS différents est de l’eBGP (external BGP) ; une session entre routeurs d’un même AS est de l’iBGP (internal BGP), qui diffuse en interne les routes apprises à la frontière sans modifier l’AS_PATH. Un routeur ne relaie pas à un pair iBGP une route apprise en iBGP, d’où le maillage complet entre routeurs internes, ou les réflecteurs de routes (RFC 4456) qui l’évitent. L’iBGP ne remplace pas le routage interne : il s’appuie dessus pour joindre les prochains sauts (voir Routage interne, redistribution et stabilité).

Peering, transit et argent

Les relations entre AS sont d’abord commerciales. Le transit est un service payant : l’upstream (fournisseur amont) transporte le trafic de son client vers tout Internet et annonce ses préfixes au reste du monde. Le peering est un échange, souvent gratuit, entre deux AS qui s’envoient directement le trafic destiné à leurs clients respectifs, typiquement sur un point d’échange Internet. La règle de bon sens qui en découle, formalisée par Gao et Rexford : un AS préfère les routes apprises de ses clients (qui le paient), puis de ses pairs (gratuits), puis de ses fournisseurs (qu’il paie), et il n’annonce les routes de ses pairs et fournisseurs qu’à ses clients. Personne ne transporte gratuitement le trafic de deux tiers qui ne le rémunèrent pas.

Pourquoi BGP ne prend pas le plus court chemin

Quand plusieurs routes existent pour un même préfixe, BGP applique une suite de critères. L’ordre courant, avec des variantes selon les constructeurs, est le suivant :

1. LOCAL_PREF le plus élevé : préférence locale, fixée par l’AS lui-même pour traduire sa politique (client avant pair avant fournisseur) ;
2. route originée localement ;
3. AS_PATH le plus court ;
4. origine (IGP avant EGP avant incomplete) ;
5. MED (Multi-Exit Discriminator) le plus bas, indication donnée par un voisin sur le point d’entrée qu’il préfère ;
6. eBGP avant iBGP ;
7. coût interne le plus faible vers le prochain saut ;
8. critères de départage (ancienneté, identifiant de routeur).

La préférence locale passe avant la longueur du chemin : une route à cinq AS via un client battra une route à deux AS via un fournisseur payant. Les communities (RFC 1997, étendues par les large communities du RFC 8092) sont des étiquettes attachées aux routes, qui permettent à un client de demander à son fournisseur un traitement particulier : ne pas annoncer à tel pair, baisser la préférence, ou jeter le trafic. La community bien connue NO_EXPORT interdit la diffusion hors de l’AS voisin.

Enfin, au moment de transmettre un paquet, le routeur applique la correspondance du préfixe le plus long : entre 203.0.113.0/24 et 203.0.113.128/25, le /25 gagne pour les adresses qu’il couvre, quel que soit son AS_PATH. Cette règle, saine en soi (voir Décision de chemin, routes statiques et routage système), est la porte d’entrée des détournements. Par convention, la plupart des réseaux refusent les annonces IPv4 plus spécifiques qu’un /24 et IPv6 plus spécifiques qu’un /48.

Anycast et usages modernes

Un service, plusieurs lieux

L’anycast consiste à annoncer le même préfixe depuis plusieurs sites. Chaque utilisateur est acheminé vers l’instance que le routage lui fait atteindre en premier, généralement proche en termes de topologie, pas forcément en kilomètres. Les serveurs racine du DNS (Domain Name System) l’utilisent massivement : treize identités logiques, plus d’un millier d’instances dans le monde. Les résolveurs publics comme 1.1.1.1 ou 8.8.8.8, les CDN (Content Delivery Network) et les services de nettoyage DDoS (Distributed Denial of Service) fonctionnent de la même façon. Pour ces derniers, l’anycast est une arme : une attaque distribuée est absorbée par tous les sites à la fois, chacun ne recevant que la part venue de sa région. Les centres de scrubbing peuvent aussi annoncer temporairement le préfixe d’un client attaqué, recevoir tout son trafic, le filtrer et ne lui renvoyer que le propre.

À l’opposé, le blackholing sacrifie la cible pour sauver le reste : le client marque une route /32 vers l’adresse attaquée avec la community BLACKHOLE (65535:666, RFC 7999), et son fournisseur jette tout le trafic vers cette adresse. L’attaque réussit, mais le reste du réseau respire.

Limites du dépannage

L’anycast complique le diagnostic : deux utilisateurs qui interrogent « la même » adresse ne parlent pas au même serveur. Un incident ne touche parfois qu’une instance, donc qu’une région. Il faut identifier l’instance atteinte, par exemple avec dig @1.1.1.1 id.server CH TXT ou dig +nsid, qui renvoient un identifiant de site sur de nombreux serveurs DNS, puis comparer depuis plusieurs points de vue : sondes RIPE Atlas, looking glasses des opérateurs, collecteurs publics comme RIPE RIS ou RouteViews, et des outils de visualisation comme RIPEstat, bgp.tools ou bgp.he.net. L’anycast n’est pas le round-robin DNS : le second renvoie plusieurs adresses différentes et laisse le client choisir, le premier publie une seule adresse et laisse le routage choisir.

Sécurité du routage global

Détournements, fuites et mauvaise origine

Le prefix hijacking consiste à annoncer un préfixe qu’on ne détient pas. En février 2008, Pakistan Telecom, chargé de bloquer YouTube dans le pays, a annoncé 208.65.153.0/24, plus spécifique que le /22 légitime ; l’annonce a fui vers son fournisseur et YouTube est devenu injoignable pour une large partie du monde pendant environ deux heures. En avril 2018, une annonce frauduleuse de préfixes d’Amazon Route 53 a redirigé les requêtes DNS de MyEtherWallet vers un faux site qui a dérobé des cryptomonnaies.

La route leak est différente : les annonces sont authentiques, mais relayées là où elles n’auraient pas dû l’être, en violation de la logique client, pair, fournisseur. En juin 2019, un petit réseau client de deux fournisseurs a relayé vers l’un des routes plus spécifiques reçues de l’autre ; Verizon les a acceptées et propagées, et une partie du trafic vers Cloudflare et d’autres services a transité pendant environ deux heures par un réseau incapable de l’absorber.

RPKI, ROA et validation d’origine

La RPKI (Resource Public Key Infrastructure) permet au détenteur d’adresses de publier, signé par la chaîne de certificats de son registre régional, un ROA (Route Origin Authorization) qui dit quel AS a le droit d’annoncer quel préfixe, et jusqu’à quelle longueur. Les routeurs, alimentés par un validateur (Routinator, rpki-client ou FORT, par exemple) via le protocole RTR (RPKI to Router), appliquent la validation d’origine (ROV, Route Origin Validation, RFC 6811) : chaque route devient Valid, Invalid ou NotFound. La bonne pratique largement adoptée par les grands réseaux consiste à rejeter les routes Invalid.

Un ROA se lit ainsi :

Préfixe       : 203.0.113.0/24
maxLength     : 24
ASN d'origine : AS64496

Une annonce de 203.0.113.0/24 par AS64496 est Valid. La même par AS64499 est Invalid. Une annonce de 203.0.113.0/25 par AS64496 est aussi Invalid, car elle dépasse le maxLength : c’est voulu, et c’est pourquoi un maxLength trop généreux (/24 autorisé jusqu’à /28 sans besoin) offre à un détourneur la possibilité d’annoncer un plus spécifique « valide » s’il usurpe l’AS d’origine.

Ce que la RPKI ne résout pas

La validation d’origine ne vérifie que le dernier numéro de l’AS_PATH. Un attaquant qui annonce le préfixe en plaçant l’AS légitime en fin de chemin passe le contrôle. Elle ne détecte pas non plus les route leaks, puisque l’origine y est exacte. Des mécanismes complémentaires existent : BGPsec (RFC 8205), qui signe tout le chemin mais reste très peu déployé, et ASPA (Autonomous System Provider Authorization), en cours de normalisation, qui publie la liste des fournisseurs de chaque AS. Et surtout, la RPKI ne chiffre rien : elle limite les détours, elle ne protège pas le contenu, qui relève de TLS (Transport Layer Security).

Le reste repose sur l’hygiène de chaque opérateur : filtrage de préfixes par voisin, construit à partir des registres de routage (IRR, Internet Routing Registry) avec des outils comme bgpq4 ; max-prefix, qui coupe une session dont le voisin annonce soudain bien plus de routes que prévu ; refus des préfixes réservés et des ASN privés. L’initiative MANRS (Mutually Agreed Norms for Routing Security) rassemble ces engagements.

Exemples et ateliers

Trois AS. AS64496 (fournisseur de transit) a deux clients, AS64497 et AS64498, qui sont aussi pairs entre eux sur un point d’échange. AS64497 joint AS64498 par le peering (LOCAL_PREF plus élevée, gratuit), et non par le transit. AS64497 n’annonce pas à AS64498 les routes reçues de AS64496 : sinon AS64498 pourrait utiliser AS64497 comme transit gratuit, ce qui serait précisément une route leak.

L’annonce plus spécifique. AS64498 annonce 2001:db8::/32. Un AS tiers annonce 2001:db8:8000::/33, qui reste bien plus court que la limite usuelle du /48 et passe donc les filtres de longueur. Chez les réseaux qui ne valident pas, le /33 l’emporte pour la moitié de l’espace, quel que soit l’AS_PATH. Si AS64498 a publié un ROA (2001:db8::/32, maxLength 32, AS64498), le /33 est Invalid chez tous ceux qui valident, et rejeté. La parade d’urgence d’une victime sans ROA consiste à annoncer elle-même des préfixes encore plus spécifiques, pour reprendre l’avantage, ce qui marche jusqu’à la limite du /48.

Lire une configuration de garde-fous. Sur une session client, en pseudo-configuration :

neighbor 192.0.2.10 remote-as 64497
neighbor 192.0.2.10 prefix-list CLIENT-64497 in
neighbor 192.0.2.10 maximum-prefix 50

La liste n’accepte que les préfixes enregistrés pour ce client ; au-delà de 50 routes, la session est coupée plutôt que d’accepter une table entière par erreur.

Pièges classiques

Croire que BGP choisit le plus court chemin conduit à des diagnostics faux : la préférence locale et les accords commerciaux décident d’abord. Ne pas publier de ROA prive les réseaux qui valident de tout moyen de trancher. Accepter trop de routes d’un pair, sans filtre ni max-prefix, transforme son erreur en incident pour tout l’Internet qui écoute. Et publier un ROA sans mettre à jour toutes les annonces légitimes (un plus spécifique pour un site de secours, un AS d’origine chez un prestataire anti-DDoS) rend Invalid ses propres routes, ce qui est une manière très sûre de se protéger de soi-même.

🐝 Ce qui arrive si on s’en passe

Sans validation d’origine ni filtrage des annonces, un réseau accepte toute déclaration de ses pairs : une annonce plus spécifique d’un préfixe qui ne leur appartient pas suffit à attirer le trafic d’autrui, qui peut être lu, altéré ou simplement jeté, pendant que la victime constate une panne sans cause visible depuis chez elle. Sans ROA publiés, les réseaux voisins qui valident n’ont rien pour trancher : l’annonce frauduleuse et la légitime se valent. Sans limite du nombre de préfixes, une erreur de configuration chez un pair se propage à tout ce qui l’écoute. Et comme l’anycast sert chaque région depuis un site différent, un détournement partiel ne se voit que depuis certaines régions, ce qui rend son diagnostic particulièrement lent.

🦫 Explication de la marmotte 🍫

Internet est formé de nombreux réseaux indépendants, appelés systèmes autonomes : un fournisseur d’accès, un hébergeur, une grande entreprise. Chacun possède des blocs d’adresses, appelés préfixes. Pour que le trafic arrive, chaque réseau annonce à ses voisins les préfixes qu’il sait joindre, grâce à un protocole nommé BGP. Les voisins relaient ces annonces en ajoutant leur propre numéro à la liste des réseaux traversés. Chaque réseau choisit ensuite quelle route utiliser, pas forcément la plus courte : il suit ses accords, en préférant par exemple un voisin avec qui l’échange est gratuit plutôt qu’un fournisseur payant. Quand deux annonces couvrent les mêmes adresses, la plus précise l’emporte. C’est ce qui rend possibles les détournements : un réseau qui annonce, par erreur ou volontairement, des adresses qui ne lui appartiennent pas attire vers lui le trafic destiné à leur vrai propriétaire. Une fuite de routes se produit quand un réseau relaie des annonces qu’il aurait dû garder pour lui. Pour limiter ces risques, les propriétaires d’adresses publient des attestations signées qui indiquent quel réseau a le droit de les annoncer, et les autres réseaux vérifient l’origine des annonces reçues et limitent ce qu’ils acceptent de chaque voisin. Ces contrôles ne vérifient que l’origine et ne chiffrent rien. Enfin, un même service peut être annoncé depuis plusieurs lieux : chaque utilisateur rejoint alors le plus proche selon le routage.

À lire aussi

• Géographie d'internet, câbles sous-marins et points d'atterrissementAnatomie des câbles sous-marins, routes et points de concentration, pannes, menaces, latence, et ce que cette géographie physique impose à une architecture.
• MPLS, GMPLS, SD-WAN et overlays opérateursExpliquer les architectures WAN et opérateurs au-delà d’IP routé : labels, circuits virtuels, transport optique, overlays, SD-WAN et technologies héritées.
• GRE, IPsec ou GRE dans IPsec pour un tunnel site à siteChoisir entre GRE, IPsec et GRE dans IPsec pour relier deux sites, selon le chiffrement, le routage dynamique, le multicast et le coût en MTU.
• IPv4, CIDR et plans d’adressageApprendre à lire, calculer et concevoir un adressage IPv4 cohérent pour LAN, DMZ, VPN, cloud, laboratoires et environnements multi-sites.

Pages voisines

La citent

• Géographie d'internet, câbles sous-marins et points d'atterrissement
• Continuité, sauvegardes, PRA/PCA et haute disponibilité
• Flux inter-cloud et résidence réelle des données
• Menaces réseau, détection et réponse opérationnelle

BGP, Internet, anycast et sécurité des annonces

Elle cite

• ⇄Lien dans les deux sens :Décision de chemin, routes statiques et routage système
• ⇄Lien dans les deux sens :Routage interne, redistribution et stabilité
• ⇄Lien dans les deux sens :BGP, la confiance par défaut
• Défendre un DDoS volumétrique et applicatif

⇄ : les deux pages se citent l’une l’autre.