Le géant de l’Internet Cloudflare rapporte que son service de résolveur DNS, 1.1.1.1, était récemment inaccessible ou dégradé pour certains de ses clients en raison d’une combinaison de détournement de Border Gateway Protocol (BGP) et d’une fuite de route.

L’incident s’est produit la semaine dernière et a affecté 300 réseaux dans 70 pays. Malgré ces chiffres, la société affirme que l’impact a été « assez faible » et que dans certains pays, les utilisateurs ne l’ont même pas remarqué.

Détails de l’incident
Cloudflare indique qu’à 18h51 UTC le 27 juin, Eletronet S.A. (AS267613) a commencé à annoncer l’adresse IP 1.1.1.1 / 32 à ses pairs et aux fournisseurs en amont.

Cette annonce incorrecte a été acceptée par plusieurs réseaux, y compris un fournisseur de niveau 1, qui l’a traitée comme une route de trou noir déclenché à distance (RTBH).

Le détournement s’est produit parce que le routage BGP favorise la route la plus spécifique. L’annonce de la version 1.1.1.1/32 par AS267613 était plus spécifique que la version 1.1.1.0 / 24 de Cloudflare, ce qui a conduit les réseaux à acheminer de manière incorrecte le trafic vers AS267613.

Par conséquent, le trafic destiné au résolveur DNS 1.1.1.1 de Cloudflare a été bloqué/rejeté, et par conséquent, le service est devenu indisponible pour certains utilisateurs.

Une minute plus tard, à 18h52 UTC, Nuova Rade de Telecomunicaçoes Lda (AS262504) a divulgué par erreur 1.1.1.0/24 en amont vers AS1031, ce qui l’a propagé davantage, affectant le routage global.

Cette fuite a modifié les chemins de routage BGP normaux, entraînant une erreur d’acheminement du trafic destiné à 1.1.1.1, aggravant le problème de détournement et entraînant des problèmes supplémentaires d’accessibilité et de latence.

Cloudflare a identifié les problèmes vers 20h00 UTC et a résolu le détournement environ deux heures plus tard. La fuite d’itinéraire a été résolue à 02h28 UTC.

Efforts d’assainissement
La première ligne de réponse de Cloudflare a été de s’engager avec les réseaux impliqués dans l’incident tout en désactivant les sessions d’appairage avec tous les réseaux problématiques pour atténuer l’impact et empêcher la propagation de routes incorrectes.

La société explique que les annonces incorrectes n’ont pas affecté le routage interne du réseau en raison de l’adoption de l’Infrastructure à clé publique de ressources (RPKI), ce qui a conduit au rejet automatique des routes invalides.

Les solutions à long terme présentées par Cloudflare dans son post-mortem incluent:

  • Améliorez les systèmes de détection des fuites d’itinéraire en incorporant davantage de sources de données et en intégrant des points de données en temps réel.
  • Promouvoir l’adoption de l’Infrastructure à Clé Publique des Ressources (ICP) pour la Validation de l’origine des routes (ROV).
  • Promouvoir l’adoption des principes des Normes mutuellement convenues pour la sécurité du routage (MANRS), qui incluent le rejet des longueurs de préfixe invalides et la mise en œuvre de mécanismes de filtrage robustes.
  • Encouragez les réseaux à rejeter les préfixes IPv4 supérieurs à /24 dans la Zone sans défaut (DFZ).
  • Préconisez le déploiement d’objets ASP (actuellement rédigés par l’IETF), qui sont utilisés pour valider le chemin AS dans les annonces BGP.
  • Explorez le potentiel de la mise en œuvre de la RFC9234 et de l’Autorisation d’origine de rejet (DOA).

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *