Resumen

  • Cloudflare informó de dos eventos diferentes el 27 de junio de 2024: AS267613 comenzó a originar 1.1.1.1/32 a las 18:51 UTC, mientras que AS262504 filtró 1.1.1.0/24 a través de AS1031 a las 18:52 UTC.
  • El anuncio /32 y la fuga /24 no fueron variantes de una sola ruta incorrecta. Tuvieron mecanismos, estados de validación y posibles controles preventivos diferentes.
  • Cloudflare atribuyó parte del efecto del /32 a que una red de nivel uno no identificada lo aceptó como una ruta de blackholing activado remotamente, o RTBH. Las fuentes públicas no permiten reconstruir la implementación privada de ese proveedor.
  • La fuga /24 conservaba el origen correcto de Cloudflare, AS13335, pero seguía un camino no autorizado. Por eso la validación de origen podía aceptar el origen sin certificar la legitimidad de toda la secuencia de sistemas autónomos.
  • Cloudflare describió como efectos la imposibilidad de llegar a 1.1.1.1 o una latencia elevada para algunos usuarios. Esa información no demuestra una interrupción mundial del DNS.
  • APNIC sostuvo que el evento no fue visible globalmente y que probablemente fue marginal frente al conjunto de usuarios de Internet. Internet Society Pulse empleó un lenguaje de observación más amplio; ambos alcances deben conservarse con su atribución correspondiente.
  • Los ROA, los registros de asignación y los colectores como RouteViews y RIPE RIS sirven para validar, observar y reconstruir hechos. No configuran filtros, no autorizan rutas y no prueban por sí solos todos los resultados de reenvío.
  • La responsabilidad operativa sigue el control práctico: quién podía autorizar el origen, restringir la exportación del cliente, rechazar la ruta, limitar su propagación, aprobar un blackhole, detectar el desvío, contenerlo y confirmar su retirada.

Dos incidentes, no una única anomalía

La dirección 1.1.1.1 es ampliamente reconocida por su uso en el servicio de resolución DNS público operado por Cloudflare. Esa notoriedad puede hacer que cualquier problema de alcance se describa rápidamente como «un secuestro de 1.1.1.1» o «una caída de DNS». Sin embargo, ese atajo elimina precisamente la distinción que permite entender el caso y asignar controles con rigor.

Según el relato de Cloudflare, AS267613 comenzó a anunciar el prefijo más específico 1.1.1.1/32 a las 18:51 UTC del 27 de junio de 2024. Un minuto después, a las 18:52 UTC, AS262504 comenzó a filtrar 1.1.1.0/24 a través de AS1031. La proximidad temporal no convierte ambos sucesos en una sola acción coordinada ni demuestra que compartieran intención, configuración o causa.

El primer evento fue un anuncio de origen de un /32: una ruta que identificaba únicamente la dirección 1.1.1.1. Cloudflare indicó que ese anuncio era inválido desde la perspectiva de RPKI y que una red de nivel uno no identificada lo aceptó como RTBH. En los lugares donde esa señal fue aceptada y aplicada, el efecto no consistía necesariamente en entregar el tráfico al sistema autónomo que había originado el anuncio. El tráfico podía descartarse deliberadamente como resultado del mecanismo de blackhole.

El segundo evento fue una fuga de 1.1.1.0/24. En esa ruta aparecía el origen correcto, AS13335, perteneciente a Cloudflare, pero la ruta se propagaba por una relación y una cadena que Cloudflare consideró no autorizadas. La identidad correcta del origen no convertía en correcto todo el camino. Esa diferencia expone uno de los límites más importantes de la validación de origen: confirmar que un sistema autónomo está autorizado para originar un prefijo no equivale a validar cada relación comercial, cada exportación ni cada tránsito intermedio.

No existe en el conjunto de fuentes una prueba de intención maliciosa por parte de AS267613 o AS262504. Tampoco se aportan pruebas suficientes para declarar negligencia, ilegalidad, ocultamiento o responsabilidad jurídica. El análisis puede identificar puntos de control y formular preguntas verificables, pero no debe convertir una configuración observable en una conclusión sobre motivos privados.

