La fuga de ruta de Google de 2018 mostró el desajuste entre los contratos de enrutamiento y el control real

Resumen

• El 12 de noviembre de 2018, rutas asociadas a servicios de Google fueron filtradas por el proveedor nigeriano MainOne hacia China Telecom y luego se propagaron a través de otros proveedores, enviando parte del tráfico destinado a Google por caminos inesperados y haciendo que los servicios no estuvieran disponibles para algunos usuarios.
• El incidente es distinto del secuestro de YouTube de Pakistan Telecom en 2008. Aquí, el problema crítico de rendición de cuentas no fue un bloque nacional exportado como una ruta más específica de origen incorrecto; fue un desajuste de contrato y control en el que las rutas aprendidas a través de una relación se escaparon hacia otras.
• El registro público respalda una configuración incorrecta accidental, no la prueba de un compromiso de contenido exitoso. Google informó que el tráfico afectado estaba cifrado y no tenía razones para creer que los servicios se habían comprometido, mientras que observadores independientes trataron la ruta como un riesgo grave de disponibilidad y vigilancia.
• La validación de origen RPKI no es una respuesta completa para esta clase de fallo porque las rutas afectadas aún podrían aparecer como originadas desde el AS legítimo de Google. Las fugas de ruta requieren filtrado de clientes y pares, controles conscientes de la relación, límites de prefijos, monitoreo, coordinación y mecanismos posteriores como Roles BGP.
• La lección de rendición de cuentas es que los contratos de interconexión y tránsito comerciales no se aplican por sí mismos. Los operadores deben convertir las relaciones comerciales en políticas de enrutador y controles verificables externamente antes de que una ruta filtrada se convierta en una interrupción global.

Registro de evidencia y cómo se utiliza

Este artículo trata el registro público como evidencia en capas. Los informes de incidentes, estándares, mediciones de navegador o enrutamiento, materiales de reguladores o políticas, y las guías actuales de operadores se utilizan para diferentes afirmaciones. Las fuentes de la empresa se atribuyen como posiciones de la empresa. Los estándares y las guías posteriores se utilizan para explicar los controles y presentar expectativas de rendición de cuentas, no para inventar hechos privados o imponer retroactivamente obligaciones posteriores donde el registro público no respalda esa afirmación.

El incidente trataba sobre límites que los routers no podían inferir

La fuga de ruta de Google de 2018 es fácil de reducir a una frase conocida: BGP es frágil. Esa frase es cierta pero no lo suficientemente precisa. La lección más precisa es que Internet contiene muchas relaciones comerciales que el software de enrutamiento no puede inferir a menos que los operadores las codifiquen. Un par puede enviar rutas que deberían permanecer locales. Un proveedor de tránsito puede recibir rutas que nunca deberían aceptarse de ese vecino. Una ruta puede conservar el AS de origen correcto mientras viaja a través de una ruta que viola las expectativas comerciales y operativas.

Los análisis de Cloudflare, ThousandEyes e Internet Society convergen en la forma central. MainOne tenía conectividad con Google a través de una relación de interconexión en Lagos. Las rutas asociadas a Google escaparon de esa relación hacia China Telecom. China Telecom las propagó y aparecieron rutas que involucraban a TransTelecom, NTT y otras redes. Los usuarios que intentaban acceder a los servicios de Google siguieron rutas que no tenían la capacidad, política o filtrado esperado para transportar ese tráfico. Parte del tráfico se descartó y los servicios no estuvieron disponibles para algunos usuarios.

Ese no es el mismo mecanismo que el secuestro de YouTube de Pakistan Telecom. En 2008, Pakistan Telecom originó una ruta más específica para el espacio de direcciones de YouTube desde un AS de origen incorrecto, y PCCW la propagó. En 2018, los análisis públicos importantes describen una fuga de ruta donde las rutas originadas por Google se propagaron más allá de la relación prevista. El origen podría parecer legítimo mientras la ruta seguía siendo incorrecta. Esta distinción es importante porque cambia los controles que habrían ayudado. La validación de origen puede rechazar un origen falso.

Por sí sola no puede demostrar que una ruta de origen correcto haya cruzado únicamente relaciones comerciales válidas.

