Resumen

  • Cloudflare revisó una anomalía BGP en Venezuela e identificó a AS8048, CANTV, como el sistema que parecía filtrar rutas aprendidas por AS6762 hacia AS52320, con prefijos originados por AS21980, Dayco Telecom [1].
  • Low Orbit Security publicó ejemplos de rutas en los que AS8048 aparecía repetido dentro de caminos relacionados con el espacio 200.74.224.0/20. Esos ejemplos sirven como evidencia de ruta, no como censo completo de usuarios afectados [2].
  • APNIC advirtió después que muchas detecciones de fugas pueden ser efímeras y ligadas a convergencia. Por eso la duración, la propagación y la selección real de tráfico importan tanto como la presencia del camino [3].
  • RPKI Route Origin Validation ayuda cuando el origen es incorrecto. En esta clase de incidente, el origen puede seguir siendo correcto mientras el camino viola una relación. Los controles relevantes son política explícita, BGP Roles, Only-to-Customer, ASPA y telemetría retenida [1][5][6][7][8].
  • Este artículo no afirma que CANTV haya causado una caída nacional. Pregunta qué evidencia debería existir para demostrar qué ruta se exportó, quién la aceptó, cuándo se retiró y por qué la misma clase de ruta debería fallar cerrada.

Qué ocurrió

El registro público empieza con datos de Cloudflare Radar y de colectores BGP. Low Orbit Security señaló que prefijos venezolanos aparecían con AS8048 en caminos que necesitaban explicación. Cloudflare precisó después que el patrón involucraba rutas aprendidas por AS6762, Sparkle, y redistribuidas hacia AS52320, V.tal GlobeNet, con AS21980 como origen de algunos prefijos [1][2].

Para un lector no especializado, un camino AS es la lista de redes autónomas que una ruta dice atravesar. Una relación normal separa cliente, par y proveedor. Un cliente puede enviar sus propias rutas y las de sus clientes a un proveedor. Un operador no debería convertir rutas de una relación limitada en tránsito amplio para terceros. Cuando esa frontera se cruza, aparece una fuga de ruta [5].

La frontera de prueba es esencial. Cloudflare llamó al patrón fuga de ruta, pero no lo presentó como prueba de apagón, intención o interceptación. APNIC añadió que ciertos eventos visibles en detectores públicos pueden durar poco y desaparecer durante convergencia. Esa cautela no elimina el problema. Define el estándar: primero ruta observada, duración y propagación; después impacto e intención.

Por qué importa

CANTV es un operador nacional. Sus políticas de enrutamiento pueden influir en bancos, agencias públicas, empresas, proveedores regionales y usuarios finales. Una regla de exportación demasiado amplia puede hacer que una señal local se vuelva visible fuera de su alcance previsto. Incluso si el impacto final fue limitado, la organización debe poder reconstruir qué ruta se aceptó, qué ruta se exportó y qué alarma activó la reparación.

El análisis más amplio de FastNetMon recuerda que BGP no comprende de forma nativa la intención, la calidad ni la topología esperada. Por eso una ruta sintácticamente válida puede propagarse aunque la relación sea operacionalmente extraña [4].

La defensa "nadie probó daño" no basta. Una red crítica debe demostrar que sus relaciones comerciales y técnicas coinciden con el estado ejecutado en los routers. También debe distinguir entre observación pública, inferencia técnica y dato privado no disponible.

La capa técnica

RPKI ROV verifica si un ASN está autorizado a originar un prefijo [8]. Aquí el origen podía permanecer autorizado. El problema estaba en el camino. RFC 8212 exige política explícita de importación y exportación; RFC 9234 define roles BGP y el atributo Only-to-Customer; ASPA apunta a evidencia de relación proveedor-cliente [6][7]. Estos controles no son una garantía automática, pero describen el tipo de freno que corresponde a una fuga de relación.

Una investigación creíble debería incluir prefijos, sesiones, roles, mapas de ruta, primeros y últimos tiempos observados, colectores externos, tráfico seleccionado, retiro, cambios de política y pruebas de no recurrencia. Sin esos datos, el público no puede separar un evento breve de convergencia de una política de exportación insegura.

Quién pudo verse afectado

Las fuentes públicas nombran prefijos y ASNs, no todos los usuarios afectados. Una ruta visible en un colector puede no ser usada para reenviar mucho tráfico. También puede afectar a usuarios concretos si redes relevantes la seleccionan. La investigación responsable debe unir rutas, flujos, pérdida, latencia, quejas de clientes y cronología operativa.

Qué observar después

Hay que observar si las alertas sobre AS8048 se repiten, si aparecen caminos parecidos con AS6762, AS52320 o AS21980, y si CANTV o sus vecinos publican mejoras de política. Las señales útiles incluyen filtros de exportación, roles BGP, OTC, preparación ASPA, alarmas de conteo de rutas y revisión independiente.

El caso se vuelve más grave si aparecen fugas repetidas, alertas ignoradas o falta de conciliación entre colectores públicos y registros internos. Se vuelve menos grave si los operadores publican una causa estrecha, duración limitada, tráfico seleccionado bajo, retiro limpio y reparación probada.

Fuentes

  1. https://blog.cloudflare.com/bgp-route-leak-venezuela/
  2. https://loworbitsecurity.com/radar/radar16/
  3. https://blog.apnic.net/2026/05/25/ephemeral-leaks-and-automated-bgp-route-leak-detection/
  4. https://fastnetmon.com/2026/01/09/venezuelas-routing-anomaly-and-the-bigger-problem-with-bgp-security/
  5. https://www.rfc-editor.org/rfc/rfc7908
  6. https://www.rfc-editor.org/rfc/rfc9234
  7. https://www.rfc-editor.org/rfc/rfc8212
  8. https://www.rfc-editor.org/rfc/rfc6811