Resumen

  • La cadena pública del incidente apunta a una fuga de rutas BGP en la que Google anunció a Verizon rutas aprendidas de pares, Verizon las aceptó y las propagó, y prefijos más específicos atrajeron tráfico hacia rutas que no debían funcionar como tránsito para esos destinos.
  • La responsabilidad técnica no se agota en decir que Google corrigió una configuración en ocho minutos: Internet Society habló de una fuga de menos de diez minutos, NTT Communications registró inestabilidad de OCN entre las 12:22 y las 12:45 hora de Japón, y KDDI informó una ventana más larga para algunos usuarios, con recuperación hasta las 16:47.

El 25 de agosto de 2017 debe leerse como un incidente acotado de enrutamiento interdominio. No describe todos los fallos de Google, no se mezcla con otros episodios posteriores de MainOne, Google Cloud o Meta, y no autoriza una conclusión universal sobre todo el Internet japonés.

La frontera factual importante es más estrecha y más útil: Google exportó a Verizon un conjunto grande de rutas que había aprendido de relaciones de peering; Verizon aceptó esas rutas y las redistribuyó; algunas rutas eran más específicas que alternativas legítimas; el algoritmo de selección por prefijo más largo hizo que parte del tráfico prefiriera esas rutas; y operadores japoneses observaron degradación de alcanzabilidad que duró más que la corrección inicial del origen de la fuga.

Esa cadena importa porque BGP no obedece una intención comercial abstracta. Obedece anuncios, atributos, filtros, sesiones y decisiones de selección implementadas en routers. Si un sistema de rutas anuncia a un vecino rutas que no debe exportar, y ese vecino las acepta y las propaga como si fueran utilizables, el daño no depende de que alguien haya querido secuestrar tráfico. Tampoco depende de que una base de datos de recursos numéricos contenga información falsa. La realidad operacional se expresa en la ruta que entra, se selecciona, se instala y se vuelve a anunciar.

Por eso el incidente es una prueba de responsabilidad sobre controles: filtros de exportación en Google, filtros de importación y exportación en Verizon, límites de prefijos, alarmas de rutas anómalas, monitoreo de propagación, autoridad de reversión, evidencia de retiro y comunicación con clientes afectados.

La secuencia pública empieza con Google. Internet Society describió el evento como una fuga accidental de prefijos aprendidos de pares, una conducta que hizo que Google actuara funcionalmente como tránsito para rutas que no debía transportar. En términos de política BGP, esa distinción es central: una red puede intercambiar tráfico con un par para sus propios clientes y prefijos, pero no por eso debe transportar y anunciar al resto de Internet rutas aprendidas de otros pares. Cuando esa frontera se rompe, la relación de interconexión deja de estar reflejada en las tablas de rutas que ven terceros.

La etiqueta “peer” o “transit” solo protege si se traduce en filtros ejecutables.

Los recuentos públicos de prefijos deben mantenerse separados. El paquete de fuentes permite tratar como existentes recuentos en torno a 135.000, 160.000 y otras cifras, pero no permite convertirlos en una sola cifra universal. La razón no es semántica; es metodológica. Un análisis puede contar rutas recibidas por un colector, otro puede contar prefijos filtrados después de una condición de visibilidad, otro puede contar anuncios propagados a determinados pares, y otro puede estimar rutas afectadas a partir de tablas observadas.

Doug Madory, en CircleID, aporta una reconstrucción técnica con recuento de prefijos, rutas y trayectorias visibles desde su punto de medición. Internet Society ofrece una lectura de evento y de controles comunitarios. Los informes periodísticos y técnicos japoneses conservan otros recortes de impacto y tiempo. La cifra correcta para una frase depende de qué se está midiendo: rutas anunciadas por Google a Verizon, rutas que Verizon propagó, rutas más específicas que atrajeron tráfico, rutas vistas por colectores públicos o servicios observados como degradados en Japón.

Esa distinción protege contra una simplificación frecuente. Decir “Google filtró 160.000 rutas” puede ser adecuado si se atribuye al análisis que usa esa medida y si se aclara que no equivale a “160.000 destinos japoneses cayeron”. Decir “unas 135.000 rutas fueron visibles en una reconstrucción técnica” puede ser útil si no se presenta como inventario completo de todas las sesiones privadas. Un colector de rutas no ve la totalidad de Internet. Ve lo que sus peers le entregan, en el momento y con las políticas de esos peers. La ausencia de una ruta en RouteViews, BGPStream u otra fuente pública no prueba que nadie la recibiera.

La presencia de una ruta tampoco prueba que todos los routers del mundo la instalaran ni que todos los paquetes de una aplicación fallaran. La cuenta pública es evidencia de propagación, no omnisciencia.

El segundo paso de la cadena es Verizon. Las fuentes públicas describen que Google anunció rutas a Verizon y que Verizon las aceptó y las propagó hacia otros vecinos. Esa es una frontera de control independiente. Un operador que recibe rutas de un vecino no está condenado a aceptarlo todo. Puede aplicar filtros por relación, listas de prefijos, límites máximos, controles de IRR, validación de origen cuando exista material RPKI, alarmas por volumen inusual y reglas que bloqueen exportación entre pares cuando la relación no lo permite.

