Cloudflare a publié une analyse de la prévalence de la norme RFC 9234, utilisée pour limiter les fuites de routage dans le protocole BGP, en s’appuyant sur les données de sessions d’échange avec ses réseaux ainsi que sur des expériences au cours desquelles elle a annoncé des routes de test sur Internet. L’entreprise a constaté que 67 réseaux ajoutaient l’attribut Only to Customer, ou OTC, aux routes qu’ils envoyaient directement, mais elle a également découvert qu’un certain nombre de réseaux supprimaient cet attribut lors de la transmission des routes, ce qui réduit la capacité des réseaux compatibles à détecter les fuites et à les rejeter.
Les fuites BGP se produisent lorsqu’un réseau annonce à un autre fournisseur ou pair une route apprise auprès d’un fournisseur ou d’un pair, contrairement aux relations commerciales et à la logique hiérarchique supposée des routes Internet. Cela peut entraîner l’acheminement du trafic par un réseau qui n’était pas préparé à l’absorber ou qui n’était pas autorisé à le transmettre, avec un risque d’augmentation de la latence, de perte de paquets ou de pannes plus étendues.
Transférer les règles de prévention des fuites dans le protocole
Les mécanismes de protection traditionnels imposent à chaque opérateur de configurer des politiques manuelles, telles que des filtres de préfixes et des politiques extraites des bases IRR, ce qui nécessite de définir précisément la relation de chaque session BGP. La RFC 9234 propose de transférer une partie de cette charge au protocole lui-même au moyen de deux composants : BGP Roles et l’attribut OTC.
Les rôles BGP définissent la nature de la relation entre les voisins d’une session eBGP, par exemple Provider, Customer et Peer, ainsi que RS et RS-Client, associés aux serveurs de routes des points d’échange Internet. Lorsque les deux parties annoncent des rôles incompatibles, la session est rejetée avec une notification Role Mismatch, au lieu de se poursuivre jusqu’à ce que l’erreur apparaisse ultérieurement sous la forme d’une fuite réelle. En cas d’adoption partielle, la session peut fonctionner si un seul côté envoie le rôle, sauf si l’opérateur active le mode strict, qui rejette les sessions dans lesquelles l’autre partie n’annonce aucun rôle.
L’attribut OTC enregistre le numéro du système autonome qui l’a ajouté en premier, lorsque la route cesse de remonter la hiérarchie et commence à se diriger vers les clients. Une fois présent, l’attribut ne devrait pas permettre à la route d’être transmise à un fournisseur, à un pair ou à un serveur de routes ; un routeur compatible peut également rejeter une route portant l’OTC si elle arrive depuis une relation qui ne l’autorise pas. La prévention devient ainsi automatique après la configuration des rôles, au lieu de dépendre exclusivement d’une politique rédigée par l’opérateur pour chaque session.
Qu’a réellement mesuré Cloudflare ?
Cloudflare a utilisé les données BMP de ses routeurs et surveillé la valeur de l’OTC reçue de ses voisins directs pendant trois mois. L’entreprise considérait un réseau comme candidat à la conformité lorsque la valeur de l’attribut était égale au numéro de système du voisin, une méthode qui réduit l’ambiguïté apparaissant lors de l’analyse de routes passées par plusieurs réseaux. Ces mesures ont montré que 67 systèmes autonomes ajoutaient l’OTC, sachant que les serveurs de routes peuvent adopter les nouvelles fonctionnalités plus rapidement et que certains réseaux exploités par des particuliers apparaissaient dans une proportion notable des résultats.
L’analyse des données RIB publiques de RouteViews et de RIPE RIS a donné des résultats plus prudents. Après avoir tenté de distinguer les réseaux qui ajoutent l’OTC lors de l’envoi de ceux qui complètent une valeur manquante lors de la réception, Cloudflare a identifié 18 réseaux susceptibles d’ajouter l’attribut et 20 réseaux susceptibles de le compléter ; en combinant ces résultats avec ceux des voisins directs, l’entreprise est parvenue à 36 réseaux potentiellement conformes à la RFC 9234. L’entreprise souligne que la méthodologie peut ne pas détecter les réseaux possédant un nombre limité de routes ou de voisins.
Les réseaux qui ont supprimé l’OTC
Cloudflare a testé la propagation de l’OTC en annonçant un préfixe IPv4 et un autre IPv6 portant la valeur 13335 depuis ses sites d’échange, puis a analysé les messages BGP pendant l’annonce et le retrait à l’aide des données de RIPE RIS, de RouteViews et de données BMP locales. Lors de la première phase, l’entreprise a identifié six systèmes autonomes supprimant l’attribut, dont les deux réseaux de niveau 1 GTT, AS3257 et Arelion, AS1299. La poursuite de l’analyse des chemins plus longs a permis d’identifier neuf réseaux supplémentaires supprimant l’OTC.
L’attribut était absent de 33,1 % des chemins AS_PATH IPv4 et de 17 % des chemins IPv6 dans l’expérience. GTT, Arelion ou les deux apparaissaient dans 96,6 % des chemins IPv4 ayant perdu l’OTC et dans 92,9 % des chemins IPv6, Arelion représentant la majorité des cas. Lors de l’examen des chemins dont le saut suivant était l’un des deux réseaux, Cloudflare a constaté que GTT supprimait systématiquement l’attribut, tandis qu’Arelion le supprimait dans 71,4 % des chemins IPv4 et 40,7 % des chemins IPv6 de l’échantillon concerné.
Cloudflare a indiqué que les deux réseaux avaient confirmé que la suppression de l’OTC faisait partie de pratiques défensives apparues après des incidents liés au traitement d’erreurs BGP. Selon les résultats publiés, les configurations de GTT continuaient de supprimer l’attribut, tandis qu’Arelion a commencé à le préserver après avoir été contacté par Cloudflare, ce qu’une analyse ultérieure des routes de test a confirmé.
Qu’est-ce qui change concrètement pour les opérateurs de réseaux ?
Les résultats montrent que l’adoption de la RFC 9234 ne dépend pas uniquement de la prise en charge de la fonctionnalité par les routeurs, mais aussi de la capacité des réseaux intermédiaires à continuer de transmettre l’attribut transitant, de manière facultative. La suppression de l’OTC dans un réseau situé à un emplacement central peut empêcher un réseau compatible situé plusieurs sauts plus loin de détecter une fuite qui aurait pu être évitée.
Cloudflare indique que Junos OS et Junos OS Evolved prennent en charge la RFC 9234 et que la prise en charge de Cisco IOS XR était prévue dans la version 26.4.1, tandis que d’autres implémentations figuraient dans son tableau sans état de prise en charge complet, notamment Arista EOS, Nokia SR OS, Huawei, Extreme SLX-OS, RouterOS, BIRD, OpenBGPD, FRR, ArcOS, GoBGP et ExaBGP. L’entreprise recommande aux opérateurs disposant de cette fonctionnalité de configurer progressivement les rôles BGP pendant les fenêtres de maintenance, car leur mise en œuvre nécessite de réinitialiser les sessions BGP. Cloudflare a également commencé à déployer progressivement les configurations sur l’ensemble de son parc mondial et prévoit de rendre les données d’adoption disponibles dans la section consacrée au routage de Cloudflare Radar.