Cronología delimitada del 27 y 28 de junio

La cronología publicada por Cloudflare comienza con los dos cambios de ruta: el anuncio de 1.1.1.1/32 atribuido a AS267613 a las 18:51 UTC y la fuga de 1.1.1.0/24 atribuida a AS262504 a las 18:52 UTC, esta última a través de AS1031. Cada marca temporal debe permanecer unida a la atribución de Cloudflare, pues las fuentes públicas son observaciones y relatos posteriores, no acceso completo a los sistemas internos de todos los participantes.

Cloudflare abrió su incidente a las 20:03 UTC. Entre el inicio de las anomalías y esa declaración transcurrió más de una hora. Ese intervalo es relevante para evaluar la capacidad de detección, la correlación entre telemetría de servicio y rutas, y la velocidad de escalamiento entre equipos. No demuestra por sí solo que la organización ignorara alertas, careciera de visibilidad o actuara con retraso injustificado. Para establecer cualquiera de esas conclusiones serían necesarios registros internos de alarmas, turnos, contactos y decisiones.

La empresa informó de que algunos usuarios no podían llegar a 1.1.1.1 o experimentaban una latencia elevada. Es una descripción de efectos parciales, no una prueba de que todos los usuarios del resolvedor, todas las regiones o todos los proveedores estuvieran afectados. El camino elegido por BGP depende de la vista local de cada red, sus políticas, sus filtros y las rutas alternativas disponibles. Por eso una anomalía ampliamente observada por colectores puede tener consecuencias muy diferentes para redes concretas.

Cloudflare registró la resolución completa de la fuga /24 a las 02:28 UTC del 28 de junio. Esa hora se refiere expresamente a la resolución comunicada del evento /24 y no debe emplearse para fusionar el ciclo de vida de ambas anomalías. La retirada observada en colectores, la desaparición de un anuncio de las tablas de ciertos operadores y la recuperación del servicio tampoco son necesariamente el mismo momento.

APNIC describió el impacto como no visible globalmente y probablemente marginal respecto del total de usuarios de Internet. Internet Society Pulse utilizó una descripción más amplia de las observaciones realizadas en redes y países. Esas formulaciones no tienen por qué ser incompatibles: una señal puede aparecer en numerosos puntos de observación sin dominar el tráfico mundial ni afectar materialmente a la mayoría de los usuarios. Lo importante es no sustituir las atribuciones por una cifra o geografía universal que las fuentes no prueban.

Cómo un /32 cambia la selección de rutas

BGP distribuye información de alcance entre sistemas autónomos. Cada red aplica sus propias políticas a las rutas que recibe y puede elegir, rechazar o propagar una ruta de acuerdo con atributos, relaciones, filtros y preferencias locales. Cuando existen rutas que cubren una misma dirección, el reenvío IP favorece normalmente el prefijo más específico.

Esa regla hace que un anuncio de 1.1.1.1/32 pueda ser especialmente disruptivo allí donde sea aceptado. La ruta legítima 1.1.1.0/24 cubre 256 direcciones IPv4, incluida 1.1.1.1. El /32 cubre solo esa dirección y, por ser más específico, puede atraer el tratamiento del tráfico destinado a ella si logra entrar en la tabla o en el mecanismo de descarte del receptor.

No obstante, no todas las redes aceptan ni propagan prefijos IPv4 tan específicos. Es habitual aplicar filtros de longitud que impiden distribuir más allá de ciertos límites rutas que no tienen sentido operativo en la tabla global. Que una ruta aparezca en un colector o sea aceptada por un vecino tampoco demuestra que todas las redes la incorporaran, la propagaran o la utilizaran para el reenvío.

Cloudflare afirmó que una red de nivel uno aceptó el /32 como una señal de RTBH. El blackholing activado remotamente es un control defensivo legítimo: permite descartar tráfico dirigido a un destino atacado para evitar que una inundación sature enlaces o perjudique una infraestructura mayor. El problema no es la mera existencia de RTBH. El problema de responsabilidad surge cuando una red acepta una solicitud de descarte sin verificar de manera suficiente quién puede solicitarla, para qué prefijo, con qué longitud y dentro de qué alcance.

