Résumé

  • À partir de 07 h 35 UTC, AS3223 a propagé vers AS3356 des routes apprises auprès de pairs; l'événement a duré environ vingt minutes [1].
  • Il s'agissait d'une fuite de chemin ou de relation, et non d'une simple usurpation d'origine. Une origine pouvait rester légitime alors que le chemin franchissait une mauvaise frontière.
  • La validation d'origine RPKI ne suffisait donc pas. Les rôles BGP, l'attribut Only-to-Customer, les politiques explicites et la surveillance de composition répondent à une autre question: qui peut transmettre quel chemin à quel voisin [13][14][15][16].
  • RouteViews et RIPE RIS fournissent des observations externes utiles mais partielles. Ils ne représentent ni tous les routeurs ni tous les utilisateurs [8][9].
  • Les sources publiques ne prouvent ni l'intention, ni la cause interne exacte, ni l'emplacement du goulot d'étranglement, ni la liste complète des réseaux affectés.

Ce qui s'est passé

Le Border Gateway Protocol, ou BGP, est le protocole par lequel des réseaux indépendants échangent des informations de joignabilité. Chaque réseau est représenté par un numéro de système autonome, ou ASN. Kentik rapporte que Voxility AS3223 a annoncé à Lumen AS3356 des routes qu'il avait apprises auprès de pairs. Une relation de pair à pair sert normalement à échanger le trafic des clients respectifs; un fournisseur de transit offre un accès plus large à Internet. Exporter une route de pair vers un fournisseur peut donc étendre cette route au-delà de sa portée prévue [1][11].

Kentik a compté 31 258 routes dans sa reconstruction. Parmi elles, 7 381 ont été vues par au moins cinquante pairs alimentant le système public de collecte RouteViews [1][8]. Ce chiffre démontre une propagation large dans l'échantillon, pas une visibilité universelle. Des exemples de chemins vers des préfixes associés à TPG Telecom et Yahoo ont montré le passage inattendu par AS3223 et AS3356. Ces organisations servent ici d'objets d'observation; les exemples ne leur attribuent aucune cause.

Les données de flux analysées par Kentik ont associé le changement de chemin à du trafic détourné et à une part plus importante de trafic perturbé ou abandonné. L'analyse ne localise pas le lien ou l'équipement saturé. Une clôture honnête doit conserver cette limite: la preuve publique établit un chemin anormal et un effet de trafic, mais pas chaque décision interne.

Pourquoi cela compte

Les fournisseurs de mitigation DDoS peuvent légitimement transporter des routes pour de nombreux clients, parfois pendant une urgence. Une simple liste statique peut devenir trop large ou trop lente. Cette difficulté n'autorise pas une acceptation illimitée. Elle impose un registre opérationnel précis: client, préfixes autorisés, origine, rôle de session, durée d'activation, chemin de retour et date d'expiration.

Le fournisseur de transit porte une obligation complémentaire. Il doit distinguer les routes autorisées par un client des routes apprises latéralement auprès de pairs ou d'autres fournisseurs. Si la seule règle est «ce client annonce beaucoup de routes», une erreur locale dispose d'un canal de propagation mondial. Les contrôles doivent comparer la configuration prévue à l'état réellement annoncé.

La couche technique

RPKI et les Route Origin Authorizations, ou ROA, permettent de vérifier si un ASN est autorisé à originer un préfixe [15]. Dans cet événement, l'origine pouvait rester correcte. Le défaut se trouvait au milieu du chemin. La validation d'origine ne répond donc pas à la question de relation.

RFC 8212 formalise une politique explicite par défaut à l'import et à l'export [13]. RFC 9234 décrit les rôles BGP et l'attribut Only-to-Customer, ou OTC, qui peut signaler qu'une route ne doit pas remonter dans certaines relations [14]. ASPA ajoute des éléments sur les relations de fournisseur [16]. Ces mécanismes décrivent des contrôles possibles; aucune source publique ne prouve leur déploiement exact entre AS3223 et AS3356 le jour de l'incident.

Les registres ASN et les pages bgp.tools lient les chemins à des identités numériques stables [3][4][5][6]. Ils sont des livres de comptes, pas des verdicts. La preuve décisive reste l'état exécuté: routes reçues, sélectionnées, annoncées et retirées, avec les versions de politique correspondantes.

Qui est affecté

Une fuite peut éloigner le trafic, créer de la latence, saturer un lien ou provoquer des pertes de paquets alors que le service de destination reste sain. Les opérateurs de destinations, leurs utilisateurs, le fournisseur de mitigation, le transit et les réseaux qui propagent le chemin ont chacun une vue différente. Aucun collecteur n'observe l'ensemble d'Internet. Une investigation doit donc aligner journaux de routeurs, collecteurs publics, flux, pertes, plaintes clients et retraits.

Ce qu'il faut surveiller

Il faut surveiller l'écart entre l'ensemble autorisé et l'ensemble annoncé, l'apparition d'origines ou de relations inhabituelles, la couverture des rôles BGP et OTC, la convergence de RouteViews et RIPE RIS, et le retour du trafic après retrait. Une réparation crédible reproduit le type exact de chemin défaillant dans un test et le rejette à la fois à l'export et à l'import.

Le dossier changerait si les journaux montraient qu'AS3223 n'a jamais exporté les routes ou qu'AS3356 les a rejetées. Il deviendrait plus sévère en présence d'une politique permissive connue, d'alertes ignorées ou d'une récidive. Il deviendrait moins sévère avec une cause étroite, un confinement automatique, une disparition cohérente dans les collecteurs et un correctif vérifié indépendamment.

Sources

  1. https://www.kentik.com/blog/beyond-their-intended-scope-ddos-mitigation-leak/
  2. https://manrs.org/2025/03/beyond-their-intended-scope-ddos-mitigation-leak/
  3. https://bgp.tools/as/3223
  4. https://bgp.tools/as/3356
  5. https://bgp.tools/as/7545
  6. https://bgp.tools/as/10310
  7. https://www.cenic.org/
  8. https://www.routeviews.org/routeviews/
  9. https://ris.ripe.net/docs/
  10. https://www.rfc-editor.org/rfc/rfc4271
  11. https://www.rfc-editor.org/rfc/rfc7908
  12. https://www.rfc-editor.org/rfc/rfc7454
  13. https://www.rfc-editor.org/rfc/rfc8212
  14. https://www.rfc-editor.org/rfc/rfc9234
  15. https://www.rfc-editor.org/rfc/rfc6811
  16. https://www.rfc-editor.org/rfc/rfc8893
  17. https://manrs.org/isps/guide/
  18. https://www.kentik.com/blog/a-brief-history-of-the-internets-biggest-bgp-incidents/