Incident affectant Cloudflare 1.1.1.1 le 27 juin 2024

Le 27 juin 2024, un petit nombre d'utilisateurs dans le monde est susceptible d'avoir remarqué que le résolveur 1.1.1.1 était inaccessible ou que son fonctionnement était altéré. La cause fondamentale était à la fois un détournement et une fuite de routage du protocole BGP (Border Gateway Protocol).

Cloudflare figurait parmi les primo-adoptants du cadre de sécurité Resource Public Key Infrastructure (RPKI) aux fins de la validation de l'origine de l'itinéraire (Route Origin Validation, ROV). Avec RPKI, les propriétaires de préfixes IP peuvent stocker et partager en toute sécurité des informations liées à la propriété, et d'autres opérateurs peuvent valider les annonces BGP en comparant les itinéraires BGP reçus avec les informations stockées sous la forme de ROA (Route Origin Authorization, autorisation d'origine d'itinéraire). Lorsque la validation d'origine d'itinéraire est correctement mise en œuvre par les réseaux et que les préfixes sont signés au moyen de la ROA, l'impact d'un détournement de BGP est considérablement limité. En dépit d'une adoption croissante de RPKI, ces dernières années, et malgré le fait que 1.1.1.0/24 soit une ressource signée, pendant l'incident, l'adresse 1.1.1.1/32 a été créée par l'opérateur ELETRONET S.A. (AS267613) et acceptée par plusieurs réseaux, dont au moins un fournisseur de niveau 1, qui a accepté 1.1.1.1/32 en tant qu'itinéraire de routage par trou noir. Cette situation a entraîné l'indisponibilité immédiate de l'adresse du résolveur DNS depuis plus de 300 réseaux situés dans 70 pays, bien que l'impact sur le pourcentage global d'utilisateurs ait été assez faible (moins de 1 % des utilisateurs au Royaume-Uni et en Allemagne, par exemple) ; dans certains pays, aucun utilisateur n'a remarqué d'impact.

Cloudflare s'est déjà exprimée au sujet des fuites de routage, et malheureusement, seules des mesures de protection « au mieux », telles que le filtrage des listes de préfixes IRR (Internet Routing Registry) par fournisseur d'accès, ont aujourd'hui été déployées à grande échelle. Pendant la même période que le détournement de 1.1.1.1/32, 1.1.1.0/24 a accidentellement été divulguée en amont par l'opérateur Nova Rede de Telecomunicações Ltda (AS262504). La fuite a ensuite été largement propagée par l'opérateur Peer-1 Global Internet Exchange (AS1031), contribuant également aux répercussions ressenties par les clients pendant l'incident.

Nous nous excusons pour l'impact ressenti par les utilisateurs du résolveur 1.1.1.1, et nous prenons très au sérieux le fonctionnement de ce service. Bien que la cause fondamentale de l'impact soit externe à Cloudflare, nous continuerons à améliorer les méthodes de détection mises en place afin d'accélérer les temps de réponse. Nous nous appuierons également sur notre position au sein de la communauté Internet afin d'encourager davantage l'adoption de mécanismes de prévention des détournements et des fuites basés sur RPKI, tels que Route Origin Validation (ROV, validation de l'origine de l'itinéraire) et les objets Autonomous Systems Provider Authorization (ASPA) pour le protocole BGP.

Cloudflare a inauguré le service de résolveur DNS public 1.1.1.1 en 2018. Depuis cette annonce, 1.1.1.1 est devenue l'une des adresses de résolveur IP gratuit accessible à tous les plus populaires. La popularité et le caractère facilement mémorisable de cette adresse IP s'accompagnent de quelques difficultés opérationnelles. Les difficultés proviennent en effet de l'utilisation historique de 1.1.1.1 par les réseaux dans des laboratoires ou en tant qu'adresse IP de test, entraînant un certain volume de trafic résiduel inattendu ou un comportement de routage par trou noir. Par conséquent, Cloudflare est familière avec les effets du trafic lié aux erreurs de routage de BGP, dont deux exemples sont décrits ci-dessous.