Una política segura necesita al menos una identidad de cliente clara, una lista de prefijos autorizados, límites de longitud, comunidades permitidas, un alcance controlado, registros de cada activación y una vía inequívoca para retirar la orden. Una señal que causa descarte es deliberadamente destructiva dentro de su ámbito: cumple su función eliminando tráfico. Precisamente por ello requiere una autorización más estricta que una preferencia ordinaria de ruta.

Las fuentes no identifican al proveedor de nivel uno y no ofrecen su configuración privada. No corresponde deducir su nombre, su topología, sus comunidades internas o la lógica exacta con la que procesó el anuncio. La conclusión demostrable es más limitada: Cloudflare informó de que un proveedor de esa categoría aceptó el /32 como RTBH, y ese comportamiento convierte la autorización de blackhole en un punto de control que merece evidencia específica.

Por qué la fuga /24 plantea otro problema

La fuga de 1.1.1.0/24 requiere un análisis diferente. Cloudflare era el origen correcto mediante AS13335, de modo que un ROA que autorizara ese origen podía hacer que la ruta resultara válida bajo la validación de origen. Sin embargo, el camino por el que la ruta se exportó y propagó seguía siendo incorrecto o no autorizado.

Una fuga de rutas ocurre cuando información aprendida en una relación se anuncia a otro vecino de una forma contraria a la política esperada. Por ejemplo, una ruta aprendida de un proveedor o de un par puede exportarse como si debiera ofrecerse a otro proveedor, creando tránsito no previsto. La definición concreta depende de roles, relaciones y políticas, no solo de que cada número de sistema autónomo del camino exista.

RPKI permite relacionar un prefijo con un sistema autónomo autorizado para originarlo y, cuando corresponde, con una longitud máxima admisible. La validación de origen puede clasificar como inválida una ruta cuyo origen no está autorizado o cuya longitud supera el límite indicado por el ROA. Esa capacidad habría sido relevante para el anuncio /32 si el objeto de autorización no permitía esa combinación.

Pero RPKI no valida todas las relaciones intermedias del AS_PATH. Una ruta puede llevar un origen válido y, al mismo tiempo, haber sido exportada por un cliente, proveedor, par, route server o tránsito de manera contraria a la política prevista. El caso del /24 muestra por qué «RPKI válido» no debe usarse como sinónimo de «ruta completamente autorizada».

AS1031 aparece en el camino de propagación descrito por Cloudflare. La mera presencia de un sistema autónomo en una observación no establece por sí sola cuál fue su contrato, qué sesión recibió la ruta, qué política debía aplicar o qué decisión humana estuvo implicada. Para asignar una responsabilidad más precisa harían falta datos de sesión, roles, configuración efectiva, registros de cambios y mensajes de retirada.

Registros, ROA y código en funcionamiento

Los registros de asignación de direcciones aportan una base documental para determinar quién administra un bloque y qué organizaciones o contactos están asociados con él. Los ROA añaden una declaración criptográficamente verificable sobre qué sistema autónomo puede originar un prefijo y hasta qué longitud. Ambas capas reducen la ambigüedad y ayudan a investigar anomalías.

No obstante, un registro no instala automáticamente un filtro en un router. Un ROA tampoco obliga a una red a descartar una ruta inválida. Cada operador debe obtener los datos, validarlos, integrarlos en su plataforma, definir una política y aplicarla a sesiones reales. La disponibilidad de evidencia y la ejecución del control son responsabilidades diferentes.

Esta separación evita dos errores. El primero es culpar al registro porque una red no aplicó una política disponible. El segundo es tratar la existencia de un ROA como garantía de disponibilidad. Los datos pueden ser correctos y, aun así, una ruta inválida puede propagarse por redes que no ejecutan validación de origen. A la inversa, una ruta puede superar la validación de origen y seguir siendo una fuga de camino.

Los estándares describen herramientas y comportamientos, pero no demuestran su implantación en ninguna red nombrada. Las recomendaciones de filtrado, el rechazo por defecto, los roles BGP y la señal Only-to-Customer ofrecen mecanismos para limitar rutas impropias. Para afirmar que uno de ellos estaba desplegado, mal configurado o ausente en un operador concreto se necesitaría evidencia adicional.