Que la fuga se haya originado en Google no elimina la pregunta sobre por qué el borde de Verizon dejó pasar y amplificar anuncios que no debían convertirse en tránsito global.

No hace falta inferir contratos privados para sostener esa pregunta. La ruta pública visible basta para formular una responsabilidad técnica: si una red recibe rutas desde un vecino y luego las propaga, sus controles de importación y exportación son parte de la cadena causal. Lo que no puede inferirse desde la visibilidad pública son comandos exactos de router, preferencia local, actas de cambio, acuerdos comerciales o intención. Un análisis serio debe detenerse en ese límite. La evidencia pública permite examinar la frontera de filtrado; no permite reconstruir el NOC de cada operador.

El tercer elemento es la especificidad de prefijos. BGP selecciona rutas usando un conjunto de reglas, pero el enrutamiento IP conserva un principio previo y decisivo: el prefijo más específico gana para un destino dentro de su rango. Si una ruta legítima a un bloque amplio existe, pero aparece una ruta más específica para una porción de ese bloque, el tráfico hacia esa porción puede moverse hacia la ruta más específica incluso si el origen general de la red sigue siendo reconocible. Ese fue el mecanismo que convirtió una fuga de política en un problema de alcanzabilidad.

Los análisis del evento indican que anuncios de rutas más específicas atrajeron tráfico hacia Google. Si Google no actuaba como tránsito válido para esos destinos, el resultado previsible era pérdida, desvío improductivo o degradación.

Esta parte del incidente muestra por qué los registros de recursos son necesarios pero insuficientes. Un registro ASN, un registro de prefijo, un objeto ROA o una base IRR puede ayudar a identificar quién debería originar un recurso y qué autorizaciones se han publicado. Ese registro crea una pista de auditoría y permite controles automáticos. Pero no obliga por sí mismo a un router a respetar la relación entre dos AS. Una ruta puede preservar el origen legítimo y aun así violar el alcance de exportación entre vecinos.

Route Origin Validation, definida para comparar el origen de una ruta contra una autorización publicada, tiene valor cuando la pregunta es si el AS originador está autorizado. En una fuga de rutas, la pregunta puede ser distinta: si una ruta aprendida por una relación fue exportada a otra relación donde no debía circular. ROV por sí sola no resuelve esa política de relación.

Esto no resta importancia a RPKI. La coloca en su sitio. Un stack de seguridad de rutas necesita datos autorizativos exactos, validación de origen cuando existan ROA, filtros de prefijos y relación, límites de volumen y observabilidad. Pero afirmar que RPKI habría detenido necesariamente el incidente de 2017 sería más fuerte que la evidencia. También sería una mala lección: el problema no era solo “quién origina el prefijo”, sino qué vecino puede transportar qué ruta hacia qué otro vecino.

Los controles posteriores como BGP Roles, Only-to-Customer, ASPA, Peerlock, políticas explícitas de rechazo por defecto y los compromisos MANRS ayudan a expresar o verificar relación, pero deben presentarse como comparaciones posteriores y no como obligaciones retroactivas que demuestren incumplimiento legal en 2017.

El reloj del incidente también debe separarse. Internet Watch recogió la disculpa contemporánea de Google y la afirmación de que el error de configuración fue corregido en ocho minutos. Internet Society describió la fuga como un evento de menos de diez minutos. Esas afirmaciones se refieren al control inicial y a la duración estrecha de la fuga. No equivalen a decir que todos los clientes afectados recuperaron la experiencia normal en ocho o diez minutos. En BGP, retirar una ruta no borra instantáneamente sus efectos.

Los anuncios deben retirarse, los vecinos deben procesar cambios, las rutas alternativas deben volver a seleccionarse, las tablas deben converger, los sistemas de acceso deben estabilizarse y las aplicaciones de usuarios pueden necesitar sus propios ciclos de recuperación.

NTT Communications ofrece una ventana japonesa concreta. Su aviso dijo que grandes cambios de rutas en Internet hicieron inestable la conectividad de OCN y que su propio equipamiento OCN no presentaba anomalía. La ventana registrada para esa inestabilidad fue de 12:22 a 12:45, hora de Japón. Esa ventana es más larga que la corrección de configuración de ocho minutos atribuida por Google y conservada por Internet Watch. La diferencia no contradice la corrección inicial; muestra que hay varias capas de tiempo. Un cambio de configuración puede cerrarse antes de que todos los efectos visibles en clientes desaparezcan.

KDDI da otro límite, también acotado. Su aviso registró inestabilidad para algunos clientes de acceso a Internet y una recuperación posterior que llegó hasta las 16:47 para algunos usuarios. Esa hora no debe usarse para decir que toda Japón estuvo caída durante horas. Debe usarse para explicar que la cola de recuperación percibida por clientes puede ser mucho más larga que el primer reloj de control BGP. Distintos operadores observan impactos distintos porque sus rutas, clientes, políticas, dependencias y procesos de estabilización no son idénticos.