Une partie de la difficulté provient des détournements potentiels du routage de 1.1.1.1. Par exemple, si l'opérateur fictif Foobar Networks attribue l'adresse 1.1.1.1/32 à l'un de ses routeurs et partage ce préfixe sur son réseau interne, ses clients auront des difficultés à établir le routage vers le service DNS 1.1.1.1. Et si l'opérateur annonce le préfixe 1.1.1.1/32 en dehors de son réseau immédiat, l'impact peut être encore plus important. La raison pour laquelle 1.1.1.1/32 a été sélectionné au lieu du préfixe 1.1.1.0/24 annoncé par Cloudflare est due à l'algorithme Longest Prefix Matching (LPM). Tandis que de nombreux préfixes d'une table de routage pourraient correspondre à l'adresse 1.1.1.1 (par exemple, 1.1.1.0/24, 1.1.1.0/29 et 1.1.1.1/32), 1.1.1.1/32 est considéré comme la « correspondance la plus longue » par l'algorithme LPM parce qu'il comporte le nombre le plus élevé de bits identiques et le masque de sous-réseau le plus long, tout en correspondant à l'adresse 1.1.1.1. En termes simples, nous appellerions 1.1.1.1/32 l'itinéraire « le plus spécifique » disponible pour 1.1.1.1.

Au lieu d'être acheminé vers Cloudflare via Anycast et de parvenir à l'un de nos serveurs quelque part dans le monde, le trafic destiné à 1.1.1.1 sera transmis à un équipement de Foobar Networks servant de terminaison à 1.1.1.1, et une réponse légitime ne pourra pas être servie aux clients. Cela serait considéré comme un détournement des requêtes à destination de 1.1.1.1, qu'il soit effectué délibérément ou accidentellement par des opérateurs de réseau au sein de Foobar Networks.

Les fuites de routage de BGP provoquent également des impacts auxquels nous sommes parfois confrontés avec 1.1.1.1. Une fuite de routage se produit lorsqu'un réseau devient un fournisseur en amont, en termes d'annonces BGP, d'un réseau dont il ne devrait pas être un fournisseur en amont.

Voici un exemple de fuite de routage, dans lequel un client acheminant les itinéraires appris d'un fournisseur vers un autre fournisseur entraîne une fuite de type 1 (définie dans la RFC7908).

Si un nombre suffisant de réseaux au sein de la Default-Free Zone (DFZ) accepte une fuite de routage, celle-ci peut être largement utilisée pour acheminer le trafic suivant l'itinéraire incorrect. Cela entraîne souvent une surcharge du réseau à l'origine de la fuite des préfixes, car le réseau n'est pas en mesure de faire face à la quantité de trafic mondial qu'il attire actuellement. Nous avons écrit un article au sujet d'une fuite de routage de grande ampleur ayant entraîné l'arrêt d'une grande partie de l'Internet, lorsqu'un fournisseur en Pennsylvanie a attiré du trafic transitant vers des destinations mondiales pour lesquelles il n'avait généralement jamais acheminé de trafic. Même si Cloudflare dispose d'interconnexions avec plus de 13 000 réseaux dans le monde, l'attribut BGP local-preference affecté à un itinéraire concerné par une fuite peut l'emporter sur l'itinéraire reçu directement de Cloudflare par un réseau. Bien que cela puisse paraître contre-productif, cela peut malheureusement arriver.

Pour expliquer pourquoi cela se produit, il est utile de considérer BGP comme un moteur de politiques opérationnelles au même titre que le protocole de routage pour Internet. Les clients d'un fournisseur de services d'acheminement paient celui-ci pour transporter leurs données ; le fournisseur leur assigne donc logiquement un attribut BGP local-preference plus élevé qu'aux connexions avec des pairs privés ou des pairs utilisant Internet Exchange (IX), et la connexion payante est donc la plus utilisée. Vous pouvez considérer local-preference comme un moyen d'influencer la priorité des connexions sortantes vers lesquelles est envoyé le trafic. Différents réseaux peuvent également choisir de préférer les interconnexions de réseaux privés (Private Network Interconnect, PNI) aux itinéraires reçus depuis des points d'échange Internet (Internet Exchange, IX). Cette préférence s'explique en partie par la fiabilité ; en effet, une connexion privée peut être considérée comme une connexion point à point entre deux réseaux, exempte des problématiques liées à une infrastructure gérée par un tiers. Une autre raison pourrait être la rentabilité : si vous avez pris la peine d'assigner un port de routeur et d'acheter une interconnexion entre votre réseau et celui d'un pair, vous souhaitez sûrement pouvoir l'utiliser de manière à générer le meilleur retour sur investissement.