Los límites de los colectores de rutas

RouteViews y RIPE RIS recopilan observaciones BGP desde numerosos puntos. Son recursos esenciales para establecer cuándo apareció una ruta, cómo se veía desde determinadas sesiones y qué caminos quedaron preservados. También permiten comparar anuncios, retiradas y cambios de origen o de longitud.

Sin embargo, un colector no autoriza una ruta. No actúa como registro de derechos, no configura los filtros de los participantes y no impide que una ruta se propague. Su visión también es parcial: muestra lo que llega a sus puntos de observación, no cada decisión tomada en todos los routers ni cada paquete reenviado por Internet.

Una ruta visible en un colector no prueba que todo el tráfico siguiera ese camino. Tampoco permite calcular por sí sola el volumen exacto perdido, el número de clientes afectados o la geografía completa del impacto. Para eso harían falta datos complementarios: telemetría de tráfico, sondas activas, registros del resolvedor, tablas locales, métricas de latencia y quizá información de proveedores que no es pública.

Los colectores sí preservan un elemento crucial de responsabilidad: una cronología independiente que puede contrastarse con declaraciones de operadores. Esa evidencia ayuda a formular preguntas concretas y a verificar retiradas, aunque no sustituye los registros de configuración ni la telemetría de servicio.

Impacto: lo observado y lo que no está probado

La consecuencia informada fue que algunos usuarios no pudieron alcanzar 1.1.1.1 o experimentaron una latencia elevada. En un resolvedor DNS, la falta de alcance puede manifestarse como consultas que expiran, reintentos hacia otro resolvedor o demoras en aplicaciones dependientes. El comportamiento final dependerá de la configuración del dispositivo, la red de acceso y la disponibilidad de resolutores alternativos.

No debe extrapolarse esta descripción a una caída global del DNS ni siquiera a una interrupción mundial del servicio de Cloudflare. El alcance de BGP es desigual. Una red que rechazara el /32, ignorara la comunidad de blackhole o mantuviera una ruta preferida diferente podía no sufrir el mismo efecto que otra que aceptara y propagara la anomalía.

La afirmación de APNIC sobre visibilidad no global y efecto probablemente marginal constituye un límite importante. Al mismo tiempo, la descripción más amplia de Internet Society Pulse muestra que la anomalía fue observable en una diversidad de redes y lugares. «Observable en muchos puntos» y «marginal frente a toda la población de Internet» miden dimensiones distintas.

No hay pruebas en las fuentes de una cifra completa de clientes, un volumen exacto de tráfico perdido, una lista exhaustiva de países o la totalidad de caminos de propagación. Tampoco se demuestra que un resultado de forwarding observado desde una red pueda atribuirse a todos los usuarios de esa red. Cualquier estimación posterior debería especificar método, período, cobertura y margen de incertidumbre.

Una cadena de control, no un único culpable técnico

La responsabilidad operativa puede organizarse según los puntos donde existía capacidad real para cambiar el resultado.

En el origen del /32, el primer control consiste en impedir que un sistema anuncie un prefijo para el que no tiene autorización. Eso requiere filtros de salida, límites por prefijo, validación de configuración y controles sobre quién puede modificar sesiones o políticas. Si el anuncio se produjo a través de un proveedor, ese proveedor tenía su propio punto de control en la aceptación de rutas de cliente.

En el origen de la fuga /24, la responsabilidad empieza con la política de exportación. Un sistema autónomo debe conocer qué rutas puede anunciar a cada clase de vecino. La presencia del origen legítimo AS13335 no elimina la obligación de impedir la exportación impropia de una ruta aprendida.

Los proveedores, pares y route servers tienen controles diferentes. Pueden mantener listas de prefijos, verificar relaciones cliente-proveedor, aplicar límites de longitud, usar validación de origen, definir roles y rechazar por defecto rutas no autorizadas. La aplicabilidad de cada mecanismo depende del tipo de sesión. Un route server, por ejemplo, participa en la distribución de rutas dentro de un punto de intercambio, pero su papel no es idéntico al de un proveedor que ofrece tránsito.

