La manière dont nous détections les fuites de routage et notre nouveau service de routage Cloudflare Radar

Nous lançons aujourd'hui l'API et les données sur les fuites de routage de Cloudflare Radar, afin que chacun puisse bénéficier d'informations sur ces fuites sur l'ensemble d'Internet. Nous avons mis au point un système complet reposant sur les données issues de sources publiques et du point de vue sur Internet dont profite Cloudflare grâce à son gigantesque réseau mondial. Le système envoie actuellement des données sur les fuites de routage aux pages des ASN de Cloudflare Radar, ainsi que via l'API.

Cet article se compose de deux parties. Il commence par une discussion sur le BGP et les fuites de routage, suivie par des détails sur notre système de détection de ces fuites et la manière dont il alimente Cloudflare Radar.

À propos du BGP et des fuites de routage

Le routage interdomaines (c'est-à-dire, l'échange d'informations d'accessibilité entre réseaux) se révèle essentiel à l'intégrité et aux performances d'Internet. Le Border Gateway Protocol (BGP) est le protocole permettant d'échanger de facto des informations de routage entre entreprises et réseaux. Fondamentalement, le protocole BGP part du principe que les informations échangées sont authentiques et dignes de confiance, un point qui ne constitue malheureusement plus une hypothèse plausible sur le réseau Internet actuel. Il arrive fréquemment que les réseaux commettent des erreurs ou mentent intentionnellement sur les informations d'accessibilité et propagent ce mensonge au reste d'Internet. Ces incidents peuvent entraîner de considérables perturbations des opérations habituelles du réseau Internet. Les fuites de routage sont l'un de ces types d'incidents perturbateurs.

Nous définissons les fuites de routage comme la propagation d'annonces de routage au-delà de leur portée prévue (RFC7908). Ces fuites peuvent entraîner des perturbations affectant des millions d'internautes, comme nous l'avons observé lors de nombreux incidents notables. Pour prendre un exemple, en juin 2019, une erreur de configuration au sein d'un petit réseau de Pennsylvanie, aux États-Unis (AS396531 – Allegheny Technologies Inc), a accidentellement fait fuiter un préfixe Cloudflare vers Verizon, qui a continué à propager l'itinéraire mal configuré au reste de ses pairs et de ses clients. En résultat, le trafic d'une grande partie d'Internet s'est retrouvé redirigé via les liaisons à capacité limitée d'un petit réseau, au sein desquelles il a été fortement comprimé. Les encombrements qui s'en sont suivis ont entraîné la chute de la plupart du trafic Cloudflare et de la plage IP affectée.

Un incident similaire survenu en novembre 2018 a entraîné l'indisponibilité des services Google lorsqu'un FAI nigérian (AS37282 – a Mainone) accidentellement fait fuiter un grand nombre de préfixes IP Google vers ses pairs et ses fournisseurs, violant ainsi le principe « valley-free » (sans vallée).

Ces incidents illustrent non seulement le fait que l'impact des fuites de routage peut s'avérer considérable, mais aussi l'effet boule de neige que ces erreurs de configuration au sein de petits réseaux régionaux peuvent avoir sur le réseau Internet mondial.

Malgré le caractère essentiel de la détection et de la correction rapides des fuites de routage, ces erreurs ne sont souvent détectées que lorsque les utilisateurs commencent à signaler les effets remarquables de ces fuites. Les défis liés à la détection et à la prévention des fuites de routage proviennent du fait que les relations d'affaires entre AS et les politiques de routage BGP sont généralement confidentielles et que le réseau affecté se révèle souvent éloigné de la racine de la fuite de routage.

Ces dernières années, des solutions ont été proposées pour empêcher la propagation des itinéraires exposés à des fuites. Ces propositions comprennent la RFC9234 et l'ASPA, qui étendent les fonctionnalités du BGP en lui permettant d'annoter des sessions en indiquant le type de relation entre les deux réseaux AS connectés afin d'autoriser la détection et la prévention des fuites de routage.