Il convient de noter que les détournements et les fuites de routage de BGP peuvent affecter n'importe quelle adresse IP et préfixe sur Internet, et pas uniquement 1.1.1.1. Comme nous l'avons mentionné précédemment, toutefois, 1.1.1.1 est une adresse tellement mémorisable et historiquement utilisée à des fins contestables qu'elle a tendance à être plus sujette aux fuites et détournements accidentels que d'autres ressources IP.

Au cours de l'incident affectant Cloudflare 1.1.1.1 survenu le 27 juin 2024, nous nous sommes retrouvés à lutter contre l'impact provoqué à la fois par un détournement de BGP et par une fuite de routage.

Toutes les informations d'horodatage sont au format UTC.

27-06-2024 18:51:00 AS267613 (Eletronet) commence à annoncer 1.1.1.1/32 aux pairs, fournisseurs et clients. 1.1.1.1/32 est annoncée avec le système autonome (AS) d'origine AS267613

27-06-2024 18:52:00 AS262504 (Nova) divulgue 1.1.1.0/24, également reçue du système autonome AS267613, en amont d'AS1031 (Peer-1 Global Internet Exchange) avec le chemin de système autonome « 1031 262504 267613 13335 »

2024-06-2024 18:52:00 AS1031 (en amont de Nova) propage 1.1.1.0/24 à différents pairs et serveurs de routage Internet Exchange, amplifiant les effets de la fuite

2024-06-2024-06-2024-18 18:52:00 Un fournisseur de niveau 1 reçoit l'annonce de 1.1.1.1/32 d'AS267613 en tant qu'itinéraire RTBH (Remote Triggered Blackhole, routage par trou noir déclenché à distance), provoquant le routage par trou noir du trafic pour tous les clients du fournisseur de niveau 1

27-06-2024 20:03:00 Cloudflare signale un incident interne concernant des problèmes d'accessibilité de 1.1.1.1 dans différents pays

27-06-2024 20:08:00 Cloudflare désactive un emplacement de peering partenaire avec l'identifiant de système autonome AS267613 qui reçoit du trafic à destination de 1.1.1.0/24

2024-06-20 20:08:00 L'équipe de Cloudflare interagit avec le partenaire de peering AS267613 au sujet de l'incident

2024-06-27 20:10:00 AS262504 divulgue 1.1.1.0/24 avec un nouvel itinéraire de système autonome, « 262504 53072 7738 13335 », qui est également rediffusé par AS1031. Le trafic est bien acheminé vers Cloudflare lorsqu'il suit cet itinéraire, mais avec une latence élevée pour les clients concernés

27-06-2024 20:17:00 Cloudflare communique avec AS262504 concernant la fuite de routage de 1.1.1.0/24 vers les fournisseurs en amont du système autonome

27-06-2024 21:56:00 Les ingénieurs de Cloudflare désactivent un deuxième point de peering, AS267613, qui reçoit du trafic destiné à 1.1.1.0/24 provenant de plusieurs sources extérieures au Brésil

27-06-2024 22:16:00 AS262504 divulgue à nouveau 1.1.1.0/24, attirant une partie du trafic vers un peering Cloudflare avec AS267613, situé à São Paulo. Certaines requêtes adressées à 1.1.1.1 sont renvoyées avec une latence plus élevée, mais le détournement de 1.1.1.1/32 et le routage par trou noir du trafic semblent résolus