En el nivel uno que, según Cloudflare, aceptó el /32 como RTBH, la cuestión específica es la autorización de blackhole. ¿Podía ese vecino solicitar el descarte de 1.1.1.1? ¿Estaba autorizado para el bloque padre? ¿La longitud /32 estaba permitida? ¿La señal debía actuar solo dentro de una red o propagarse? ¿Quedaron registrados el inicio, el solicitante y la retirada? Las fuentes no responden esas preguntas, pero establecen qué evidencia sería pertinente.

Cloudflare, como operador del servicio y origen legítimo del /24, controlaba la monitorización de alcance, el seguimiento de rutas, la comunicación del incidente, el contacto con vecinos y la verificación de recuperación. Eso no implica que pudiera configurar los routers de terceros. Su responsabilidad se concentra en detectar, escalar, facilitar pruebas, coordinar mitigaciones y confirmar que el servicio recuperó un estado estable.

Los registros y operadores RPKI controlan la calidad y disponibilidad de los datos de autorización. Los colectores preservan observaciones. Ninguna de esas funciones sustituye a la política ejecutada en el borde de cada red.

Prevención: aplicar controles distintos a fallos distintos

Para el anuncio /32, una defensa directa es el filtrado de prefijos de cliente. El proveedor que recibe rutas debe disponer de una fuente fiable que limite los bloques y longitudes que ese cliente puede anunciar. La validación de origen añade otra barrera cuando el anuncio contradice un ROA por origen o longitud máxima.

Los límites de longitud son especialmente relevantes porque un /32 en la tabla global de IPv4 tiene un significado operativo muy diferente de una ruta más agregada. Aun así, una regla general no debe confundirse con la política de RTBH, donde un operador puede aceptar prefijos muy específicos dentro de un canal controlado. La solución no es prohibir todo blackholing, sino separar su autorización de la aceptación ordinaria de rutas.

Para la fuga /24, la validación de origen no basta. Son necesarias políticas explícitas de importación y exportación, conocimiento de roles y filtros basados en la relación. El rechazo por defecto reduce el riesgo de que una sesión nueva comience a intercambiar rutas antes de que exista una política deliberada.

Los roles BGP y Only-to-Customer pueden ayudar a expresar y detectar relaciones incompatibles con una propagación determinada. No son una prueba retroactiva de lo que ocurrió en este caso ni una garantía universal: su valor depende de una implementación bilateral correcta y de políticas que actúen sobre la señal.

Los operadores también pueden utilizar límites de prefijos, validación de objetos de registro, listas de rutas autorizadas y controles de cambios. Ningún mecanismo individual cubre todos los fallos. La defensa útil combina datos correctos, configuración verificable y respuesta operativa.

Detección: correlacionar plano de control y experiencia de servicio

Una organización que opera una dirección crítica debería vigilar cambios de origen, anuncios más específicos, estados RPKI, caminos inesperados y variaciones en la visibilidad regional. Las alertas deben distinguir un origen nuevo, una longitud anómala y una fuga con origen legítimo, porque requieren diagnósticos diferentes.

La telemetría BGP debe correlacionarse con indicadores de servicio: pérdida de alcance, latencia, tasas de consulta, expiraciones y distribución geográfica. Una alarma de rutas sin degradación observable puede seguir siendo importante, pero su prioridad no es idéntica a una anomalía que coincide con pérdida de servicio.

La diversidad de colectores y sondas es valiosa. Un único punto puede mostrar una ruta que no se propaga ampliamente o, al contrario, no ver una anomalía presente en otras partes. La detección madura compara fuentes y conserva la incertidumbre en lugar de inferir una perspectiva mundial desde una sola sesión.

También resulta necesario medir el tiempo entre la primera observación, la primera alarma, la clasificación, la apertura formal del incidente y la coordinación con terceros. Esas marcas permiten mejorar el proceso sin confundir un intervalo visible con una prueba automática de negligencia.

Contención: reducir alcance sin crear un segundo fallo