Une autre possibilité à la mise en œuvre d'un mécanisme de signalement des rôles BGP consiste à utiliser les communautés BGP, un attribut transitif servant à encoder les métadonnées au sein des annonces BGP. Si ces directions s'avèrent prometteuses sur le long terme, elles en sont encore à des stades tout à fait préliminaires et ne devraient pas être adoptées à grande échelle de sitôt.

Chez Cloudflare, nous avons développé un système permettant de détecter automatiquement les événements de fuite de routage et d'envoyer des notifications vers plusieurs canaux afin d'en renforcer la visibilité. Tandis que nous poursuivons nos efforts visant à offrir davantage de données pertinentes au grand public, nous sommes heureux d'annoncer que nous lançons aujourd'hui une API open data pour nos résultats de détection des fuites de routage, résultats qui seront également intégrés aux pages de Cloudflare Radar.

La définition et les différents types de fuites de routage

Avant de passer à la manière dont nous concevons nos systèmes, nous allons tout d'abord effectuer un rapide tour d'horizon de ce qu'est une fuite de routage et des raisons pour lesquelles il est important de les détecter.

Pour définir les fuites de routage, nous nous référons au document RFC7908 « Problem Definition and Classification of BGP Route Leaks » (Définition des problèmes et classification des fuites de routage BGP) publié par l'IETF.

> Une fuite de routage consiste en la propagation d'une ou plusieurs annonces de routage au-delà de leur portée prévue.

La portée prévue est souvent concrètement définie comme les politiques de routage interdomaines basées sur les relations d'affaires entre systèmes autonomes (Autonomous Systems, AS). Ces relations d'affaires sont grossièrement classées dans quatre catégories : clients, fournisseurs de transit, pairs et membres de la famille, bien que des arrangements plus complexes soient possibles.

Dans une relation de client à fournisseur, l'AS du client dispose d'un accord avec un autre réseau pour faire transiter son trafic sur la table de routage générale. Dans une relation de pair-à-pair (peer-to-peer), deux AS acceptent d'échanger leur trafic librement et de manière bilatérale, mais uniquement entre leurs propres adresses IP et les adresses IP de leurs clients. Enfin, les AS qui appartiennent à la même entité administrative sont considérés comme membres de la même famille. Leur trafic n'est donc généralement pas restreint.  Le visuel ci-dessous montre de quelle manière les trois types de relations se traduisent en politiques d'exportation.

En catégorisant les types de relations au niveau de l'AS et leurs implications sur la propagation des itinéraires BGP, nous pouvons définir plusieurs phases d'annonces d'origination du préfixe pendant la propagation :

• Phase ascendante (upward) : pendant cette phase, tous les segments du chemin vont du client vers le fournisseur.
• Phase de peering : un unique segment pair-à-pair.
• Phase descendante (downward) : pendant cette phase, tous les segments du chemin vont du fournisseur vers le client.

Un chemin d'AS qui suit le principe de routage « valley-free » (sans vallée) présentera les phases ascendante, de peering et descendante. Elles sont toutes facultatives, mais doivent figurer dans cet ordre. Voici un exemple de chemin d'AS qui se conforme au routage sans vallée.

Dans la RFC7908, « Problem Definition and Classification of BGP Route Leaks » (Définition des problèmes et classification des fuites de routage BGP), les auteurs définissent six types de fuites de routage. Nous nous référons nous-mêmes à ces définitions dans notre processus de conception de systèmes. Vous trouverez ci-dessous des illustrations décrivant chaque type de fuite de routage.

Type 1 : virage en épingle à cheveux (Hairpin Turn) avec préfixe intégral

> Un AS multi-hébergé apprend un itinéraire de la part d'un FAI situé en amont et le propage tout simplement vers un autre FAI (le virage ressemble essentiellement à une épingle à cheveux).  Ni le préfixe ni le chemin d'AS contenus dans la mise à jour ne sont altérés.

Un chemin d'AS qui contient un segment fournisseur-client et client-fournisseur est considéré comme une fuite de type 1, comme dans l'exemple suivant : AS4 → AS5 → AS6.

