Résumé

  • Cloudflare a indiqué que, vers 10 h 30 UTC le 24 juin 2019, une petite entreprise était devenue un chemin préféré pour de nombreuses routes via Verizon AS701, avec des préfixes Cloudflare parmi les annonces affectées [1].
  • L'analyse ultérieure de Cloudflare a placé la couche de route optimizer et la propagation par un grand fournisseur de transit au centre du problème [2].
  • Noction a répondu publiquement parce que son produit d'optimisation faisait partie du débat; cette réponse sépare l'intention du produit de la gouvernance du déploiement [3].
  • ThousandEyes/Catchpoint a observé des effets de joignabilité pour des utilisateurs Cloudflare, ce qui borne le dommage dans des mesures externes plutôt que dans des journaux privés [4].
  • RFC 7908 et RFC 9234 montrent pourquoi le problème est une fuite de relation BGP et pourquoi les rôles explicites, comme Only-to-Customer, sont devenus une réparation pertinente [6][7].

Ce qui s'est passé

Cloudflare a décrit un incident où de nombreuses routes ont été envoyées via Verizon après qu'une petite société est devenue un chemin préféré. En termes BGP, le problème public n'était pas seulement qu'un réseau a annoncé quelque chose. Le problème était que d'autres réseaux ont traité ce chemin comme utilisable et l'ont porté plus loin que la relation ne devait le permettre. Une annonce surprenante ne devient un événement Internet visible que si les réseaux autour d'elle l'acceptent, la préfèrent et l'exportent.

DQE est donc dans le périmètre même si Verizon était le grand nom de l'incident. Un réseau client ou de bord peut être le premier endroit où une chaîne de responsabilité commence. Si un route optimizer influence l'export, il doit être gouverné comme une infrastructure de routage, pas comme un simple outil analytique. Si un fournisseur en amont accepte un ensemble anormal de routes client, il doit pouvoir expliquer quels filtres, limites de préfixes, objets IRR, contrôles RPKI et alarmes étaient en place.

Pourquoi cela compte

Une fuite de route peut garder une origine apparemment valide tout en violant la relation au milieu du chemin. C'est pourquoi la validation d'origine RPKI n'est pas une réponse complète. Le contrôle pertinent est la preuve de relation: qui est client, qui est fournisseur, quels préfixes sont autorisés, quelle exportation est permise et quelles routes doivent être rejetées.

Le public peut voir des collecteurs BGP, des chemins AS et des symptômes externes. Il ne peut pas voir directement les route maps, les tickets de changement, les journaux d'acceptation ou les décisions d'incident de chaque opérateur. Cette limite impose une conclusion prudente: les sources publiques ne prouvent pas l'intention de DQE, de Noction ou de Verizon. Elles prouvent qu'une chaîne d'acceptation était assez faible pour laisser une fuite client se propager par un grand fournisseur.

La couche technique

RFC 7908 définit une fuite de route comme une propagation qui viole la relation prévue entre réseaux. RFC 9234 essaie de rendre ces relations plus explicites grâce aux rôles BGP et à Only-to-Customer. Ces mécanismes ne réparent pas automatiquement tous les liens anciens, mais ils déplacent l'hypothèse privée vers une preuve visible par le protocole.

Une clôture crédible aurait dû lister les préfixes, les chemins AS, les horodatages, les sessions concernées, les filtres d'import et d'export, les limites de préfixes et la chronologie de retrait. Elle aurait aussi dû montrer comment les alertes distinguaient une annonce client ordinaire d'un transit involontaire.

Qui est affecté

Les réseaux utilisant les routes devenues préférées pouvaient voir de la latence, des pertes ou une indisponibilité partielle. Les sources ne donnent pas une comptabilité complète de chaque transaction touchée. La bonne mesure est donc la sélection réelle des chemins, la durée, les préfixes affectés et les lieux de collecte qui ont observé la propagation.

Ce qu'il faut surveiller

Surveiller les changements soudains dans les routes annoncées par un client, les optimisations qui dépassent une liste de préfixes autorisés, les fournisseurs qui acceptent des chemins anormaux et les communications d'incident qui ne publient pas la classe de fuite, la durée, le jeu de préfixes et les contrôles de non-récurrence.

Sources

  1. https://blog.cloudflare.com/how-verizon-and-a-bgp-optimizer-knocked-large-parts-of-the-internet-offline-today/
  2. https://blog.cloudflare.com/the-deep-dive-into-how-verizon-and-a-bgp-optimizer-knocked-large-parts-of-the-internet-offline-monday/
  3. https://www.noction.com/news/incident-response
  4. https://www.thousandeyes.com/blog/cloudflare-users-burned-by-internet-routing-pile-up
  5. https://www.kentik.com/blog/a-brief-history-of-the-internets-biggest-bgp-incidents/
  6. https://www.rfc-editor.org/rfc/rfc7908
  7. https://www.rfc-editor.org/rfc/rfc9234