Resumen

  • El hecho queda limitado al 25 de mayo de 2023 y al evento asociado con AS37468, descrito por MANRS e Internet Society Pulse [1][2].
  • BGP distribuye información de alcanzabilidad, pero no es un sistema central de permisos.
  • RPKI y los ROA ayudan a validar origen; no validan por sí solos toda la ruta AS ni la relación comercial que permite exportarla [14][15].
  • AFRINIC RDAP, bgp.tools y PeeringDB sirven como registros de identidad de red, no como prueba de culpa [4][5][6].
  • Una reparación creíble requiere inventario de rutas previstas, registros de exportación, aceptación por vecinos, observación en colectores y un control probado contra reincidencia.

Qué ocurrió

La evidencia pública describe un problema de plano de control que tuvo consecuencias visibles para usuarios. Un usuario puede ver solo una página lenta o una aplicación que no responde. Debajo, la causa puede ser que la ruta elegida hacia un servicio se desvió por una relación de red que no debía transportar ese tráfico. El destino puede seguir funcionando y, aun así, la experiencia degradarse porque el camino cambió.

Las fuentes no muestran el comando interno, la política completa de cada sesión ni todos los flujos afectados. Tampoco prueban intención. Eso no convierte el incidente en irrelevante. La responsabilidad técnica empieza con el estado observable: una ruta salió de su alcance previsto y suficientes redes la vieron o la siguieron como para afectar conectividad.

Por qué el camino importa más que una sola validación de origen

Un ROA RPKI puede indicar que un AS está autorizado a originar un prefijo. Esa señal es poderosa cuando el origen es falso. Pero una fuga de rutas puede conservar un origen válido y fallar en otra capa: el camino por el que la ruta viaja. La pregunta entonces es si el vecino debía recibirla, aceptarla o exportarla de nuevo.

RFC 7908 describe la fuga como una violación del alcance de propagación. RFC 8212 empuja hacia políticas explícitas de importación y exportación. RFC 9234 aporta roles BGP y señales de relación. Esos estándares no prueban cómo estaba configurada cada sesión de Angola Cables. Sí muestran qué evidencias debe pedir una revisión seria.

Registros e identidad de AS37468

El ASN AS37468 evita que el análisis se convierta en una historia genérica de conectividad. bgp.tools muestra contexto de enrutamiento. AFRINIC RDAP registra el recurso autnum. PeeringDB ayuda a ubicar la superficie de interconexión declarada [4][5][6]. Esos registros son libros de evidencia. No dicen qué ruta fue aceptada por cada vecino ni qué política falló.

La distinción es importante. Un registro no configura routers. Un objeto en PeeringDB no equivale a un log de BGP. La realidad operacional es el código en ejecución y las rutas visibles. La función del registro es anclar identidad para que las preguntas posteriores no floten sin sujeto.

Colectores y límites de observación

RouteViews y RIPE RIS permiten contrastar afirmaciones con observación pública [7][8]. Su cobertura no es total: ven lo que sus peers les envían. Una ruta visible en un colector no prueba que todo Internet la haya seleccionado; una ruta ausente tampoco prueba que no existiera en otro lugar. Aun con esos límites, los colectores son infraestructura de rendición de cuentas.

Una línea temporal útil debe mostrar cuándo apareció el camino anómalo, en qué peers o colectores, cuándo se retiró y si reapareció. Esa línea debe compararse con logs de operadores. Si la ruta desaparece antes de la acción interna declarada, tal vez otro límite la contuvo. Si persiste después de la reparación anunciada, el cierre no está probado.

Qué debería demostrar el cierre

El cierre debe incluir el conjunto previsto de rutas exportadas, la diferencia con lo que salió, los vecinos que aceptaron o rechazaron, los estados RPKI o IRR disponibles, los límites de prefijos, la política de relaciones y la evidencia externa de retirada. También debe explicar qué control cambió y cómo se prueba.

La conclusión más útil es sobria: una fuga de rutas no se resuelve con un argumento de culpa, sino con pruebas de control. Cuando los permisos de ruta son explícitos y observables, el siguiente error tiene más probabilidades de fallar cerrado antes de llegar al usuario.

Fuentes

  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/