28-06-2024 02:28:00 AS262504 résout entièrement la fuite de routage de 1.1.1.0/24

Les répercussions pour les clients se sont manifestées de l'une des deux manières suivantes : incapacité d'atteindre 1.1.1.1 ou capacité d'atteindre 1.1.1.1, toutefois avec une latence par requête élevée

Puisque le système autonome AS267613 détournait l'adresse 1.1.1.1/32 quelque part sur son réseau, de nombreuses requêtes ont échoué au niveau d'un équipement du système autonome. L'incident s'est produit par périodes intermittentes (ou « battements ») durant lesquelles le système autonome est parvenu à acheminer des requêtes adressées à 1.1.1.1 vers des datacenters de Cloudflare, toutefois, avec une latence élevée.

Si l'on examine deux pays sources au cours de l'incident, l'Allemagne et les États-Unis, le trafic affecté à destination de 1.1.1.1 se présentait ainsi :

Pays source des utilisateurs :

Gardez à l'esprit que, dans l'ensemble, ces valeurs peuvent représenter un volume relativement faible du nombre total de requêtes par pays source ; en temps normal, toutefois, aucune requête adressée à 1.1.1.1 n'est acheminée depuis les États-Unis ou l'Allemagne vers le Brésil.

Ville hébergeant un datacenter Cloudflare :

L'examen des graphiques montre que les requêtes adressées à 1.1.1.1 parvenaient à des datacenters brésiliens. Les écarts entre les pics correspondent au moment où les requêtes adressées à 1.1.1.1 subissaient un routage par trou noir en amont ou au niveau d'AS267613, et les pics eux-mêmes correspondent aux moments où le trafic était acheminé vers Cloudflare avec une latence élevée invoquée au niveau de la requête et de la réponse. Les brefs pics de trafic acheminés avec succès vers l'emplacement de peering Cloudflare avec AS267613 pourraient s'expliquer par les battements d'itinéraire de 1.1.1.1/32 sur le réseau du système autonome ; celui-ci autorisait parfois l'acheminement du trafic vers Cloudflare, au lieu de l'abandonner quelque part sur l'itinéraire intermédiaire.

Normalement, une requête transmise par les utilisateurs à 1.1.1.1 est acheminée vers le datacenter le plus proche via BGP Anycast. Pendant l'incident, AS267613 (Eletronet) a annoncé 1.1.1.1/32 à ses pairs et fournisseurs en amont, et AS262504 a divulgué 1.1.1.0/24 en amont, modifiant radicalement l'itinéraire BGP Anycast normal pour plusieurs réseaux d'utilisateurs finaux.

Avec les outils de collecte d'itinéraires publics et l'outil monocle, nous pouvons rechercher les mises à jour indésirables de BGP.

Nous voyons ci-dessus que les réseaux AS398465 et AS13760 ont signalé aux outils de collecte route-views qu'ils ont reçu l'adresse 1.1.1.1/32 d'AS267613, à peu près au moment où l'impact devient perceptible. Normalement, le préfixe IPv4 le plus long accepté dans la Default-Free-Zone (DFZ) est /24, mais dans ce cas, nous avons observé plusieurs réseaux utilisant l'itinéraire de 1.1.1.1/32 depuis AS267613 pour l'acheminement, comme le révèle le routage vers un trou noir du trafic qui n'a jamais atteint un POP (Point of Presence) de Cloudflare. L'origination de 1.1.1.1/32 par AS267613 est un détournement d'itinéraire BGP : le préfixe était annoncé avec le réseau d'origine AS267613, même si le certificat Route Origin Authorization (ROA) était uniquement signé pour le réseau d'origine AS13335 (Cloudflare), avec une longueur de préfixe maximale de /24.