Le type 1 est le type de fuite de routage le plus reconnu et se révèle particulièrement impactant. Dans de nombreux cas, un itinéraire client est préférable à un itinéraire pair ou fournisseur. Dans cet exemple, l'AS6 préférera probablement envoyer le trafic via l'AS5 plutôt que via ses autres itinéraires pair ou fournisseur, en transformant ainsi l'AS5 en fournisseur de transit de manière involontaire. Ce point peut affecter considérablement les performances du trafic lié au préfixe fuité ou entraîner une interruption de service si l'AS fuité n'est pas provisionné pour traiter un fort afflux de trafic.

En juin 2015, Telekom Malaysia (AS4788), un FAI régional, a fait fuiter plus de 170 000 itinéraires appris de ses fournisseurs et de ses pairs vers son autre fournisseur Level3 (AS3549, aujourd'hui Lumen). Level3 a accepté les itinéraires et a continué à les propager vers ses réseaux en aval, une opération qui a, à son tour, entraîné d'importants problèmes de réseaux dans le monde entier.

Type 2 : fuite latérale FAI-FAI-FAI

La fuite de type 2 se définit par des itinéraires de propagation obtenus d'un pair vers un autre pair, créant ainsi deux segments de chemin pair-à-pair consécutifs ou plus.

Dans l'exemple suivant, la partie AS3 → AS4 → AS5 forme une fuite de type 2.

Un exemple de ce type de fuite intervient lorsque plus de trois réseaux très vastes apparaissent l'un après l'autre. Les réseaux très vastes (comme as Verizon et Lumen) n'achètent pas de transit les uns auprès des autres et le fait de disposer de plus de trois de ces réseaux l'un après l'autre sur le chemin indique souvent la présence d'une fuite de routage.

En réalité, il n'est toutefois pas inhabituel de voir plusieurs petits réseaux de peering échanger des itinéraires et se les transmettre l'un à l'autre. Il existe des raisons commerciales parfaitement légitimes pour disposer de ce type de chemin réseau. Comparativement au type 1, ce type de fuite nous inquiète moins.

Types 3 et 4 : itinéraires fournisseur vers un pair, itinéraires de pair vers un fournisseur

Ces deux types de fuites impliquent la propagation d'itinéraires depuis un fournisseur ou un pair, non pas vers un client, mais vers un autre pair ou un autre fournisseur. Les schémas ci-dessous illustrent ces deux types de fuites :

Comme dans l'exemple mentionné précédemment, un FAI nigérian appairé à Google a accidentellement fait fuiter son itinéraire vers son fournisseur AS4809 et ainsi généré une fuite de routage de type 4. Comme les itinéraires entre clients sont généralement préférés aux autres, le gros fournisseur (AS4809) a redirigé son trafic vers Google via son client (c.-à-d. l'ASN fuité), submergé le petit FAI et entraîné une interruption de Google pendant plus d'une heure.

Résumé des fuites de routage

Jusqu'ici, nous nous sommes intéressés aux quatre types de fuites de routage décrits dans la RFC7908. Le dénominateur commun de ces derniers est qu'ils sont tous définis par l'intermédiaire de relations entre l'AS et les autres parties (pairs, clients et fournisseurs). Nous résumons les types de fuites en catégorisant la propagation du chemin d'AS en fonction de l'endroit depuis lequel les itinéraires sont appris et vers lesquels ils sont propagés. Le tableau suivant présente les résultats.

Nous pouvons résumer le tableau entier à une règle unique : les itinéraires obtenus de la part d'un AS non client ne peuvent être propagés que vers des clients.

Remarque : les fuites de routage de type 5 et type 6 sont définies comme la réorigination de préfixe et l'annonce de préfixes privés. Le type 5 est plus étroitement lié aux usurpations de préfixes, que nous prévoyons d'étendre prochainement à nos systèmes, tandis que les fuites de type 6 se situent hors du cadre de ce travail. Les lecteurs intéressés peuvent se référer aux sections 3.5 et 3.6 de la RFC7908 pour plus d'informations.

Le système de détection des fuites de routage de Cloudflare Radar

Maintenant que nous savons ce qu'est une fuite de routage, parlons de la manière dont nous avons conçu notre système de détection de ces fuites.