El desajuste contrato-control es el centro del problema de gobernanza. Un contrato de interconexión puede decir que una parte debe intercambiar solo ciertas rutas o no debe proporcionar tránsito. Un acuerdo de tránsito puede definir conos de cliente y reglas de exportación. Pero un router remoto reenviará en función de las rutas que recibe y la política que está configurado para aplicar. Si la política falta, está desactualizada o es demasiado permisiva, el límite legal o comercial se vuelve decorativo. El paquete sigue el plano de control, no el PDF del contrato.

Por eso el evento pertenece a la gobernanza. El fallo no fue un desastre natural misterioso. Fue un desajuste entre la configuración técnica, la relación comercial, la autoridad de ruta, el monitoreo y la escalada. Cada organización en la ruta tenía una visión operativa más estrecha que el efecto global. MainOne pudo configurar mal la exportación. China Telecom pudo aceptar y propagar. Otros proveedores pudieron preferir o transmitir las rutas. Google pudo detectar, comunicar y proteger la confidencialidad de la capa de servicio, pero no pudo reescribir directamente todas las políticas de importación externas.

El origen correcto no significó la ruta correcta

Muchas discusiones sobre seguridad de enrutamiento comienzan con secuestros porque los anuncios de origen incorrecto son más fáciles de explicar. Alguien que no posee un prefijo dice, en efecto, envíenme ese tráfico. La validación de origen de ruta RPKI está diseñada para abordar esa clase: el titular del recurso publica una Autorización de Origen de Ruta (ROA), y las redes validadoras pueden rechazar rutas cuyo AS de origen o longitud de prefijo no coincida. Ese control es importante. El evento de Google de 2018 muestra su límite.

Internet Society lo dejó claro en su análisis público: en este escenario, los prefijos todavía se originaban legítimamente desde el AS correcto, por lo que es difícil que las redes intermedias bloqueen la fuga utilizando únicamente la validación de origen. La ruta podría tener un origen válido y aún así representar una relación de exportación inválida. Por eso una fuga de ruta no es simplemente un secuestro con un lenguaje más suave. Es un fallo de relación: las rutas se propagan más allá de su alcance previsto.

El efecto práctico puede ser igualmente grave para los usuarios. Una ruta de origen correcto que viaja a través del proveedor equivocado puede llevar tráfico a una red con capacidad insuficiente, filtrado restrictivo, problemas de vigilancia o mala accesibilidad. Los usuarios ven tiempos de espera. Los clientes ven servicios en la nube rotos. Los equipos de incidentes ven traceroutes extraños a través de países y proveedores que no esperaban. El origen correcto no los tranquiliza si la ruta descarta paquetes o viola sus suposiciones de riesgo.

Esta distinción debería cambiar las adquisiciones y la supervisión del consejo. Preguntar si un proveedor tiene RPKI es útil pero incompleto. Los compradores también deberían preguntar si el proveedor filtra las rutas de los clientes, rechaza rutas inconsistentes con las relaciones comerciales, mantiene límites de prefijos, monitorea fugas, participa en canales de coordinación y puede explicar cómo se evita que las rutas de interconexión se conviertan en rutas de tránsito. Una respuesta sí/no sobre la cobertura de RPKI no puede sustituir un control de ruta consciente de la relación.

Trabajos técnicos posteriores como Roles BGP y el atributo Solo-para-Cliente intentan hacer visibles las relaciones comerciales para el protocolo de enrutamiento. Estos mecanismos no eran un control universal terminado en 2018, y el artículo no los aplica retroactivamente como un estándar obligatorio. Su relevancia es explicativa: existen porque los operadores reconocieron que muchas fugas dañinas son fallos de política de ruta en lugar de fallos de autorización de origen. La industria necesitaba formas de hacer que "esta ruta no debería ir por allí" fuera verificable por máquina.

China Telecom fue el amplificador de propagación

MainOne aparece en el registro público como la fuente de la fuga, pero el evento se volvió globalmente significativo porque otros proveedores aceptaron y propagaron las rutas. China Telecom es central en los relatos públicos porque recibió las rutas filtradas de Google y las transmitió. Ese rol debe describirse con cuidado. Las fuentes públicas respaldan un manejo accidental o erróneo de las rutas; no prueban una operación exitosa de intercepción de tráfico. Pero la intención no es necesaria para la rendición de cuentas. Un proveedor de tránsito puede causar un daño importante al creer una ruta de cliente o par que debería haber filtrado.

