Résumé

  • L’événement retenu est borné au 25 mai 2023 et à AS37468, avec des effets décrits par MANRS et Internet Society Pulse sur des chemins depuis l’Australie vers des services aux États-Unis [1][2].
  • BGP annonce de la joignabilité, mais il ne certifie pas automatiquement que chaque voisin était autorisé à exporter le chemin reçu.
  • La validation d’origine RPKI aide à vérifier qu’un AS peut originer un préfixe. Elle ne valide pas toute la séquence de systèmes autonomes et ne remplace pas les politiques de relation [14][15].
  • Les enregistrements AFRINIC RDAP, bgp.tools et PeeringDB fixent le contexte d’identité réseau d’AS37468. Ils sont des registres de preuve, pas des verdicts de faute [4][5][6].
  • Une clôture sérieuse demanderait l’ensemble voulu des routes exportées, les journaux d’acceptation chez les voisins, les observations RouteViews ou RIPE RIS, l’état RPKI/IRR, les retraits et un contrôle de prévention testable.

Ce qui s’est passé

Les sources publiques décrivent une fuite BGP qui a rendu certains chemins nettement plus lents. Pour un lecteur non spécialiste, il faut imaginer une carte de livraison où plusieurs transporteurs se passent des itinéraires. Si un transporteur annonce une route en dehors du rôle prévu, d’autres peuvent la suivre parce qu’elle semble acceptable dans le protocole. Les paquets prennent alors un détour ou un chemin moins fiable. L’application de destination peut être saine, mais l’utilisateur voit un service lent ou instable.

Le dossier public ne prouve ni l’intention, ni la commande interne, ni la liste complète des flux affectés. Il permet cependant de poser la bonne question : quelle politique aurait dû empêcher l’export, l’acceptation ou la propagation du mauvais chemin ? C’est une question de contrôle opérationnel. Elle porte sur les filtres d’export, les limites de préfixes, les relations client-fournisseur-pair, les alertes et la conservation des preuves.

Pourquoi la validation du chemin est différente de l’origine

Un ROA RPKI peut dire qu’un préfixe est autorisé à être originaire d’un AS donné. Cette vérification est précieuse lorsqu’un mauvais AS apparaît comme origine. Une fuite de routes peut pourtant conserver une origine plausible tout en traversant une mauvaise relation. Le problème n’est alors pas seulement “qui a originaire le préfixe”, mais “qui avait le droit de transmettre ce chemin à ce voisin”.

RFC 7908 décrit les fuites de routes comme des erreurs de propagation. RFC 8212 rappelle l’importance de politiques explicites à l’import et à l’export. RFC 9234 ajoute une logique de rôles BGP et d’attribut Only-to-Customer pour signaler des relations. Ces textes ne prouvent pas ce qui était configuré chez Angola Cables le 25 mai 2023. Ils indiquent les contrôles qu’une enquête doit chercher.

Identité réseau et registres

AS37468 fournit l’ancrage technique. bgp.tools rend visible le contexte de routage. AFRINIC RDAP donne le registre de l’autnum. PeeringDB décrit une partie de la présence d’interconnexion déclarée [4][5][6]. Ces enregistrements ne sont pas des preuves de négligence. Ils sont utiles parce qu’ils empêchent l’article de devenir une narration abstraite. La responsabilité s’attache à une surface réseau identifiable : un ASN, des relations, des annonces et des observations.

La logique est proche du principe selon lequel un registre est un livre de comptes, pas un souverain. Le registre aide à relier une ressource numérique à un opérateur et à une continuité. La réalité décisive reste le code en fonctionnement : quelles routes sont sorties, quels voisins les ont acceptées, quels collecteurs les ont vues et quand elles ont disparu.

Le rôle des collecteurs

RouteViews et RIPE RIS sont essentiels parce qu’ils donnent une vision externe du plan de contrôle [7][8]. Ils ne voient pas tout. Un collecteur reçoit ce que ses pairs lui transmettent; il ne montre pas tous les choix de chaque routeur ni l’expérience de chaque utilisateur. Mais sans ces observatoires, le public dépendrait presque entièrement des déclarations privées des opérateurs.

Une analyse responsable compare donc les observations publiques aux journaux privés. Si un opérateur dit que le problème a été retiré à une heure donnée, les collecteurs doivent montrer une disparition compatible. Si un chemin reste visible ailleurs, la réparation est incomplète ou la visibilité est mal comprise. Cette confrontation entre registre public et état interne est le cœur de la responsabilité.

Questions de réparation

Une clôture défendable devrait répondre à plusieurs questions. Quel ensemble AS37468 voulait-il exporter ? Quelles routes ont franchi cette limite ? Quels voisins ont accepté, rejeté ou propagé les annonces ? Quels contrôles RPKI, IRR, maximum-prefix, rôles BGP ou filtres de relation existaient ? Quel changement prouve que la même classe d’erreur échouera à l’avenir ?

Ces questions ne supposent pas une faute intentionnelle. Elles demandent une preuve. C’est le bon niveau pour une fuite de routes : moins de rhétorique, plus de traces vérifiables.

Sources

  1. https://manrs.org/2023/05/bgp-route-leak-at-angola-cables-slows-connectivity-for-many-australians/
  2. https://pulse.internetsociety.org/en/news/2023/05/bgp-route-leak-at-angola-cables-slows-connectivity-for-many-australians/
  3. https://seclists.org/nanog/2023/May/368
  4. https://bgp.tools/as/37468
  5. https://rdap.afrinic.net/rdap/autnum/37468
  6. https://www.peeringdb.com/net?asn=37468
  7. https://www.routeviews.org/routeviews/
  8. https://ris.ripe.net/docs/
  9. https://www.rfc-editor.org/rfc/rfc4271
  10. https://www.rfc-editor.org/rfc/rfc7908
  11. https://www.rfc-editor.org/rfc/rfc7454
  12. https://www.rfc-editor.org/rfc/rfc8212
  13. https://www.rfc-editor.org/rfc/rfc9234
  14. https://www.rfc-editor.org/rfc/rfc6811
  15. https://www.rfc-editor.org/rfc/rfc8893
  16. https://www.rfc-editor.org/rfc/rfc9319
  17. https://manrs.org/isps/guide/
  18. https://www.kentik.com/blog/a-brief-history-of-the-internets-biggest-bgp-incidents/