À un très haut niveau, nous compartimentons notre système en trois composants différents :

1. Module de collecte des données brutes : responsable pour la collecte des données BGP issues de plusieurs sources et la transmission du flux de messages BGP vers les clients situés en aval.
2. Module de détection des fuites : pour déterminer si un chemin donné au niveau de l'AS est une fuite de routage, estimer le niveau de confiance de l'évaluation, ainsi qu'agréger et fournir les preuves externes nécessaires à l'analyse d'un événement.
3. Module de stockage et de notification : responsable pour la fourniture d'un accès aux événements de fuites de routage détectés et l'envoi de notifications aux parties concernées. Ses tâches peuvent également inclure la création d'un tableau de bord pour un accès facile, la possibilité de rechercher les événements historiques et la fourniture de l'interface utilisateur afin de réaliser des analyses de haut niveau des événements.

Module de collecte de données

Nous prenons en compte trois types de données :

1. Historiques : les fichiers d'archive BGP d'une certaine plage temporelle passée.
   a.Les archives BGP RouteViews et RIPE RIS
2. Semi-temps réel : les fichiers d'archive BGP dès qu'ils deviennent disponibles, avec un délai de 10 à 30 minutes.
   a. Les archives RouteViews et RIPE RIS accompagnées d'un agent de données qui vérifie périodiquement les nouveaux fichiers (p. ex. BGPKIT Broker)
3. Temps réel : les sources de données en temps réel véritable.
   a. RIPE RIS Live
   b. Sources BGP internes Cloudflare

Pour la version actuelle, nous utilisons les sources de données en semi-temps réel pour le système de détection (c.-à-d. les fichiers des mises à jour BGP de RouteViews et RIPE RIS). À des fins d'exhaustivité des données, nous traitons les données de l'ensemble des collecteurs publics de ces deux projets (un total de 63 collecteurs et plus de 2 400 pairs collecteurs) et mettons en œuvre un pipeline capable de se charger du traitement des données BGP, dès que les fichiers de données sont disponibles.

Pour l'indexage et le traitement des fichiers de données, nous avons déployé une instance BGPKIT Broker sur site dotée de la fonctionnalité Kafka activée pour la transmission des messages, ainsi qu'un pipeline de traitement de données MRT personnalisé et simultané, basé sur le SDK Rust BGPKIT Parser. Le module de collecte de données traite les fichiers MRT et convertit les résultats en un flux de messages BGP de plus de deux milliards de messages BGP par jour (soit environ 30 000 messages par seconde).

Détection des fuites de routage

Le module de détection des fuites de routage agit au niveau de chaque annonce BGP individuelle. Le composant de détection examine un message BGP à la fois et estime la probabilité qu'un message BGP donné soit le résultat d'un événement de fuite de routage.

Nous basons principalement notre algorithme de détection sur le modèle sans vallée, le plus à même, selon nous, de repérer la plupart des incidents notables de fuite de routage. Comme mentionné précédemment, la clé d'un faible nombre de faux positifs en matière de détection des fuites de routage grâce au modèle sans vallée consiste à disposer des relations précises établies au niveau de l'AS. Si ces types de relations ne sont pas annoncés par chaque AS, le domaine peut se targuer de plus de deux décennies de recherches sur l'analyse des types de relations à l'aide des données BGP publiquement observées.

Malgré la précision extrême dont font preuve les algorithmes d'analyse des relations les plus récents et les plus avancés, la moindre des marges d'erreur peut induire des inexactitudes au niveau de la détection des fuites de routage. Afin d'atténuer l'impact de ces artéfacts, nous synthétisons plusieurs sources de données pour analyser les relations au niveau de l'AS, notamment les données du CAIDA/UCSD relatives aux relations des AS et notre ensemble de données compilé en interne sur ces mêmes relations. En nous appuyant sur les deux relations au niveau de l'AS, nous développons un ensemble de données bien plus précis concernant les niveaux du « préfixe » et du « pair ». Ainsi, cet ensemble de données amélioré nous permet, par exemple, de définir le type de relation entre l'AS1 et l'AS2 par rapport au préfixe P observé par le pair de collecte X. En éliminant la plus grande partie des ambiguïtés dans les scénarios au sein desquels les réseaux disposent de plusieurs relations différentes en fonction des préfixes et de la géolocalisation, cette approche nous permet de réduire le nombre de faux positifs dans le système. Et pour le réduire encore davantage, nous appliquons également l'ensemble de données AS Hegemony compilé par IHR IIJ en plus des ensembles de données liées aux relations entre AS.