Un proveedor con alcance global tiene una obligación de alto apalancamiento de saber qué rutas está autorizado a anunciar un vecino y qué rutas deben exportarse. Esto no significa que cada decisión de ruta sea simple. Los conos de cliente cambian, los pares tienen acuerdos complejos, los intercambios de Internet transportan rutas diversas y los datos de los registros pueden ser desordenados. Sin embargo, el deber básico permanece: un proveedor importante no debería tratar cada ruta inesperada como globalmente exportable simplemente porque la sintaxis BGP es válida.

El filtrado también debe coincidir con la relación. Una ruta de par no debería convertirse en una ruta de tránsito a menos que la relación lo permita explícitamente. Un cliente no debería poder anunciar las rutas de una gran plataforma en la nube a menos que ese cliente esté proporcionando legítimamente tránsito para esa plataforma. Un proveedor debería aplicar filtros de prefijos y AS-path, límites de prefijos máximos, generación de política de ruta a partir de datos confiables, monitoreo de cambios repentinos en conjuntos de rutas grandes y escalada fuera de banda para anuncios anómalos de prefijos famosos.

La visibilidad pública de la ruta hizo difícil ignorar el rol de propagación. ThousandEyes describió rutas a través de China Telecom y TransTelecom. Cloudflare registró enrutamiento inusual e impacto en el servicio. Los reportajes se centraron en el tráfico que pasaba por China y Rusia porque esa ruta conllevaba preocupaciones políticas y de vigilancia obvias. Incluso si el tráfico estaba cifrado y no se demostró que estuviera comprometido, la ruta en sí misma socavó las expectativas de los clientes sobre dónde viajaría el tráfico y si seguiría siendo accesible.

Este es el punto político: un proveedor que exporta una ruta filtrada convierte el error de otra red en un evento global. La configuración incorrecta original importa, pero la propagación determina el radio de explosión. La rendición de cuentas del enrutamiento debería, por lo tanto, medir la primera exportación incorrecta y cada punto de amplificación importante.

Google tenía deberes de resiliencia pero no control unilateral

Google era el operador del servicio afectado y una de las partes con mayor capacidad para detectar que algo extraño estaba sucediendo con el tráfico destinado a Google. También controlaba las protecciones de la capa de aplicación que importaban. Los reportajes públicos indican que Google declaró que el tráfico afectado estaba cifrado y que no había razón para creer que los servicios se hubieran comprometido. Esa distinción importa. El cifrado puede reducir el riesgo de confidencialidad incluso cuando el enrutamiento toma un mal camino.

No resuelve el riesgo de disponibilidad, pero evita que la fuga de ruta se convierta automáticamente en un evento comprobado de exposición de datos.

Los deberes de Google en tal evento incluyen monitoreo de rutas, publicación de ROA, objetos IRR precisos, escalada a proveedores, comunicación con clientes, ingeniería de tráfico de emergencia y evidencia posterior al evento. Una plataforma del tamaño de Google no puede detener cada fuga externa, pero puede reducir el tiempo de detección y reparación. También puede diseñar servicios para que un desvío de ruta no exponga silenciosamente el contenido del usuario. El cifrado, la higiene de certificados, la redundancia de servicios y la telemetría de red son parte de ese paquete de resiliencia.

Al mismo tiempo, Google no podía obligar unilateralmente a MainOne o China Telecom a aplicar la política de importación y exportación correcta. Esta es la razón por la cual la rendición de cuentas de seguridad de enrutamiento debe seguir la capacidad de control en lugar de la visibilidad de la marca. Los usuarios experimentaron síntomas de interrupción de Google, y la marca de Google soportó el golpe de confianza público. Pero la política de enrutador que aceptó y exportó las rutas filtradas estaba fuera de la red de Google.

La cuestión de gobernanza es cómo los contratos, acuerdos de interconexión y manuales de escalada de Google abordaron esa dependencia externa antes del evento.