La responsabilidad técnica necesita esa granularidad: quién pudo prevenir, quién pudo detectar, quién pudo mitigar, quién pudo comunicar, y en qué intervalo.

La cobertura japonesa y los informes secundarios nombraron servicios y empresas afectadas, pero la evidencia pública no enumera todos los clientes, pérdidas o paquetes descartados. Por eso una formulación adecuada habla de “efectos sustanciales de alcanzabilidad en redes japonesas” y de “usuarios o servicios afectados según avisos y reportes”, no de un corte universal de Internet en Japón.

El título periodístico de que Japón quedó “fuera de Internet” puede capturar la gravedad percibida, pero un análisis de responsabilidad debe traducirlo a hechos verificables: prefijos anunciados, rutas propagadas, más específicos preferidos, ventanas de operador y límites de medición.

La cadena causal queda entonces en cinco pasos. Primero, Google creó o exportó anuncios de rutas inesperados. Segundo, Verizon aceptó y propagó rutas que no debían salir por esa relación. Tercero, prefijos más específicos atrajeron tráfico que antes seguiría rutas menos específicas y más apropiadas. Cuarto, Google no era tránsito efectivo para esos destinos, de modo que parte del tráfico se perdió o no alcanzó su servicio esperado. Quinto, la retirada de rutas y la convergencia devolvieron el estado interdominio a una condición útil, mientras operadores y clientes atravesaron colas de recuperación propias.

No hay que añadir intención maliciosa para que la cadena sea grave. De hecho, añadirla sin evidencia debilitaría el análisis. El problema de accountability es que el sistema de interconexión depende de que redes grandes no exporten accidentalmente rutas aprendidas de pares y de que redes de tránsito no acepten y redistribuyan anomalías evidentes. Ese deber no nace solo de una norma jurídica externa. Nace de la arquitectura operacional: cada AS que participa en BGP puede convertirse, si sus filtros fallan, en un amplificador de estados de ruta falsos o impropios.

La magnitud de Google y Verizon hizo que un intervalo corto tuviera consecuencias visibles lejos del punto de configuración.

La observabilidad pública fue indispensable, pero parcial. RouteViews y BGPStream permiten reconstruir anuncios visibles desde colectores participantes. CAIDA describe BGPStream como una plataforma para acceder a datos públicos de rutas, y RouteViews mantiene colectores que preservan vistas históricas. Esos sistemas permiten comparar AS paths, observar anuncios más específicos, ubicar ventanas temporales y corroborar que un cambio no fue puramente local. Sin ellos, el análisis dependería casi por completo de comunicados corporativos. Con ellos, se puede verificar parte de la propagación.

Pero su poder se detiene donde no hay sesión de colector, donde una red rechazó la ruta, donde una política privada no se publica o donde el tráfico de datos no se corresponde directamente con el plano de control observado.

Por eso los colectores deben ser tratados como evidencia, no como árbitros absolutos. Una ruta visible en un colector demuestra que al menos una trayectoria llegó a una vista pública. No demuestra que todos los peers de Verizon la aceptaran. Un AS path observado ayuda a inferir propagación, pero no revela la preferencia local, las comunidades BGP internas, las rutas instaladas en FIB o las reglas de negocio. Un traceroute puede mostrar una ruta de datos en un momento, pero no reconstruye por sí solo toda la política.

La responsabilidad razonable combina fuentes: anuncios BGP, avisos de operadores, reportes técnicos, estándares de operación y declaraciones contemporáneas de corrección.

Los estándares técnicos ofrecen el lenguaje para esa combinación. RFC 4271 define fundamentos de BGP: anuncios, atributos, selección y propagación entre sistemas autónomos. RFC 7908 clasifica route leaks como violaciones de expectativa de exportación entre relaciones, lo que encaja con el núcleo del incidente sin requerir una acusación de secuestro intencional. RFC 7454 reúne prácticas operacionales de filtrado, seguridad de sesiones y controles como max-prefix. RFC 8212, posterior como referencia de comparación, empuja a una postura de eBGP donde no haya importación o exportación sin política explícita.

RFC 9234, también posterior, formaliza BGP Roles y Only-to-Customer como señales para reducir fugas de relación. RFC 6811 y RFC 6482 delimitan ROV y ROA: autorización de origen, no gobierno completo del camino.

La conclusión de este primer nivel es directa: el incidente no fue solo “un error de Google” ni “una falla inevitable de BGP”. Fue un evento de política distribuida. La corrección de Google fue necesaria, pero no suficiente para explicar la duración percibida por usuarios. La aceptación y propagación por Verizon fue una frontera decisiva, pero la evidencia pública no permite afirmar que todos sus vecinos se comportaran igual. Los operadores japoneses aportaron ventanas de impacto, pero no un mapa completo de daños. Los registros y RPKI ayudan a auditar recursos, pero no reemplazan filtros de relación.

Los colectores permitieron ver parte del plano de control, pero no la totalidad de rutas privadas ni pérdidas de tráfico.