Cloudflare mesure l’adoption de RFC 9234 et montre une prévention des fuites BGP encore inégale
Le 18 août 2026, Cloudflare a publié la mesure de l’adoption de RFC 9234, le mécanisme BGP Role et OTC qui détecte les fuites de routes à la source. Le constat est sans appel : le support reste inégal selon les constructeurs, et l’attribut OTC ne bloque une fuite que si tout le chemin le préserve.
18 août 2026. RFC 9234. OTC. Le 18 août 2026, Cloudflare a publié son suivi de l’adoption de RFC 9234, le standard IETF qui encode la relation entre deux réseaux directement dans BGP pour détecter et prévenir les fuites de routes. Trois chercheurs — Bryton Herdes, Iliana Xygkou et Mingwei Zhang — y mesurent qui a déployé le mécanisme, et le constat est sans appel : la prévention est inégale selon les constructeurs, et un attribut de route ne sert à rien si la moitié du chemin l’ignore.
Ce qu’est une fuite de route, et pourquoi elle coûte
Une fuite de route pousse le trafic par des chemins qu’il n’aurait jamais dû emprunter. BGP fonctionne sur les relations entre systèmes autonomes (AS) : un client paie son fournisseur pour accéder au reste d’Internet, tandis que deux pairs échangent du trafic sans règlement financier. Ces relations dessinent une hiérarchie « sans vallée » : une route apprise d’un fournisseur ou d’un pair ne doit être annoncée que vers le bas, vers les clients, jamais remontée vers un autre fournisseur ou pair.
Une fuite se produit quand cette intention est violée. Historiquement, chaque réseau devait l’implémenter seul, à coups de politiques de routage complexes et sujettes à l’erreur. C’est là qu’intervient RFC 9234 (« Route Leak Prevention and Detection Using Roles in UPDATE and OPEN Messages ») : elle exprime l’intention dans le protocole lui-même.
Le standard introduit deux briques. D’abord, une capacité « BGP Role » : deux voisins BGP doivent se mettre d’accord sur leur relation — provider, customer, peer — au moment où la session s’établit. Ensuite, un attribut de chemin « Only to Customer » (OTC), qui marque les routes devant rester chez les clients. Un routeur qui comprend OTC peut alors rejeter de lui-même une route qui fuit, sans qu’un opérateur ait écrit la moindre politique.
La mesure : tout le monde n’est pas au niveau
Le travail de Cloudflare ne se contente pas d’expliquer le standard : il mesure son adoption sur le réseau public. Le résultat le plus frappant concerne Arelion (AS1299), un grand tier-1. Les chercheurs ont constaté que ses chemins perdaient l’attribut OTC en transit — autrement dit, le réseau supprimait la marque censée protéger la route. Après un échange avec l’équipe, Arelion a déployé une configuration qui préserve l’OTC, et les chercheurs l’ont vérifié sur leurs préfixes d’expérimentation via monocle, l’outil d’analyse de routes.
C’est la démonstration la plus utile de l’article : la prévention des fuites par OTC est fragile de bout en bout. L’attribut doit survivre à chaque saut pour qu’un routeur aval puisse trancher. Un seul AS intermédiaire qui le supprime — volontairement ou par défaut — et la protection s’évapore.
Le tableau de support, arrêté en août 2026, raconte la même histoire côté équipementiers :
| Implémentation BGP | Support RFC 9234 |
|---|---|
| Junos OS / Junos Evolved | Oui |
| RouterOS (MikroTik) | Oui |
| BIRD | Oui |
| OpenBGPD | Oui |
| FRR | Oui |
| Cisco IOS XR | À venir en 26.4.1 |
| Arista EOS | Non |
| Nokia SR OS | Non |
| Huawei | Non |
| Extreme SLX-OS | Non |
| ArcOS | Non |
| GoBGP | Non |
| ExaBGP | Non |
La lecture est immédiate : les routeurs ouverts (BIRD, OpenBGPD, FRR, RouterOS) ont pris de l’avance, Juniper a livré, tandis que la plupart des grands constructeurs propriétaires — Arista, Nokia, Huawei, Extreme — ne supportent toujours pas le standard, et Cisco ne l’aura qu’avec la version 26.4.1 d’IOS XR.
Ce qu’il faut configurer, et dans quel ordre
Cloudflare a commencé son déploiement progressif de RFC 9234 sur sa flotte mondiale, et recommande aux opérateurs dont l’équipementier est prêt de configurer les rôles maintenant. Un point opérationnel compte : appliquer les rôles réinitialise les sessions BGP. Le déploiement se planifie donc en fenêtre de maintenance, lien par lien, avec un repli documenté.
La hiérarchie des protections vaut la peine d’être posée. RPKI et la validation d’origine (ROV) — que nous avions détaillée dans notre guide RPKI/ROV — répondent à une autre question : « cet AS est-il légitime pour ce préfixe ? ». RFC 9234 répond, elle, à « cette route a-t-elle le droit de remonter vers moi ? ». Ce sont deux étages complémentaires, pas concurrents. À terme, ASPA ajoutera un troisième verrou, côté fournisseur, pour rejeter les annonces d’un client qui ne serait pas le vrai chemin.
Comment l’OTC se propage, et où il se perd
Le mécanisme mérite d’être compris en détail, car c’est lui qui explique la fragilité mesurée. OTC est un attribut de chemin transitif : un routeur qui l’émet le pose sur la route, et chaque saut est censé le conserver avant de décider. Un routeur qui reçoit une route marquée OTC de la part d’un pair ou d’un fournisseur sait qu’elle n’a rien à faire chez lui : elle remonte, au lieu de descendre, et il peut la rejeter.
Le problème est que cette conservation n’est pas garantie. Un AS intermédiaire dont l’implémentation ne connaît pas l’attribut, ou dont la politique le supprime, brise la chaîne. C’est exactement ce que Cloudflare a observé chez Arelion : l’attribut disparaissait en transit, neutralisant la protection pour tous les réseaux en aval.
Le précédent le plus cité reste la fuite du 24 juin 2019. Ce jour-là, Verizon (AS701) a accepté puis propagé des milliers de routes de DQE Communications (AS396531), un petit FAI de Pennsylvanie, à cause d’un optimiseur BGP mal configuré. Le trafic de Cloudflare, d’Amazon et de Facebook a transité par un réseau qui n’était pas censé le porter, provoquant une saturation et des coupures pendant près de deux heures. RFC 9234 a précisément été conçu pour empêcher ce scénario : un routeur aval qui comprend OTC aurait rejeté ces routes.
Reste une asymétrie que les opérateurs doivent accepter : configurer les rôles de son côté protège ses propres sessions, mais la protection de bout en bout dépend aussi de ce que font les AS en amont. Un réseau qui préserve OTC correctement hérite quand même de la défaillance d’un voisin qui le supprime. C’est tout l’enjeu des initiatives comme MANRS (Mutually Agreed Norms for Routing Security), qui poussent les réseaux à adopter ensemble ROV, l’anti-usurpation et la prévention des fuites : RFC 9234 s’inscrit naturellement dans leur quatrième action.
Verdict
Si votre routeur supporte RFC 9234 — Junos, RouterOS, BIRD, OpenBGPD ou FRR — configurez les rôles dès la prochaine maintenance. Le gain est automatique : une fois les rôles posés, la protection par OTC ne dépend plus de politiques que quelqu’un doit encore écrire et relire.
Si votre constructeur ne supporte pas encore le standard, le levier n’est pas technique mais commercial : demandez une date. Tant qu’Arista, Nokia, Huawei ou Cisco (avant 26.4.1) n’ont pas livré, votre réseau reste un maillon qui peut laisser fuir — le vôtre ou celui de votre voisin.
La conclusion tient en une phrase : la fuite de route est un problème de bout en bout, et RFC 9234 est le premier mécanisme qui la traite comme tel. Sa valeur réelle dépend de la part du chemin qui le comprend — et cette part, aujourd’hui, reste trop inégale pour s’en remettre à elle seule.