Un registro público más sólido de las plataformas afectadas incluiría el tiempo de detección, el número de prefijos afectados, el impacto para el cliente, los cambios de ruta observados, la evaluación del cifrado y la confidencialidad, los proveedores contactados, la marca de tiempo de reparación y cualquier cambio en el monitoreo de rutas o requisitos de socios después del incidente. Parte de esa evidencia puede ser sensible durante un evento en vivo, pero los resúmenes posteriores al evento pueden compartir categorías sin exponer secretos defensivos.

Para los clientes, la lección no es culpar a Google por cada ruta externa. Es preguntar a los grandes proveedores de nube y plataformas cómo monitorean la accesibilidad global, qué rutas están autorizadas, qué tan rápido detectan rutas sospechosas y qué compromisos asumen cuando un fallo de enrutamiento de un tercero hace que los servicios no estén disponibles. La disponibilidad no termina en el borde del proveedor.

Los contratos necesitan controles ejecutables

La frase «desajuste contrato-control» captura un patrón de fallo que aparece en toda la infraestructura de Internet. Las partes pueden tener contratos que definen quién es par, cliente o proveedor. Pero los routers aplican política de ruta, no intención legal. Si la política de ruta no refleja la relación, el contrato se convierte en un argumento a posteriori en lugar de un control preventivo. La fuga de Google de 2018 hizo visible esa brecha para los usuarios comunes porque el cambio de ruta interrumpió servicios altamente visibles.

Los controles ejecutables incluyen filtros de prefijos construidos a partir de conjuntos de rutas autorizados por el cliente, filtros de AS-path, límites de rutas, políticas de sesiones de pares, validación de origen RPKI, detección de fugas de ruta, alertas para exportaciones repentinas de prefijos famosos y contactos de emergencia probados. También incluyen controles de gobernanza: revisión de cambios para política de exportación, reconciliación periódica de conjuntos de rutas, revisión del cono de cliente, simulacros de incidentes y autoridad documentada para cerrar rápidamente una sesión con fugas.

MANRS, NIST y las guías del IETF hacen que estos controles sean menos exóticos de lo que eran en épocas anteriores. El punto no es que todos los operadores puedan eliminar todas las fugas mañana. El punto es que el vocabulario de control existe. Un proveedor que vende accesibilidad global debería poder explicar cómo evita que una ruta de interconexión local se convierta en tránsito global y cómo detecta el fallo si la prevención falla.

Los consejos deberían pedir evidencia, no eslóganes. «Seguimos las mejores prácticas» no es suficiente. Un panel útil mostraría la política de validación RPKI, la cobertura de filtrado de clientes, la cobertura explícita de política de importación y exportación EBGP, eventos de prefijos máximos, excepciones de objetos de ruta obsoletos, alertas de fugas, tiempos de respuesta y anomalías no resueltas. Distinguiría el rechazo de origen inválido de los controles de fuga de ruta, porque son clases de riesgo diferentes.

La conclusión es que la fuga de ruta de Google de 2018 fue un evento de rendición de cuentas sobre la gobernabilidad de las relaciones. El error de MainOne importó. La propagación de China Telecom importó. La aceptación de otras redes importó. La resiliencia y comunicación de Google importaron. El público tuvo que experimentar un fallo de política de ruta como una interrupción del servicio. La lección de reparación no es solo una mejor higiene BGP en abstracto; es la conversión de contratos y expectativas en controles de ruta que fallan visiblemente y se recuperan rápidamente.

La ruta parecía política porque la ruta era operativamente incorrecta

La fuga de ruta de Google de 2018 atrajo la atención pública en parte porque el tráfico parecía pasar por China y Rusia. Esa geografía importaba a los usuarios y periodistas porque planteaba preocupaciones de vigilancia y soberanía. También ilustra una regla más general: cuando las rutas de enrutamiento violan las expectativas, el espacio de explicación se expande rápidamente. Los usuarios no saben si están viendo congestión, censura, secuestro, fuga accidental, vigilancia, ataque o un optimizador de enrutamiento defectuoso.

El registro del operador debe, por lo tanto, ser lo suficientemente preciso para separar el impacto en la disponibilidad del compromiso de confidencialidad y el accidente de la intención.