Nous avons même observé des mises à jour de BGP pour 1.1.1.1/32 lorsque nous examinions nos propres données BMP (BGP Monitoring protocole) chez Cloudflare. Depuis au moins quelques serveurs de routage différents, nous avons reçu notre propre annonce de 1.1.1.1/32 via BGP. Heureusement, Cloudflare rejette ces itinéraires à l'importation comme étant « RPKI Invalid » et « DFZ Invalid », en raison d'un système autonome d'origine et d'une longueur de préfixe non valides. La présentation des données BMP est antérieure à la politique, ce qui signifie que même si nous avons rejeté l'itinéraire, nous pouvons observer à quel moment nous recevons la mise à jour de BGP pendant une session de peering.

monocle search --start-ts 2024-06-27T18:51:00Z --end-ts 2024-06-27T18:55:00Z --prefix '1.1.1.1/32'

A|1719514377.130203|206.126.236.209|398465|1.1.1.1/32|398465 267613|IGP|206.126.236.209|0|0||false|||route-views.eqix
–
A|1719514377.681932|206.82.104.185|398465|1.1.1.1/32|398465 267613|IGP|206.82.104.185|0|0|13538:1|false|||route-views.ny
–
A|1719514388.996829|198.32.132.129|13760|1.1.1.1/32|13760 267613|IGP|198.32.132.129|0|0||false|||route-views.telxatl

Ainsi, non seulement plusieurs réseaux acceptent des préfixes qui ne devraient pas exister dans la table de routage mondiale, mais ils acceptent également un itinéraire RKPI (Resource Public Key Infrastructure) non valide. Pour aggraver la situation, un fournisseur d'acheminement de niveau 1 a accepté l'annonce de 1.1.1.1/32 en tant qu'itinéraire RTBH (Remote-Triggered Blackhole, routage par trou noir déclenché à distance) provenant d'AS267613, supprimant à la périphérie de son réseau la totalité du trafic normalement acheminé vers Cloudflare. Ce seul facteur a eu des répercussions considérables, car tout réseau utilisant ce fournisseur de niveau 1 pour le routage vers 1.1.1.1 n'était plus en mesure d'atteindre l'adresse IP pendant l'incident.Pour les personnes qui ne sont pas familières avec le concept de Remote-Triggered Blackholing (routage par trou noir déclenché à distance), il s'agit d'une méthode permettant de signaler à un fournisseur un ensemble de destinations pour lesquelles vous souhaitez que le trafic soit supprimé sur son réseau. Il s'agit d'une méthode rudimentaire pour lutter contre les attaques DDoS. Lorsque vous subissez une attaque sur une adresse IP ou un préfixe spécifique, vous pouvez demander à votre fournisseur en amont d'absorber tout le trafic destiné à cette adresse IP ou ce préfixe de destination en le supprimant avant qu'il n'atteigne votre port réseau. Pendant cet incident, le problème était qu'AS267613 n'était pas autorisé à effectuer le routage par trou noir de 1.1.1.1/32. Seule Cloudflare devrait avoir le droit exclusif d'utiliser RTBH pour supprimer le trafic destiné à AS13335, ce que nous ne ferions toutefois jamais.

Intéressons-nous maintenant aux mises à jour BGP pour 1.1.1.0/24. Comme nous pouvons le voir, plusieurs réseaux ont reçu le préfixe d'AS262504 et l'ont accepté.

Ici, nous prêtons à nouveau attention au chemin de l'AS. Cette fois, AS13335 est le système autonome d'origine à la toute fin des annonces. Cette annonce BGP est valide selon RKPI, car le serveur d'origine est effectivement AS13335 ; cependant, il s’agit d’une fuite de routage de 1.1.1.0/24, car l'itinéraire lui-même n’est pas valide.

Prenons l'exemple d'un itinéraire « 199524 1031 262504 267613 13335 » ; AS267613 est fonctionnellement un pair d'AS13335, et ne devrait pas partager l'annonce de 1.1.1.0/24 avec ses pairs peering ou fournisseurs en amont, mais uniquement avec ses clients (AS Cone). AS262504 est client de AS267613 et du numéro de système autonome (ASN) adjacent sur l'itinéraire, et cette annonce particulière est donc acceptable jusqu'à présent. Le problème avec 1.1.1.0/24 survient au niveau d'AS262504, lorsque ce système autonome annonce le préfixe à AS1031, son fournisseur en amont. Par ailleurs, AS1031 a rediffusé l'annonce à ses pairs.