La contención del /32 podía incluir la retirada en origen, el rechazo por proveedores y la eliminación de cualquier tratamiento RTBH no autorizado. Si una comunidad de blackhole había sido aceptada, el receptor necesitaba verificar no solo que la ruta desapareciera, sino que el estado de descarte asociado quedara retirado de todos los ámbitos pertinentes.

La contención de la fuga /24 requería corregir la exportación y detener la propagación por vecinos. Un proveedor podía filtrar el camino o la combinación de prefijo y cliente; un route server podía revisar su política aplicable; otros operadores podían rechazar la ruta según su conocimiento local. La respuesta debía evitar cambios demasiado amplios que eliminaran rutas legítimas.

Cloudflare podía distribuir información precisa sobre el prefijo, el origen esperado y los caminos observados. Esa coordinación acelera la respuesta, pero no convierte a Cloudflare en autoridad sobre las políticas de terceros. Cada operador sigue siendo responsable de validar el cambio dentro de su propio dominio.

Una contención eficaz debe ser reversible, limitada y registrada. Los remedios de emergencia que bloquean prefijos enteros o alteran filtros globales pueden introducir daños adicionales. La presión temporal no elimina la necesidad de identificar el alcance de cada acción.

Recuperación: retirar, observar y verificar

La retirada anunciada es solo el primer paso de la recuperación. BGP converge a ritmos distintos, las rutas pueden permanecer temporalmente en algunas vistas y los mecanismos auxiliares —incluido un blackhole— pueden tener estados propios. Por ello, la verificación debe abarcar tanto el plano de control como la experiencia de los usuarios.

En el plano de control, los operadores deberían confirmar que desapareció el /32 no autorizado, que el /24 volvió a propagarse por caminos esperados y que no quedaron variantes equivalentes. En el plano de datos, deberían comprobar alcance, latencia y comportamiento del resolvedor desde varias redes.

La hora de resolución completa comunicada por Cloudflare para la fuga /24, las 02:28 UTC del 28 de junio, proporciona un hito. No prueba por sí sola que cada red mundial hubiera convergido exactamente en ese instante. Una conclusión sólida distingue entre la declaración del operador, las observaciones de colectores y las mediciones de servicio.

La recuperación también exige retirar cambios temporales. Una lista de bloqueo urgente, una excepción de política o una comunidad añadida durante el incidente pueden convertirse en riesgo permanente si no tienen propietario, vencimiento y comprobación posterior.

Matriz de responsabilidad operativa

Función Control práctico Evidencia esperable Límite de la atribución pública
Red que originó el /32 Configuración de origen, autorización de prefijo, filtro de salida Cambios, políticas, anuncios y retiradas No se prueba intención maliciosa
Red que filtró el /24 Política de exportación y clasificación de vecinos Sesión, rol, ruta aprendida y regla de exportación Un origen válido no prueba un camino válido
Proveedor de cliente Filtros de prefijo, longitud y origen Lista autorizada, estado RPKI y registro de aceptación La relación contractual no es pública
AS1031 y demás propagadores observados Importación, exportación y política de relación Adj-RIB, configuración, roles y cambios Aparecer en el camino no prueba por sí solo negligencia
Route server o tránsito Distribución y filtrado según su función Política de sesión, validaciones y registros Colectores públicos no muestran toda la configuración
Red de nivel uno que aceptó RTBH Autorización de cliente, prefijo, longitud, alcance y retirada Solicitud, comunidad, identidad, tiempo y ámbito La red no está identificada; no puede reconstruirse su sistema privado
Cloudflare Monitorización, coordinación, comunicación y recuperación Alertas, métricas, cronología y contactos No controla routers ajenos
Registro y RPKI Exactitud y disponibilidad de datos Asignación, ROA y estado de validación Los datos no ejecutan filtros
RouteViews y RIPE RIS Conservación de observaciones Rutas, tiempos y vistas de colectores No autorizan rutas ni prueban todo el forwarding

La matriz evita presentar la responsabilidad como una propiedad única. Cada actor responde por el control que podía ejercer y por la evidencia que debería conservar. Una conclusión más grave —por ejemplo, responsabilidad legal o encubrimiento— necesitaría un expediente diferente y fuentes que aquí no existen.