Los reportajes públicos conservaron la posición de Google de que el tráfico afectado estaba cifrado y que no había razón para creer que sus servicios se hubieran comprometido. Esa declaración fue importante. Redujo el riesgo de que un desvío de ruta se tratara automáticamente como una violación de contenido. Pero el cifrado no eliminó el problema de disponibilidad. Un usuario cuyo tráfico está cifrado pero descartado aún no puede acceder al servicio. Una empresa cuyo servicio de Google no está disponible aún enfrenta una interrupción operativa.

Una agencia pública cuya ruta ahora atraviesa una jurisdicción inesperada puede tener preocupaciones políticas incluso si se preserva la confidencialidad de la carga útil.

La ruta también expuso por qué los controles conscientes de la relación importan más que las etiquetas nacionales. El rol de China Telecom no fue problemático simplemente porque la red es china. Fue problemático porque la ruta aparentemente no debería haber sido aceptada y propagada en esa forma. Un gran proveedor diferente en un país diferente podría haber creado una interrupción similar si aceptaba una ruta aprendida de un par o filtrada por un cliente que violaba la política de ruta.

El estándar de rendición de cuentas debería, por lo tanto, centrarse en los filtros, la autoridad de ruta, la relación, el monitoreo y la evidencia de reparación, al tiempo que reconoce que la geografía puede amplificar la preocupación del usuario.

Esta distinción ayuda a evitar dos lecturas incorrectas. Una lectura incorrecta trata el evento como prueba de intercepción maliciosa sin evidencia. La otra lo trata como un accidente inofensivo porque no se demostró ningún compromiso de contenido. La lectura correcta está en el medio: una fuga de ruta puede ser accidental y aún así grave; el tráfico cifrado puede permanecer confidencial y aún así no estar disponible; un proveedor puede carecer de intención maliciosa y aún así fallar en un deber importante de filtrado. La gobernanza necesita ese vocabulario intermedio.

La óptica política también muestra por qué la comunicación pública oportuna es importante. En ausencia de una explicación del operador, los traceroutes y las rutas BGP se convierten en materia prima para la especulación. Las plataformas afectadas deberían comunicar lo que se sabe sobre la ruta, lo que se sabe sobre el cifrado, lo que sigue siendo desconocido, lo que se ha corregido y qué partes controlaban las políticas de ruta fallidas. Eso no es solo gestión de la reputación.

Es una forma de evitar que los usuarios confundan cualquier ruta extraña con una violación confirmada, mientras se sigue tratando la disponibilidad y la integridad del enrutamiento como riesgos reales.

La interconexión y el tránsito son relaciones comerciales con dientes técnicos

La interconexión (peering) y el tránsito a menudo se resumen como acuerdos comerciales: los pares intercambian tráfico en beneficio mutuo, mientras que los proveedores de tránsito venden accesibilidad a Internet en general. La fuga de Google muestra por qué esos términos necesitan dientes técnicos. Una ruta aprendida de un par no debería exportarse automáticamente como si fuera una ruta de cliente. Una ruta de cliente no debería creerse automáticamente como si el cliente estuviera autorizado a transportar una plataforma global. Una ruta aceptada bajo una relación debería tener restricciones de política cuando cruza otro límite.

Esa correspondencia debe implementarse en la configuración del enrutador y en los sistemas de validación. Incluye política de importación explícita para lo que un vecino puede enviar, política de exportación explícita para dónde pueden ir esas rutas, filtros de prefijos y AS-path, límites de rutas, validación de origen RPKI cuando corresponda, etiquetas de relación, monitoreo de expansión repentina del conjunto de rutas y autoridad de cierre de emergencia. La palabra importante es explícito.

Los valores predeterminados, las suposiciones y el conocimiento tribal no son suficientes cuando un error de configuración puede hacer que Google no esté disponible.

El principio de rechazo predeterminado de RFC 8212 refleja la misma filosofía: las sesiones BGP externas no deberían importar ni exportar rutas sin una política explícita. Eso no evita todos los errores. Una política equivocada explícita aún puede filtrar rutas. Pero elimina la suposición más peligrosa de que una sesión no configurada o mal configurada debería propagar por defecto. En lenguaje de gobernanza, el rechazo predeterminado obliga a los operadores a declarar su intención de enrutamiento antes de que el plano de control actúe.