~> monocle search --start-ts 2024-06-27T20:10:00Z --end-ts 2024-06-27T20:13:00Z --prefix '1.1.1.0/24' --as-path ".* 267613 13335" --include-sub

.. some advertisements removed for brevity ..

A|1719519011.378028|187.16.217.158|1031|1.1.1.0/24|1031 262504 267613 13335|IGP|187.16.217.158|0|0|1031:1031 1031:4209 1031:6045 1031:7019 1031:8010|false|13335|162.158.177.1|route-views2.saopaulo
–
A|1719519011.629398|45.184.147.17|1031|1.1.1.0/24|1031 262504 267613 13335|IGP|45.184.147.17|0|0|1031:1031 1031:4209 1031:4259 1031:6045 1031:7019 1031:8010|false|13335|162.158.177.1|route-views.fortaleza
–
A|1719519036.943174|80.249.210.99|50763|1.1.1.0/24|50763 1031 262504 267613 13335|IGP|80.249.210.99|0|0|1031:1031 50763:400|false|13335|162.158.177.1|route-views.amsix
–
A|1719519037|80.249.210.99|50763|1.1.1.0/24|50763 1031 262504 267613 13335|IGP|80.249.210.99|0|0|1031:1031 50763:400|false|13335|162.158.177.1|rrc03
–
A|1719519087.4546|45.184.146.59|199524|1.1.1.0/24|199524 1031 262504 267613 13335|IGP|45.184.147.17|0|0||false|13335|162.158.177.1|route-views.fortaleza
A|1719519087.464375|45.184.147.74|264409|1.1.1.0/24|264409 1031 262504 267613 13335|IGP|45.184.147.74|0|0|65100:7010|false|13335|162.158.177.1|route-views.fortaleza
–
A|1719519096.059558|190.15.124.18|61568|1.1.1.0/24|61568 262504 267613 13335|IGP|190.15.124.18|0|0|1031:1031 1031:4209 1031:6045 1031:7019 1031:8010|false|13335|162.158.177.1|route-views3
–
A|1719519128.843415|190.15.124.18|61568|1.1.1.0/24|61568 262504 267613 13335|IGP|190.15.124.18|0|0|1031:1031 1031:4209 1031:6045 1031:7019 1031:8010|false|13335|162.158.177.1|route-views3

Cela signifie qu'AS262504 est le réseau à l'origine de la fuite. AS1031 a accepté la fuite de son client AS262504 et a provoqué un impact considérable en diffusant l'itinéraire sur plusieurs emplacements de peering, partout dans le monde. AS1031 (Peering-1 Global Internet Exchange) s'annonce comme un échange de peering mondial. Cloudflare n'est pas client d'AS1031 ; par conséquent, 1.1.1.0/24 n'aurait jamais dû être rediffusé à des pairs, des serveurs de routage ou des serveurs en amont d'AS1031. Il apparaît qu'AS1031 n'effectue pas de filtrage approfondi pour les sessions BGP de clients, et qu'au lieu de cela, il établit uniquement des correspondances sur la base de l'adjacence (dans ce cas, AS262504) et rediffuse toutes les informations satisfaisant à ces critères. Malheureusement, cette pratique d'AS1031 est irresponsable et a un impact direct sur 1.1.1.1 et potentiellement sur d'autres services victimes de la propagation d'itinéraires non protégés. Alors que le réseau à l'origine de la fuite était AS262504, AS1031 et les autres réseaux ont fortement amplifié l'impact lorsqu'ils ont accepté le détournement ou la fuite et ont continué à diffuser les annonces.

Pendant la majeure partie de la durée de l'incident, la fuite propagée par AS262504 a fini par entraîner la transmission de requêtes à AS267613, qui supprimait le trafic transmis à 1.1.1.1/32 quelque part sur son réseau. À cette fin, AS262504 n'a fait qu'amplifier l'impact en termes d'indisponibilité de 1.1.1.1 en divulguant des itinéraires en amont.

