- En la red de CANTV (AS8048) en Venezuela ocurrieron varias fugas de rutas BGP (route leak), lo que provocó la propagación anómala de algunas rutas de red
- Según los datos de Cloudflare Radar, desde diciembre se han confirmado 11 eventos de fuga, y es muy probable que se deban a un error técnico causado por políticas de enrutamiento insuficientes
- En este incidente, AS8048 retransmitió a otro proveedor, AS52320 (V.tal GlobeNet), rutas que había recibido de su proveedor ascendente AS6762 (Sparkle), una estructura típica de fuga hairpin de Tipo 1
- La validación del origen de rutas basada en RPKI (ROV) no es efectiva en este caso, y se necesitan nuevos estándares como ASPA (Autonomous System Provider Authorization) y RFC9234 para prevenir este tipo de fugas
- Debido a la estructura basada en confianza de BGP, este tipo de incidentes es común, y la adopción de tecnologías como ASPA, Peerlock y RFC9234 es clave para operar un Internet más seguro
Concepto de fuga de rutas BGP
- BGP (Route Gateway Protocol) es el protocolo que intercambia rutas entre sistemas autónomos (AS) en Internet
- Las relaciones entre redes se componen como cliente-proveedor (customer-provider) o peer-peer
- Una fuga de rutas (route leak) se define en el RFC7908 como la “propagación de información de enrutamiento más allá de su alcance previsto”
- Ejemplo: cuando un cliente vuelve a anunciar a otro proveedor rutas que recibió de su proveedor
- Estas fugas violan la regla de valley-free routing, lo que hace que el tráfico siga rutas anómalas
- Como resultado, pueden producirse problemas como congestión de red, latencia y pérdida de tráfico
Caso de fuga de rutas de AS8048 (CANTV)
- Cloudflare Radar confirmó que AS8048 (CANTV) retransmitió a AS52320 (V.tal GlobeNet) rutas que había recibido de AS6762 (Sparkle)
- Se trata claramente de una fuga de rutas
- El origen de las rutas filtradas fue AS21980 (Dayco Telecom), una red cliente de AS8048
- La relación entre ambos AS aparece como proveedor-cliente en los datos de Cloudflare Radar y bgp.tools
- En la ruta, AS8048 aparecía con múltiples prepends
- El prepend es una técnica para hacer que una ruta sea menos atractiva y desviar el tráfico hacia otras rutas
- Por lo tanto, es poco probable que se trate de un MITM (ataque de intermediario) intencional
- La fuga ocurrió varias veces entre las 15:30 y 17:45 UTC del 2 de enero de 2026, y probablemente fue causada por errores de política de red o problemas de convergencia
- Según los registros de Cloudflare Radar, desde diciembre se repitieron 11 fugas similares, lo que apunta a una deficiencia persistente en las políticas
Causas técnicas y problemas de política
- Es posible que AS8048 haya configurado de forma demasiado laxa la política de exportación de rutas hacia su proveedor AS52320
- Si se usaron solo listas de prefijos basadas en IRR en lugar de etiquetas de comunidades BGP de clientes, pudo producirse una retransmisión errónea de rutas
- Este tipo de errores de política puede prevenirse mediante el atributo Only-to-Customer (OTC) de RFC9234
- OTC define explícitamente los roles de BGP (cliente, proveedor y peer) para bloquear la propagación incorrecta de rutas
El papel de RPKI y ASPA
- Sparkle (AS6762) no implementó completamente RPKI Route Origin Validation (ROV),
- pero este incidente es una anomalía de ruta (path), por lo que no puede prevenirse con ROV
- ASPA (Autonomous System Provider Authorization) ofrece validación basada en la ruta
- Cada AS especifica la lista de proveedores ascendentes autorizados, bloqueando automáticamente rutas anómalas
- Por ejemplo, si AS6762 declara que “no tiene proveedores ascendentes”, otras redes pueden rechazar rutas incorrectas que incluyan a AS6762
- ASPA funciona sobre la base de RPKI y tiene un efecto directo en la prevención de fugas de rutas
Propuestas para construir un BGP más seguro
- Como BGP es inherentemente un protocolo basado en confianza, las fugas causadas por errores de política o equivocaciones son frecuentes
- Si se aplican en conjunto tecnologías como ASPA, RFC9234 y Peerlock/Peerlock-lite, se puede
- reforzar la validación de rutas
- bloquear la propagación de rutas incorrectas
- mejorar la estabilidad de la red
- RIPE ya admite la creación de objetos ASPA, y
- los operadores deben solicitar a los proveedores de equipos de red la implementación de RFC9234
- La adopción colaborativa de estos estándares es el medio clave para prevenir incidentes de BGP como el caso de Venezuela
1 comentarios
Opiniones en Hacker News
El hilo de comentarios aquí me pareció un poco inesperado. Todos hablan del miedo a las empresas estadounidenses, pero no parece tener mucho que ver con el contenido del artículo
El texto de Cloudflare simplemente explica cómo funciona BGP y señala que las fugas de rutas del ISP venezolano ocurrieron con frecuencia
Claro, Cloudflare podría estar equivocado o estar ocultando algo, pero en ninguna parte del texto dice que hayan intervenido directamente. Me intriga saber en qué se basan para estar tan seguros
Aun así, viendo casos como Stuxnet o Dual EC DRBG, no hay que subestimar la capacidad de los gobiernos para aprovechar vulnerabilidades 0-day
Un amigo mío trabajó en una empresa FANG y dijo haber visto cómo entregaban flujos de datos directamente al gobierno. Los backdoors en ISP también son reales (Room 641A)
Si Cloudflare hubiera cooperado por orden judicial, ¿habría podido publicar legalmente un texto negándolo?
Por eso creo que existe ese escepticismo de base. La conclusión de Cloudflare de que “esto es un problema viejo y no es gran cosa” se siente un poco débil
También me pregunto si, por la propia estructura de BGP, hay alguna razón por la que EE. UU. pudiera hacer esto más fácilmente que otros países
Últimamente la opinión pública sobre el gobierno estadounidense es tan cínica que hasta incidentes pequeños generan sospechas
O quizá solo sean cuentas sociales de Rusia o China, pero quién sabe
Además, en este artículo de CNN, Trump mencionó la posibilidad de acción militar incluso contra aliados
Con el gobierno actual, hasta parecería más probable que presumieran públicamente un ataque así. Por eso, por ahora, yo me inclino por la explicación de “simple error de configuración”
Aun así, es natural que crezca la desconfianza cuando cada vez que EE. UU. aparece en las noticias es por amenazas, retiradas o sanciones
Estaba con sueño, pero el artículo me pareció interesante. El análisis del AS path prepending respalda bastante bien la teoría de un accidente
Si un Estado hubiera querido interceptar tráfico, no tendría sentido alargar la ruta a propósito
Lo más probable es que haya sido un simple error de configuración de enrutamiento. BGP sigue siendo un sistema basado en confianza, así que un pequeño typo puede afectar a todo el mundo
Una falta de filtros de exportación suena más plausible que la mala intención
De hecho, también existen actores no estatales que manipulan tráfico publicitario
Aun así, desde la perspectiva de un operador de red, este tipo de errores son comunes y los scripts automatizados de ajuste de tráfico a veces agravan el problema
Al final, el verdadero problema es la fragilidad estructural de BGP. Seguridad y BGP siguen siendo palabras que no combinan bien
Vale la pena revisar NSA Network Shaping 101, uno de los documentos de Snowden
Es un documento escrito en 2007 que explica ASIN y el control de tráfico en capa 3
Más bien solo explica la estructura por la que el tráfico enviado a cierta IP termina pasando por ese enlace
Después de leer el artículo, me volvió a dar escalofríos pensar en lo profundamente unidas que están las empresas estadounidenses y el gobierno
Ya lo sabía desde antes, pero esta vez sentí que la confianza se rompió por completo. Parece un punto de quiebre de época
Esta infraestructura de vigilancia existe desde hace mucho tiempo, y Japón también hacía monitoreo de tráfico en tiempo real en 2003
Ahora la tecnología DPI es demasiado fácil de implementar
La gente nueva que entra a la industria empieza con ingenuidad, pero al final descubre la relación tan estrecha entre gobiernos y empresas y pierde la confianza
Con el tiempo llega otra generación nueva y repite el mismo proceso
La idea central del texto es la navaja de Hanlon: sospechar primero de un error antes que de mala intención
Claro, si Cloudflare hubiera distorsionado los hechos, merecería críticas, pero todavía no hay pruebas de eso
Pensando en la infraestructura envejecida de Venezuela, hasta cuesta creer que hiciera falta un ciberataque sofisticado
La realidad es que contratistas corruptos entregaron sistemas mal hechos
La estructura de corrupción es un problema mucho mayor que cualquier ciberataque
Al final lo resolví dándole dinero a un técnico que trabajaba en la calle, pero el número que me pusieron era de una compañía de taxis
En un entorno así, hablar de un ataque BGP suena hasta un poco absurdo
Este texto fue un buen repaso de BGP
Cuando trabajaba como ingeniero de redes usaba mucho la magia de las BGP communities,
y a veces pienso que si BGP solo expresara tres tipos —provider, customer y peer— quizá todo sería mucho más simple
Es como quitarle a Google Maps los datos de tráfico o de semáforos: el cálculo sería más fácil, pero el resultado sería pésimo
Una vez Google Maps me sacó de la autopista para pasar por el estacionamiento de un Walmart y luego volver a otra autopista
En ese momento pensé que era solo un error de algoritmo, pero si me hubiera mandado por el autoservicio de McDonald’s, ya habría sospechado una conspiración
Con este caso pasa algo parecido: la explicación de un error simple resulta más convincente
Da un poco de miedo que la infraestructura central de internet esté operada sobre todo por empresas estadounidenses
Ya va siendo hora de que otros países también construyan estructuras independientes
La pregunta sería: ¿quién tendría que administrarlo en su lugar?
Llevo mucho tiempo observando incidentes de BGP, y siempre siento que es difícil distinguir entre cambios intencionales, errores y fallas estructurales
Por eso primero me hago tres preguntas: ¿el alcance del impacto fue creciendo?, ¿las rutas cambiaron de forma simétrica?, ¿la recuperación fue limpia?
Y primero reviso los cambios en AS-path prepending y comparo la visibilidad por región
Al final sigo la pista de “quién se benefició”. Me da curiosidad saber qué indicadores usan otros para detectar estos problemas
La cobertura global de Cloudflare es realmente impresionante
Aun así, ellos sí son una organización muy enfocada en la ingeniería, así que suelen publicar este tipo de análisis de forma muy buena