Los contratos deberían seguir la misma lógica. Un acuerdo de interconexión o contrato de tránsito no solo debería decir lo que las partes pretenden; debería exigir evidencia de que la intención se aplica. ¿Cada parte mantiene filtros de ruta? ¿Cómo se generan los conjuntos de prefijos de los clientes? ¿Con qué frecuencia se revisan? ¿Qué sucede cuando un vecino filtra prefijos famosos? ¿Quién tiene autoridad para cerrar una sesión? ¿Qué notificación pública o al cliente sigue? Estas cláusulas no son un exceso legal exótico. Son la traducción del daño de enrutamiento en obligaciones operativas.

Los clientes deberían preocuparse incluso cuando no son operadores de red. Un comprador de SaaS, banco, editorial o agencia gubernamental puede depender de un proveedor cuya accesibilidad depende de relaciones de tránsito. El comprador no puede auditar todas las rutas globales, pero puede preguntar a sus proveedores críticos cómo monitorean la accesibilidad, cómo usan RPKI, cómo se protegen contra fugas de ruta y cómo notifican a los clientes cuando un fallo de ruta externo afecta el servicio.

Un acuerdo de nivel de servicio que excluye «problemas de enrutamiento de Internet» puede describir una asignación legal, pero no hace desaparecer la dependencia operativa.

Por qué la validación de origen seguía perteneciendo a la discusión

Debido a que el evento de Google de 2018 fue una fuga de ruta en lugar de un secuestro simple de origen incorrecto, algunos lectores pueden concluir que RPKI es irrelevante. Esa sería la lección equivocada. La validación de origen RPKI no fue un control completo para la fuga, pero aún pertenece a la pila de rendición de cuentas. Ayuda a distinguir una clase de autoridad falsa de otra, reduce el nivel de fondo de rutas incorrectas y brinda a los operadores evidencia legible por máquina para muchos incidentes que de otro modo dependerían de la confianza manual.

La limitación es precisa. Si la ruta todavía se origina desde el AS autorizado de Google, el componente de origen puede validarse mientras la ruta sigue siendo inaceptable. En ese caso, RPKI dice que el origen está permitido, no que MainOne, China Telecom, TransTelecom, NTT o cualquier otro segmento de la ruta deba transportar la ruta en esa relación. La validación de ruta y la prevención de fugas de ruta requieren controles adicionales. Esa es la razón por la que RFC 9234 y los mecanismos conscientes de la relación son importantes. Abordan una parte diferente del problema de confianza.

La validación de origen también puede ayudar durante la respuesta a incidentes. Si una ruta sospechosa es de origen inválido, los operadores pueden rechazarla o escalarla como probablemente no autorizada. Si es de origen válido pero la ruta es sospechosa, pueden clasificar el incidente como una fuga o fallo de política de ruta. Esa clasificación afecta a quién llamar y qué evidencia inspeccionar. Una operación madura de seguridad de enrutamiento no pide a RPKI que responda todas las preguntas; usa RPKI para eliminar ambigüedades donde puede y luego aplica comprobaciones adicionales de política de ruta.

RPKI también cambia los incentivos en torno a la documentación. Una plataforma como Google debería mantener ROA precisos, pero también debería mantener objetos de ruta, políticas de pares, contactos de proveedores y monitoreo externo. Un proveedor como China Telecom debería validar orígenes pero también filtrar según la relación. Un par como MainOne debería evitar que las rutas aprendidas de pares se filtren al tránsito. Los controles se complementan en lugar de reemplazarse entre sí.

El lector debería, por lo tanto, llevarse un modelo en capas. RPKI maneja la autoridad de origen. Los filtros de prefijos y AS-path manejan la autoridad esperada del cliente y del par. Los Roles BGP y OTC pueden codificar la dirección de la relación. El monitoreo detecta desviaciones. La coordinación humana repara lo que la automatización no puede decidir de manera segura. El lenguaje contractual y las métricas de gobernanza mantienen las capas. El evento de Google expuso una brecha en ese modelo en capas, no la futilidad de construirlo.

Un mejor registro público de reparación habría separado cada punto de control

