Cela fait bien trop longtemps que les fuites et les détournements BGP sont considérés comme inévitables sur Internet. Nous avons toujours compté sur la protection des couches supérieures comme TLS et DNSSEC pour transmettre les paquets sans les altérer, mais il suffit souvent qu’un itinéraire soit détourné pour que l’adresse IP soit injoignable. Cela se traduit par une panne d’Internet.
Internet est trop indispensable pour que ce problème connu subsiste. Il est temps que les réseaux empêchent que les fuites et les détournements aient un quelconque impact. Le temps est venu de sécuriser le protocole BGP. Nous n’avons plus d’excuses.
Border Gateway Protocol (BGP), un protocole d’échange d’itinéraires d’acheminement, existe depuis les années 1980 et a évolué depuis. Au fil des ans, il a été doté de dispositifs de sécurité. Le plus important d’entre eux est l’infrastructure à clé publique de ressources (ICPR), qui constitue un mécanisme de sécurité pour le routage. Cela a fait l’objet de plusieurs articles sur le blog ayant fait suite à notre déploiement en 2018.
De nos jours, les entreprises estiment que l’ICPR est suffisamment aboutie pour que son utilisation soit généralisée, avec un écosystème de logiciels et d’outils suffisant, y compris des outils que nous avons écrits et publiés en open source. Nous avons entièrement déployé un système de validation de l’origine pour toutes nos sessions BGP avec nos homologues et avons signé nos préfixes.
Toutefois, Internet ne sera sécurisé que si les principaux fournisseurs de réseaux mettent en place l’ICPR. Que ce soit par inadvertance ou délibérément, ces réseaux peuvent propager une fuite ou un piratage à grande échelle. Ils doivent donc participer à l’éradication des problèmes liés au protocole BGP.
Nombreux sont ceux qui, comme AT&T et Telia, ont été les premiers à se doter de l’ICPR au niveau mondial en 2019. Cogent et NTT les ont suivis en 2020. Des centaines de réseaux de toutes tailles ont accompli un excellent travail ces dernières années, mais il reste encore beaucoup à faire.
Si l’on observe les entonnoirs de clients des réseaux qui ont adopté l’ICPR, on constate qu’environ 50 % d’Internet est mieux protégé contre les fuites au niveau des itinéraires. C’est très bien, mais loin d’être suffisant.
Aujourd’hui, nous vous présentons isBGPSafeYet.com, un site web permettant de suivre les déploiements et le filtrage des itinéraires incorrects par les grands réseaux.
Nous espérons que cela aidera la communauté et nous allons mettre à disposition les informations sur le site web. Le code source est disponible sur GitHub, et vos suggestions et contributions sont les bienvenues.
Nous espérons que cette initiative permettra de rendre l’ICPR plus accessible à tous et, à terme, de réduire l’impact des fuites sur le routage. Faites passer le message à vos fournisseurs d’accès à Internet (FAI), à vos fournisseurs d’hébergement et à vos réseaux de transit pour bâtir un Internet plus sûr.
En outre, afin de surveiller et de tester les déploiements, nous avons décidé de signaler deux préfixes malveillants que nous avons relevés dans nos quelque 200 datacenters et via les quelque 233 points d’échange Internet (IXP) auxquels nous sommes connectés :
103.21.244.0/24
2606:4700:7000::/48
Ces deux préfixes doivent être considérés comme non valides et ne doivent pas être acheminés par votre fournisseur si l’ICPR est appliquée au sein de son réseau. Cela permet de démontrer facilement jusqu’où peut aller un itinéraire malveillant et de vérifier si l’ICPR fonctionne dans des conditions réelles.
Une autorisation d’origine de routage pour 103.21.244.0/24 sur rpki.cloudflare.com
Dans le cadre du test que vous pouvez exécuter sur isBGPSafeYet.com, votre navigateur tentera de télécharger deux pages : la première, valid.rpki.cloudflare.com, contient un préfixe valide pour l’ICPR et la seconde, invalid.rpki.cloudflare.com, contient un préfixe non valide pour l’ICPR.
Le test donne deux résultats :
Si les deux pages ont été correctement chargées, cela signifie que votre FAI a accepté l’itinéraire non valide. Il n’a pas mis en place l’ICPR.
Si seul valid.rpki.cloudflare.com a été chargé, cela signifie que votre FAI a mis en place l’ICPR. Les fuites d’itinéraires vous poseront moins de problèmes.
Un simple test d’accessibilité ICPR
Nous allons effectuer des tests en utilisant ces préfixes pour vérifier la propagation. Traceroutes et les sondages nous ont permis par le passé de créer des représentations graphiques de déploiements.
Il suffit de calculer le nombre de réseaux qui envoient l’itinéraire accepté à leurs homologues et aux collecteurs :
État de l’itinéraire selon l’outil de collecte d’itinéraires en ligne RIPE Stat
En décembre 2019, nous avons publié une courbe de Hilbert de l’espace d’adressage IPv4. Chaque pixel représente un préfixe /20. Si un point est jaune, le préfixe ne répond qu’à la sonde d’un espace IP validé par l’ICPR. S’il est bleu, le préfixe répond aux sondes provenant à la fois de l’espace IP valide et de l’espace IP non valide.
En bref, les zones jaunes sont les espaces IP situés derrière les réseaux qui ignorent les préfixes invalidés par l’ICPR. Internet ne sera pas sûr tant que la zone bleue ne sera pas devenue jaune.
Courbe de Hilbert de l’espace d’adressage IP derrière les réseaux filtrant les préfixes invalidés par l’ICPR
Pour finir, nous aimerions remercier tous les réseaux qui ont déjà mis en place l’ICPR et tous les développeurs qui ont travaillé sur les bases de code des logiciels de validation. Les deux années qui viennent de s’écouler ont montré qu’Internet peut devenir plus sûr et nous attendons avec impatience le jour où nous pourrons considérer les fuites et les détournements d’itinéraires comme de l’histoire ancienne.