Pour limiter l'impact de la fuite de routage, Cloudflare a désactivé le peering sur plusieurs emplacements avec AS267613. Le problème n'a pas complètement disparu, car AS262504 continuait à divulguer un itinéraire obsolète renvoyant vers les datacenters de São Paulo. Les requêtes transmises aux datacenters de São Paulo étaient servies, cependant, avec un temps d'aller-retour élevé pour les utilisateurs. Cloudflare a communiqué avec tous les réseaux mentionnés dans cette publication au regard de la fuite et des futurs mécanismes de prévention, ainsi qu'avec au moins un fournisseur d'acheminement de niveau 1 qui a accepté l'annonce de 1.1.1.1/32 d'AS267613 comme un routage par trou noir non autorisé par Cloudflare, avec des répercussions considérables.

Validation du serveur d'origine par RPKIRPKI a récemment atteint une étape importante, avec le déploiement de 50 % de préfixes signés par Route Origin Authorization (ROA). Si RKPI permet certainement de limiter la propagation d'un préfixe BGP détourné à l'ensemble d'Internet, il est indispensable que tous les réseaux fassent leur part, notamment les grands réseaux comptant un grand nombre de systèmes autonomes (AS) en aval. Pendant le détournement de 1.1.1.1/32, plusieurs réseaux ont accepté et utilisé l'itinéraire annoncé par AS267613 pour l'acheminement du trafic.

RPKI et Remote-Triggered Blackholing (RTBH)Une grande partie des répercussions de l'incident est liée à l'acceptation par un fournisseur de niveau 1 de 1.1.1.1/32 en tant que routage par trou noir de la part d'un tiers autre que Cloudflare. C'est en soi un détournement de 1.1.1.1 – très dangereux, qui plus est. Le Remote-Triggered Blackholing (RTBH, routage par trou noir déclenché à distance) est un outil utile employé par de nombreux réseaux lorsqu'ils ont impérativement besoin d'atténuer des attaques DDoS de grande ampleur. Le problème est que le filtrage BGP utilisé pour le RTBH est intrinsèquement laxiste, et repose souvent uniquement sur des objets AS-SET présents dans les registres de routage Internet. Il serait impossible de se reposer sur Route Origin Authorization (ROA) pour le filtrage par RTBH, car pour un réseau de la taille de celui de Cloudflare, cela nécessiterait la création de milliers de ROA potentiels. Par ailleurs, la création d'entrées /32 spécifiques entraîne le risque qu'une adresse individuelle telle que 1.1.1.1/32 soit annoncée par un individu se faisant passer pour AS13335, devenant ainsi le meilleur itinéraire d'accès à 1.1.1.1 sur Internet, avec de graves répercussions.

Le filtrage AS-SET n'est pas représentatif de l'autorité d'imposer un routage par trou noir sur un itinéraire tel que 1.1.1.1/32. Seule Cloudflare doit être en mesure de bloquer une destination dont elle détient les droits d'exploitation. Une manière potentielle de remédier au filtrage laxiste des fournisseurs sur les sessions RTBH consisterait, une fois encore, à utiliser une clé RPKI. En s'appuyant sur un exemple issu de l'IETF, la proposition expirée projet-spaghetti-sidrops-rpki-doa-00 spécifiait un objet Discard Origin Authorization (DOA, autorisation d'ignorer le serveur d'origine) qui serait utilisé pour autoriser uniquement des serveurs d'origine spécifiques à autoriser une action de routage par trou noir pour un préfixe donné. Si un tel objet était signé et les requêtes RTBH étaient validées pour cet objet, la tentative non autorisée d'AS267613 de routage par trou noir de 1.1.1.1/32 aurait été non valide, au lieu d'être acceptée par le fournisseur de niveau 1.

Bonnes pratiques concernant BGPLa simple conformité aux bonnes pratiques concernant BGP décrites par MANRS et le rejet des préfixes IPv4 d'une longueur supérieure à /24 dans la Default-Free Zone (DFZ) aurait permis de réduire l'impact sur 1.1.1.1. Le rejet des longueurs de préfixe non valides sur l'Internet au sens large devrait faire partie d'une politique BGP standard pour tous les réseaux.