Un registro útil posterior al incidente para la fuga de 2018 identificaría cada punto de control en la ruta. En MainOne, el registro explicaría qué conjunto de rutas se aprendió de Google, qué política debería haber impedido la exportación, qué cambió, cuándo comenzó la fuga, cuándo se detectó y cómo se corrigió. En China Telecom, explicaría por qué se aceptó la ruta filtrada, si existían filtros de cliente o par, si se activaron los límites de ruta y cuándo se detuvo la exportación. En los proveedores posteriores, explicaría qué rutas se seleccionaron y por qué.

Para Google, el registro cubriría el impacto para el cliente, los servicios afectados, la evaluación del cifrado y compromiso, la línea de tiempo de detección, la escalada a proveedores, el monitoreo de rutas, cualquier ingeniería de tráfico de emergencia y los cambios posteriores al evento en los requisitos de interconexión. Para los observadores independientes, la evidencia del recolector de rutas podría mostrar la propagación y el retiro. Para los clientes, un resumen conciso podría distinguir la pérdida de disponibilidad de la evidencia de exposición de datos.

Esos registros separados permitirían que cada parte posea su superficie de control sin obligar a la declaración de un actor a explicar todo Internet.

El registro público está parcialmente disponible a través de análisis independientes, pero el registro interno de reparación sigue siendo escaso. Eso es común en incidentes de enrutamiento. Los operadores a menudo corrigen la ruta y siguen adelante. El problema es que los incidentes de enrutamiento son oportunidades de aprendizaje solo si el fallo de control se describe al nivel en el que se puede reparar. «Configuración incorrecta» no es suficiente. ¿Qué política? ¿Qué sesión? ¿Qué conjunto de rutas? ¿Qué relación de vecino? ¿Qué alerta? ¿Qué autoridad para retirar?

Sin esas respuestas, el mismo fallo puede repetirse con un prefijo diferente y una plataforma diferente.

Los reguladores y grandes compradores no deberían exigir que todos los operadores publiquen una configuración de enrutador sensible. Pueden requerir planes de seguridad de enrutamiento y categorías de evidencia. Por ejemplo: cobertura de filtrado de prefijos de clientes, política de validación RPKI, alertas de fugas de ruta, cobertura explícita de política EBGP, excepciones de prefijos máximos, tasas de éxito de contactos de emergencia y resúmenes posteriores a la acción. Esas métricas son lo suficientemente prácticas para auditar sin exponer cada línea del enrutador.

La fuga de Google de 2018 sigue siendo útil porque hace visible el desajuste contrato-control. No era suficiente que las relaciones comerciales implicaran que la ruta no debería viajar de esa manera. Los routers necesitaban una política ejecutable. El monitoreo necesitaba ver la desviación. Los humanos necesitaban contactos accesibles. El público necesitaba evidencia de que la fuga estaba contenida y que el cifrado limitaba el riesgo de confidencialidad. Esa es la pila de gobernanza que el incidente expuso.

La decisión del lector para los contratos de enrutamiento

Un lector debería salir de la fuga de ruta de Google de 2018 con una pregunta de adquisición y gobernanza: ¿nuestros proveedores críticos traducen las relaciones de enrutamiento en controles que podemos medir? A una fuga de ruta no le importa que un contrato etiquete a un vecino como par o cliente. Le importa si la política del enrutador evita la exportación incorrecta y si el monitoreo detecta la fuga cuando la política falla.

Los clientes deberían, por lo tanto, pedir a los proveedores evidencia de filtrado de prefijos de clientes, políticas explícitas de importación y exportación EBGP, validación RPKI, alertas de fugas de ruta y contactos de escalada 24/7.

Para las plataformas, la decisión es tratar el enrutamiento externo como parte de la resiliencia del servicio. Un proveedor puede poseer excelentes centros de datos, TLS sólido y aplicaciones endurecidas mientras se vuelve inaccesible si las redes remotas prefieren una ruta filtrada. Eso significa que el monitoreo global de rutas, los simulacros de escalada con proveedores, la higiene de ROA, la higiene de objetos de ruta y la comunicación con el cliente deben estar cerca de la ingeniería de disponibilidad ordinaria.

«Internet se rompió fuera de nuestro borde» puede ser descriptivamente cierto, pero los clientes aún necesitan evidencia de detección, diagnóstico y reparación.