Stockage et présentation des fuites de routage

Après le traitement de chaque message BGP, nous stockons les entrées sur les fuites de routage générées au sein d'une base de données à des fins de stockage et d'exploration à long terme. Nous agrégeons également les annonces BGP relatives aux fuites de routage, avant de regrouper les fuites issues du même ASN et survenues sur une courte période sous la forme d'événements de fuite de routage. Les événements de fuite de routage pourront alors être utilisés par différentes applications en aval, comme les IU web, les API ou les alertes.

Les fuites de routage sur Cloudflare Radar

Cloudflare s'est donné pour mission de contribuer à bâtir un meilleur Internet. Or, cette tâche consiste également à partager nos efforts en matière de surveillance et de sécurisation du routage Internet. Nous lançons aujourd'hui notre système de détection des fuites de routage en bêta publique.

À compter de ce jour, les utilisateurs qui se rendront sur les pages des ASN sur Cloudflare Radar y découvriront la liste des fuites de routage qui affectent l'AS concerné. Nous considérons qu'un AS est affecté lorsque l'AS à l'origine de la fuite est situé à un saut d'un AS donné, quelle que soit la direction ou le fait que l'événement soit survenu avant ou après.

La page Cloudflare Radar d'un ASN page est accessible directement à l'adresse https://radar.cloudflare.com/as{ASN}. L'adresse https://radar.cloudflare.com/as174 permettra ainsi d'afficher la page de vue d'ensemble de l'AS174 de Cogent, par exemple. Les pages des ASN présentent désormais un espace dédié aux fuites de routage détectées qui affectent l'ASN actuel sur la plage temporelle sélectionnée.

Les utilisateurs peuvent également commencer à employer notre API de données publiques pour rechercher des événements de fuite de routage concernant un ASN donné. Notre API prend en charge le filtrage des résultats en fonction des plages temporelles et des AS impliqués. Vous trouverez ci-dessous une capture d'écran de la page de documentation de l'API dédiée aux événements de fuite de routage disponible sur le site récemment mis à jour regroupant les diverses documentations des API.

Nous reviendrons bientôt sur la sécurité du routage

Nous avons prévu de creuser encore bien davantage le domaine de la détection des fuites de routage. Cloudflare Radar va commencer à recevoir de nouvelles fonctionnalités au fil du temps, comme une page de visualisation mondiale, des notifications sur les fuites de routage, des API plus avancées, des scripts d'automatisation personnalisés et des ensembles de données reposant sur les archives précédentes. Vos retours et vos commentaires sont également très importants pour nous, afin de nous permettre de continuer à améliorer nos résultats de détection et de mieux communiquer les données au public.

Nous poursuivrons également nos efforts concernant d'autres thématiques importantes liées à la sécurité du routage Internet, notamment la détection des détournements BGP à l'échelle mondiale (pas uniquement limitée aux réseaux de nos clients donc), la surveillance de la validation RPKI, les outils et les designs architecturaux liés à l'open source, ainsi que les passerelles web centralisées chargées de la sécurité du routage. Notre objectif consiste à proposer les meilleures données et les meilleurs outils possible aux diverses communautés afin de nous permettre de développer tous ensemble un Internet meilleur et plus sécurisé.

En parallèle, nous avons lancé un salon Radar sur notre serveur Discord destiné aux développeurs. N'hésitez pas à vous y rendre et à nous parler. L'équipe est impatiente de recevoir vos retours et de répondre à vos questions.

Rendez-vous sur Cloudflare Radar pour découvrir davantage de statistiques liées à Internet. Vous pouvez également nous suivre sur Twitter pour plus d'actualités sur Radar.