Resumen

  • Desde las 07:35 UTC, AS3223 propagó por AS3356 rutas que había aprendido de pares; el evento duró alrededor de veinte minutos [1].
  • Fue una fuga de camino o de relación, no una simple originación por el sistema autónomo equivocado.
  • La validación de origen RPKI no era suficiente. Los roles BGP, Only-to-Customer, las políticas explícitas y la vigilancia de composición responden a quién puede pasar qué camino a qué vecino [13][14][15][16].
  • RouteViews y RIPE RIS aportan observaciones externas valiosas, pero no ven todos los routers ni la experiencia de todos los usuarios [8][9].
  • Las fuentes públicas no demuestran intención, causa interna exacta, punto de congestión ni conjunto completo de redes afectadas.

Qué ocurrió

Border Gateway Protocol, o BGP, es el protocolo con el que redes independientes intercambian información de alcance. Cada red se representa mediante un número de sistema autónomo, o ASN. Kentik informó que Voxility AS3223 anunció a Lumen AS3356 rutas aprendidas de pares. Un par suele intercambiar tráfico de los clientes respectivos sin ofrecer tránsito completo; un proveedor de tránsito lleva tráfico hacia el resto de Internet. Exportar una ruta de un par a un proveedor puede extenderla fuera de su alcance previsto [1][11].

Kentik contó 31.258 rutas en su reconstrucción. De ellas, 7.381 fueron vistas por al menos cincuenta pares que alimentan el colector público RouteViews [1][8]. Es una señal de propagación amplia dentro de la muestra, no un censo de Internet. Los ejemplos hacia prefijos asociados con TPG Telecom y Yahoo mostraron el paso inesperado por AS3223 y AS3356. No atribuyen la causa a esas organizaciones.

El análisis de flujos de Kentik relacionó el cambio de camino con tráfico desviado y con una cantidad mayor de tráfico perturbado o descartado. No identifica el enlace ni el equipo exacto que se saturó. Un cierre responsable debe preservar esa incertidumbre: el registro público demuestra un camino anómalo y efectos de tráfico, pero no cada decisión privada.

Por qué importa

Los proveedores de mitigación DDoS pueden transportar legítimamente rutas de muchos clientes y activar anuncios con rapidez durante un ataque. Una lista estática puede ser demasiado amplia o lenta. Eso no justifica aceptar cualquier ruta. Exige un registro operativo que vincule cliente, prefijos autorizados, origen, rol de sesión, ventana de activación, retorno y caducidad.

El proveedor de tránsito tiene una obligación complementaria. Debe separar las rutas autorizadas por un cliente de las que ese cliente aprendió de pares u otros proveedores. Si la única regla es que el cliente anuncia muchas rutas, un error local obtiene un canal de propagación global. La política declarada debe compararse con la configuración que realmente ejecutan los routers.

La capa técnica

RPKI y las autorizaciones de origen de ruta, o ROA, permiten comprobar si un ASN puede originar un prefijo [15]. En este incidente, el origen podía seguir siendo legítimo y el defecto estar en medio del camino. Por eso la validación de origen no resolvía la relación.

RFC 8212 establece la necesidad de políticas explícitas de importación y exportación [13]. RFC 9234 define roles BGP y el atributo Only-to-Customer, u OTC, para señalar límites de propagación [14]. ASPA aporta evidencia sobre relaciones de proveedor [16]. Son controles de referencia, no prueba de que estuvieran desplegados exactamente entre AS3223 y AS3356.

Los registros ASN y las páginas de bgp.tools vinculan los caminos con identidades numéricas estables [3][4][5][6]. Son libros de registro, no sentencias. La prueba decisiva es el estado en ejecución: rutas recibidas, seleccionadas, anunciadas y retiradas, junto con las versiones de política.

Quién resultó afectado

Una fuga puede alargar el camino, aumentar la latencia, saturar enlaces o provocar pérdida de paquetes mientras la aplicación de destino continúa sana. Destinos, usuarios, proveedor de mitigación, tránsito y redes posteriores ven partes distintas. Ningún colector observa toda Internet. La investigación debe alinear registros de routers, colectores, flujos, pérdida, avisos de clientes y retiradas.

Qué vigilar

Hay que vigilar la diferencia entre el conjunto autorizado y el anunciado, la aparición de orígenes o relaciones inusuales, la cobertura de roles BGP y OTC, la convergencia de RouteViews y RIPE RIS y la recuperación del tráfico. Una reparación creíble reproduce en una prueba la clase exacta de camino fallido y la rechaza tanto en la exportación como en la importación.

La evaluación cambiaría si los registros mostraran que AS3223 nunca exportó las rutas o que AS3356 las rechazó. Sería más grave con una política permisiva conocida, alertas ignoradas o repetición. Sería menos grave con una causa acotada, contención automática, retirada coherente en los colectores y una reparación verificada de forma independiente.

Fuentes

  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/