Para los proveedores de tránsito, la decisión es si demostrar el filtrado antes de que una fuga de ruta famosa haga público el problema. No se debe permitir que una sesión de cliente o par se convierta en una ruta de tránsito sorpresa para Google, un banco, un servicio gubernamental o una CDN. El proveedor debe conocer los conjuntos de rutas esperados, rechazar anuncios poco plausibles, alertar sobre expansiones repentinas y mantener suficientes registros para explicar la reparación. El valor del alcance global conlleva el deber de no globalizar el error de otra parte.

Para los consejos y reguladores, la lección es exigir métricas de seguridad de enrutamiento de la misma manera que exigen métricas cibernéticas. La tasa de rechazo de inválidos RPKI, la cobertura de filtrado de clientes, la cobertura de política explícita, las alertas de fugas, los objetos de ruta obsoletos, los incidentes de prefijos máximos y el tiempo de respuesta de contacto son señales de gobernanza. No son secretos profundos de paquetes. Son evidencia de que los límites de relación tienen aplicación técnica.

El evento de 2018 sigue siendo útil porque se niega a encajar en un solo control. RPKI importa, pero la validación de origen por sí sola no fue suficiente. Los contratos importan, pero no se aplicaron solos. El cifrado importó, pero no restauró la accesibilidad. La reparación requirió toda la pila: política de ruta, monitoreo, coordinación, comunicación con el cliente y evidencia pública.

Una prueba operativa final es preguntar si la próxima fuga de ruta sería notada primero por los clientes, por investigadores externos o por las redes que la transportan. Si los usuarios externos son el detector principal, el sistema de contrato-control es demasiado débil. Los proveedores deberían poder ver cuándo un par de repente parece transportar una red de hiperescala, cuándo un cliente exporta un conjunto de rutas fuera de su autoridad y cuándo las rutas de tráfico contradicen las relaciones comerciales. Esa visibilidad convierte los contratos de enrutamiento de papeleo en infraestructura ejecutable.

La misma prueba pertenece a las adquisiciones de nube y proveedores de contenido. Un comprador puede no ejecutar BGP a escala global, pero puede preguntar si su proveedor monitorea fugas de ruta, valida orígenes, publica contactos de seguridad de enrutamiento, realiza simulacros de escalada con proveedores y puede explicar si el tráfico simplemente no estaba disponible o también estaba expuesto a riesgo de ruta. Esas respuestas no son trivialidades abstractas de la red. Dan forma a la continuidad de ingresos, el soporte al cliente, la garantía de privacidad y el acceso del sector público.

El incidente Google/MainOne es, por lo tanto, un recordatorio de que los propietarios de aplicaciones heredan cierta dependencia de enrutamiento, tengan o no sus equipos política de enrutador. La rendición de cuentas comienza cuando esa dependencia heredada se nombra, se mide y se asigna a un propietario de control en lugar de tratarse como el clima incognoscible de Internet.

Ese propietario también debería controlar el lenguaje utilizado durante una interrupción. Las fugas de ruta pueden sonar como trivialidades de operadores remotos, sin embargo, la pregunta del cliente es inmediata: ¿pueden los usuarios acceder al servicio?, ¿es confiable la ruta?, ¿qué cambió? y ¿cuándo volverá a la normalidad? Una nota de incidente sólida distingue la pérdida de accesibilidad, la ruta de tránsito inesperada, el estado del cifrado, el presunto compromiso y la remediación. El registro de Google muestra por qué esas distinciones importan.

La tranquilidad de que el tráfico estaba cifrado es importante, pero no responde a la pregunta de disponibilidad. Una retirada de ruta puede restaurar el servicio, pero no explica qué relación falló. Una buena comunicación mantiene esas superficies de control lo suficientemente separadas para que compradores, usuarios y operadores puedan aprender del evento.

La conclusión

El estándar de rendición de cuentas es el control práctico unido a la evidencia pública. El registro más sólido no pretende que todos los actores controlaron todos los resultados. Identifica quién pudo prevenir el fallo, quién pudo detectarlo, quién pudo limitar el radio de explosión, quién pudo notificar a las partes afectadas, quién pudo reparar la relación de confianza y qué evidencia demuestra que la reparación llegó a los sistemas y personas que dependían de ella.