Bien que les fuites de routage ne soient pas inévitables pour Cloudflare à l'heure actuelle, car Internet repose intrinsèquement sur la confiance aux fins de l'établissement d'interconnexions), il existe des mesures que nous allons prendre pour en limiter l'impact.

Nous avons élargi les sources de données utilisées par notre système de détection des fuites de routage afin de couvrir davantage de réseaux, et nous sommes actuellement en train d'incorporer des données en temps réel au système de détection afin de permettre une réponse plus rapide en cas d'événements similaires à l'avenir.

Nous continuerons à plaider en faveur de l'adoption de RKPI dans la prévention des fuites de routage basée sur AS Path. Les objets Autonomous System Provider Authorization (ASPA, autorisation de fournisseur de système autonome) sont similaires aux ROA, à ceci près qu'au lieu de signer les préfixes avec un système autonome d'origine autorisé, le système autonome lui-même est signé avec une liste de réseaux de fournisseurs qui sont autorisés à propager leurs itinéraires. Par conséquent, dans le cas de Cloudflare, seuls les fournisseurs d'acheminement en amont valides seraient signés comme autorisés à annoncer en amont les préfixes d'AS13335 tels que 1.1.1.0/24 .

Dans l'exemple de fuite de routage où AS262504 (client d'AS267613) a partagé 1.1.1.0/24 en amont, un objet ASPA BGP identifierait cette fuite si AS267613 avait signé ses fournisseurs autorisés et AS1031 avait validé des itinéraires en fonction de cette liste. À l'instar de la validation selon RPKI du système autonome d'origine, cette approche demandera toutefois un effort à long terme et sera tributaire des réseaux, en particulier ceux des grands fournisseurs, et permettra de rejeter les chemins de systèmes autonomes non valides comme le font les objets ASPA.

Il existe des approches alternatives à ASPA qui ont actuellement atteint différents stades et peuvent s'avérer intéressantes. Il n'est toutefois pas garanti que les solutions suivantes parviennent au stade d'un déploiement à grande échelle sur Internet.

RFC9234, par exemple, propose un concept de rôles de pairs dans le cadre des capacités et attributs de BGP, et en fonction de la configuration des routeurs le long d'un itinéraire utilisé aux fins des mises à jour, un attribut « Only-To-Customer » (OTC) peut être ajouté aux préfixes afin d'empêcher la diffusion en amont d’un préfixe tel que 1.1.1.0/24, le long d’un itinéraire divulgué. L'inconvénient est que la configuration de BGP doit être effectuée pour attribuer les différents rôles à chaque session de peering, et que l'adoption par les fournisseurs doit encore être finalisée pour que l'utilisation soit réellement possible en production, avec des résultats positifs.

À l'instar de toutes les approches visant à résoudre les fuites de routage, la coopération entre opérateurs de réseaux sur Internet est indispensable au succès.

Le résolveur DNS 1.1.1.1 de Cloudflare a été victime d'un événement reposant simultanément sur un détournement de BGP et une fuite de routage BGP. Bien que les actions des réseaux externes ne relèvent pas du contrôle direct de Cloudflare, nous avons l'intention de prendre toutes les mesures, à la fois au sein de la communauté Internet et en interne chez Cloudflare, afin d'en détecter plus rapidement les conséquences et de les atténuer pour nos utilisateurs.

À long terme, Cloudflare continue à soutenir l'adoption d'une procédure de validation des serveurs d'origine basée sur RPKI, ainsi que de la validation de l'itinéraire des systèmes autonomes. La première mesure nécessite le déploiement sur un grand nombre de réseaux parmi les plus vastes du monde, tandis que la seconde est encore en phase de projet au sein de l'IETF (Internet Engineering Task Force). En attendant, pour vérifier si votre FAI met en œuvre la validation des serveurs d'origine basée sur RPKI, vous pouvez consulter les sites isbgpsafeyet.com et Test Your ISP.