La filtración de rutas de Google de 2018 mostró el desajuste entre los contratos de enrutamiento y el control real

Resumen

• El 12 de noviembre de 2018, las rutas asociadas a los servicios de Google fueron filtradas por el proveedor nigeriano MainOne hacia China Telecom y luego propagadas a través de otros proveedores, enviando parte del tráfico destinado a Google por trayectos inesperados y haciendo que los servicios fueran inaccesibles para algunos usuarios.
• El incidente es distinto del secuestro de YouTube por Pakistan Telecom en 2008. En este caso, el problema crítico de responsabilidad no fue un bloqueo nacional exportado como una ruta más específica con origen incorrecto; fue un desajuste de contratos y control en el que las rutas aprendidas a través de una relación escaparon a otras.
• El registro público respalda una mala configuración accidental en lugar de una prueba de un compromiso exitoso del contenido. Google informó que el tráfico afectado estaba cifrado y que no había motivos para creer que los servicios estuvieran comprometidos, mientras que observadores independientes consideraron el trayecto de enrutamiento como un grave riesgo de disponibilidad y vigilancia.
• La validación de origen RPKI no es una respuesta completa para esta clase de fallo porque las rutas afectadas todavía podían parecer originarse en el AS legítimo de Google. Las filtraciones de rutas requieren filtrado de clientes y pares, controles basados en la relación, límites de prefijos, monitorización, coordinación y mecanismos posteriores como BGP Roles.
• La lección de responsabilidad es que los contratos comerciales de peering y tránsito no se aplican solos. Los operadores deben convertir las relaciones comerciales en políticas de router 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 por capas. Los informes de incidentes, estándares, mediciones de navegación o enrutamiento, materiales regulatorios o de políticas y guías actuales de operadores se utilizan para diferentes afirmaciones. Las fuentes escritas por empresas 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 responsabilidad, no para inventar hechos privados o imponer retroactivamente obligaciones posteriores cuando el registro público no respalda esa afirmación.

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

La filtración de rutas 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 aguda 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 y aun así viajar por un trayecto que viola las expectativas comerciales y operativas.

Cloudflare, ThousandEyes e Internet Society coinciden en la forma central. MainOne tenía conectividad con Google a través de una relación de peering en Lagos. Las rutas asociadas con Google escaparon de esa relación hacia China Telecom. China Telecom las propagó más allá, y aparecieron trayectos que involucraban a TransTelecom, NTT y otras redes. Los usuarios que intentaban llegar a los servicios de Google siguieron entonces trayectos que no tenían la capacidad, las políticas o el filtrado esperados para transportar ese tráfico. Parte del tráfico se descartó y los servicios se volvieron inaccesibles para algunos usuarios.

Ese no es el mismo mecanismo que el secuestro de YouTube por 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 filtración de rutas en la que las rutas originadas por Google se propagaron más allá de la relación prevista. El origen podía parecer legítimo mientras que el trayecto seguía siendo incorrecto. Esta distinción importa porque cambia los controles que habrían ayudado. La validación de origen puede rechazar un origen falso.

No puede por sí sola demostrar que una ruta con origen correcto solo ha cruzado relaciones comerciales válidas.

El desajuste entre contrato y control está en el centro del problema de gobernanza. Un contrato de peering puede decir que una parte solo debe intercambiar ciertas rutas o no debe proporcionar tránsito. Un acuerdo de tránsito puede definir los conos de clientes y las reglas de exportación. Pero un router remoto reenviará basándose en las rutas que recibe y en la política que está configurado para aplicar. Si la política falta, está obsoleta 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 las rutas, la monitorización y la escalada. Cada organización en el trayecto tenía una visión operativa más reducida que el efecto global. MainOne pudo configurar mal la exportación. China Telecom pudo aceptar y propagar. Otros proveedores pudieron preferir o transmitir los trayectos. Google pudo detectar, comunicar y proteger la confidencialidad en la capa de servicio, pero no pudo reescribir directamente cada política de importación externa.

Un origen correcto no significaba una ruta correcta

Muchas discusiones sobre seguridad de enrutamiento comienzan con los secuestros porque los anuncios con 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 RPKI está diseñada para abordar esa clase: el titular del recurso publica una Autorización de Origen de Ruta, y las redes validadoras pueden rechazar las rutas cuyo AS de origen o longitud de prefijo no coincidan. Ese control es importante. El evento de Google de 2018 muestra sus límites.

Internet Society lo expresó claramente en su análisis público: en este escenario, los prefijos seguían originándose legítimamente desde el AS correcto, por lo que es difícil para las redes intermedias bloquear la filtración utilizando solo la validación de origen. La ruta podía tener un origen válido y aún representar una relación de exportación no válida. Por eso una filtración de rutas 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 ámbito previsto.

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

Esta distinción debería cambiar la supervisión de adquisiciones y de la junta directiva. 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, monitoriza las filtraciones, participa en canales de coordinación y puede explicar cómo se evita que las rutas de peering se conviertan en rutas de tránsito. Una respuesta de sí/no sobre la cobertura RPKI no puede sustituir un control de rutas basado en la relación.

El trabajo técnico posterior, como BGP Roles y el atributo Only-to-Customer, intenta hacer visibles las relaciones comerciales para el protocolo de enrutamiento. Esos mecanismos no eran un control universal terminado en 2018, y el artículo no los aplica retroactivamente como una norma obligatoria. Su relevancia es explicativa: existen porque los operadores reconocieron que muchas filtraciones dañinas son fallos de política de trayecto en lugar de fallos de autorización de origen. La industria necesitaba formas de hacer que "esta ruta no debería ir por ahí" fuera verificable por máquina.

China Telecom fue el amplificador de la propagación

MainOne aparece en el registro público como la fuente de la filtración, 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 papel debe describirse con cuidado. Las fuentes públicas respaldan un manejo accidental o equivocado de las rutas; no prueban una operación exitosa de interceptación de tráfico. Pero la intención no es necesaria para la responsabilidad.

Un proveedor de tránsito puede causar un gran daño al creer en 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 sencilla. Los conos de clientes cambian, los pares tienen acuerdos complejos, los puntos de intercambio de Internet transportan rutas diversas y los datos de registro pueden ser confusos. Sin embargo, el deber básico permanece: un proveedor importante no debe tratar cada ruta inesperada como globalmente exportable simplemente porque la sintaxis BGP sea válida.

El filtrado también debe coincidir con la relación. Una ruta de par no debe convertirse en una ruta de tránsito a menos que la relación lo permita explícitamente. Un cliente no debe 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 debe aplicar filtros de prefijos y de rutas AS, límites máximos de prefijos, generación de políticas de ruta a partir de datos confiables, monitorización de cambios repentinos en grandes conjuntos de rutas y escalada fuera de banda para anuncios anómalos de prefijos famosos.

La visibilidad pública del trayecto de la ruta hizo difícil ignorar el papel de propagación. ThousandEyes describió trayectos a través de China Telecom y TransTelecom. Cloudflare registró enrutamiento inusual e impacto en el servicio. Los informes de noticias se centraron en el tráfico que pasaba por China y Rusia porque ese trayecto 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 socavaba 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 mala configuración original importa, pero la propagación determina el radio de explosión. Por lo tanto, la responsabilidad del enrutamiento debe medir la primera mala exportación y cada punto importante de amplificación.

Google tenía deberes de resiliencia, pero no un control unilateral

Google era el operador de servicios 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 a nivel de aplicación que importaban. Los informes públicos indicaron que Google declaró que el tráfico afectado estaba cifrado y que no había motivos para creer que los servicios estuvieran comprometidos. 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 filtración de rutas se convierta automáticamente en un evento probado de exposición de datos.

Los deberes de Google en un evento de este tipo incluyen la monitorización de rutas, la publicación de ROA, objetos IRR precisos, escalada con 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 todas las filtraciones externas, 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 del servicio 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 correcta de importación y exportación. Por eso la responsabilidad de la seguridad del 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 sufrió el impacto de confianza de cara al público. Pero la política del router que aceptó y exportó las rutas filtradas estaba fuera de la red de Google.

La cuestión de gobernanza es cómo los contratos, los acuerdos de peering y los 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 en los clientes, los cambios de ruta observados, la evaluación del cifrado y la confidencialidad, los proveedores contactados, la hora de reparación y cualquier cambio en la monitorización de rutas o en los requisitos de los socios después del incidente. Parte de esa evidencia puede ser sensible durante un evento en directo, 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 monitorizan la accesibilidad global, qué rutas están autorizadas, con qué rapidez detectan trayectos sospechosos y qué compromisos asumen cuando un fallo de enrutamiento de terceros hace que los servicios sean inaccesibles. La disponibilidad no termina en el borde del proveedor.

Los contratos necesitan controles ejecutables

La frase desajuste entre contrato y 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íticas de ruta, no la intención legal. Si la política de ruta no encarna la relación, el contrato se convierte en un argumento a posteriori en lugar de un control preventivo. La filtración de Google de 2018 hizo visible esa brecha para los usuarios comunes porque el cambio de ruta rompió servicios altamente visibles.

Los controles ejecutables incluyen filtros de prefijos construidos a partir de conjuntos de rutas autorizadas por el cliente, filtros de rutas AS, límites de rutas, políticas de sesión de pares, validación de origen RPKI, detección de filtraciones de rutas, alertas para exportaciones repentinas de prefijos famosos y contactos de emergencia probados. También incluyen controles de gobernanza: revisión de cambios para la política de exportación, conciliación periódica de conjuntos de rutas, revisión de conos de clientes, simulacros de incidentes y autoridad documentada para cerrar rápidamente una sesión que esté filtrando.

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 cada operador pueda eliminar cada filtración 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 peering local se convierta en tránsito global y cómo detecta el fallo si la prevención se rompe.

Las juntas directivas 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 filtros de clientes, la cobertura explícita de políticas de importación y exportación EBGP, los eventos de prefijos máximos, las excepciones de objetos de ruta obsoletos, las alertas de filtración, los tiempos de respuesta y las anomalías no resueltas. Distinguiría el rechazo por origen no válido de los controles de filtración de rutas, porque son clases de riesgo diferentes.

La conclusión es que la filtración de rutas de Google de 2018 fue un evento de responsabilidad 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 fallen visiblemente y se recuperen rápidamente.

El trayecto parecía político porque era operativamente incorrecto

La filtración de rutas 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 los trayectos 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, filtración accidental, vigilancia, ataque o un optimizador de enrutamiento que salió mal.

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

Los informes públicos preservaron la posición de Google de que el tráfico afectado estaba cifrado y que no había motivos para creer que sus servicios hubieran sido comprometidos. Esa declaración fue importante. Redujo el riesgo de que un desvío de ruta fuera tratado 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 se descarta sigue sin poder acceder al servicio. Un negocio cuyo servicio de Google es inaccesible todavía enfrenta una interrupción operativa.

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

El trayecto también expuso por qué importan los controles basados en la relación más que las etiquetas nacionales. El papel 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 de esa forma. Un proveedor grande 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.

Por lo tanto, el estándar de responsabilidad debe centrarse en los filtros, la autoridad de las rutas, la relación, la monitorización y la evidencia de reparación, reconociendo al mismo tiempo que la geografía puede amplificar la preocupación del usuario.

Esta distinción ayuda a evitar dos malas lecturas. Una mala lectura trata el evento como prueba de interceptación maliciosa sin evidencia. La otra lo trata como un accidente inofensivo porque no se probó ningún compromiso de contenido. La lectura correcta está en el medio: una filtración de rutas puede ser accidental y aun así grave; el tráfico cifrado puede permanecer confidencial y aun así no disponible; un proveedor puede carecer de intención maliciosa y aun así no cumplir con un importante deber de filtrado. La gobernanza necesita ese vocabulario intermedio.

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

Es una forma de evitar que los usuarios confundan cada ruta extraña con una violación confirmada, al tiempo que se trata la disponibilidad y la integridad del enrutamiento como riesgos reales.

Peering y tránsito son relaciones comerciales con implicaciones técnicas

Peering y tránsito a menudo se resumen como acuerdos comerciales: los pares intercambian tráfico para beneficio mutuo, mientras que los proveedores de tránsito venden accesibilidad a la Internet más amplia. La filtración de Google muestra por qué esos términos necesitan implicaciones técnicas. Una ruta aprendida de un par no debe exportarse automáticamente como si fuera una ruta de cliente. Una ruta de cliente no debe creerse automáticamente como si el cliente estuviera autorizado para transitar una plataforma global. Una ruta aceptada bajo una relación debe llevar restricciones de política cuando cruza otro límite.

Ese mapeo debe implementarse en la configuración del router y en los sistemas de validación. Incluye políticas de importación explícitas para lo que un vecino puede enviar, políticas de exportación explícitas para dónde pueden ir esas rutas, filtros de prefijos y de rutas AS, límites de rutas, validación de origen RPKI cuando corresponda, etiquetas de relación, monitorización 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 sea inaccesible.

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

Los contratos deben seguir la misma lógica. Un acuerdo de peering o un contrato de tránsito no solo debe decir lo que las partes pretenden; debe requerir evidencia de que la intención se aplica. ¿Mantiene cada parte filtros de rutas? ¿Cómo se generan los conjuntos de prefijos de clientes? ¿Con qué frecuencia se revisan? ¿Qué sucede cuando un vecino filtra prefijos famosos? ¿Quién tiene autoridad para cerrar una sesión? ¿Qué aviso público 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, un banco, una editorial o una agencia gubernamental pueden depender de un proveedor cuya accesibilidad depende de relaciones de tránsito. El comprador no puede auditar cada ruta global, pero puede preguntar a sus proveedores críticos cómo monitorizan la accesibilidad, cómo usan RPKI, cómo se protegen contra filtraciones de rutas y cómo notifican a los clientes cuando un fallo de ruta externa afecta el servicio.

Un acuerdo de nivel de servicio que excluya "problemas de enrutamiento de Internet" puede describir la asignación legal, pero no hace que la dependencia operativa desaparezca.

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

Debido a que el evento de Google de 2018 fue una filtración de rutas en lugar de un simple secuestro con 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 filtración, pero aún pertenece a la pila de responsabilidad. Ayuda a distinguir una clase de falsa autoridad de otra, reduce el nivel de fondo de rutas malas y da 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 en el AS autorizado de Google, el componente de origen puede validarse mientras que el trayecto sigue siendo inaceptable. En ese caso, RPKI dice que el origen está permitido, no que MainOne, China Telecom, TransTelecom, NTT o cualquier otro segmento del trayecto deba estar transportando la ruta en esa relación. La validación del trayecto y la prevención de filtraciones de rutas requieren controles adicionales. Por eso importan el RFC 9234 y los mecanismos basados en la relación. Abordan una parte diferente del problema de confianza.

La validación de origen aún puede ayudar durante la respuesta a incidentes. Si una ruta sospechosa tiene un origen no válido, los operadores pueden rechazarla o escalarla como probablemente no autorizada. Si tiene un origen válido pero un trayecto sospechoso, pueden clasificar el incidente como una filtración o fallo de política de trayecto. Esa clasificación afecta a quién llamar y qué evidencia inspeccionar. Una operación madura de seguridad de enrutamiento no le pide a RPKI que responda todas las preguntas; utiliza RPKI para eliminar la ambigüedad 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 debe mantener ROA precisos, pero también debe mantener objetos de ruta, políticas de pares, contactos de proveedores y monitorización externa. Un proveedor como China Telecom debe validar los orígenes, pero también filtrar según la relación. Un par como MainOne debe evitar que las rutas aprendidas de pares se filtren al tránsito. Los controles se complementan en lugar de reemplazarse entre sí.

Por lo tanto, el lector debe llevarse un modelo por capas. RPKI maneja la autoridad de origen. Los filtros de prefijos y de rutas AS manejan la autoridad esperada de clientes y pares. BGP Roles y OTC pueden codificar la dirección de la relación. La monitorización detecta desviaciones. La coordinación humana repara lo que la automatización no puede decidir con seguridad. El lenguaje de los contratos y las métricas de gobernanza mantienen las capas mantenidas. El evento de Google expuso una brecha en ese modelo por capas, no la futilidad de construirlo.

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

Un registro posterior al incidente útil para la filtración de 2018 identificaría cada punto de control en el trayecto. 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 filtración, 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 de par, si se activaron los límites de rutas y cuándo se detuvo la exportación. En los proveedores descendentes, explicaría qué trayectos se seleccionaron y por qué.

Para Google, el registro cubriría el impacto en los clientes, los servicios afectados, la evaluación del cifrado y el compromiso, la línea de tiempo de detección, la escalada con proveedores, la monitorización de rutas, cualquier ingeniería de tráfico de emergencia y los cambios posteriores al evento en los requisitos de peering. Para los observadores independientes, la evidencia de los colectores 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 se apropiara de su superficie de control sin obligar a que la declaración de un actor explique toda la Internet.

El registro público está parcialmente disponible a través del análisis independiente, pero el registro interno de reparación sigue siendo escaso. Eso es común en los incidentes de enrutamiento. Los operadores a menudo arreglan 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. "Mala configuración" no es suficiente. ¿Qué política? ¿Qué sesión? ¿Qué conjunto de rutas? ¿Qué relación de vecindad? ¿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 los grandes compradores no deberían exigir a cada operador que publique la configuración sensible del router. Pueden exigir planes de seguridad de ruta y categorías de evidencia. Por ejemplo: cobertura de filtros de prefijos de clientes, política de validación RPKI, alertas de filtración de rutas, cobertura explícita de políticas EBGP, excepciones de prefijos máximos, tasas de éxito de contactos de emergencia y resúmenes posteriores a incidentes. Esas métricas son lo suficientemente prácticas para auditar sin exponer cada línea del router.

La filtración de Google de 2018 sigue siendo útil porque hace visible el desajuste entre contrato y control. No fue suficiente que las relaciones comerciales implicaran que la ruta no debería viajar de esa manera. Los routers necesitaban una política aplicable. La monitorización necesitaba ver la desviación. Los humanos necesitaban contactos accesibles. El público necesitaba evidencia de que la filtración estaba contenida y de 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 filtración de rutas de Google de 2018 con una pregunta de adquisición y gobernanza: ¿nuestros proveedores críticos traducen las relaciones de enrutamiento en controles que podamos medir? A una filtración de rutas no le importa que un contrato etiquete a un vecino como par o cliente. Le importa si la política del router impide la exportación incorrecta y si la monitorización detecta la filtración cuando la política falla.

Por lo tanto, los clientes deberían preguntar a los proveedores por la evidencia del filtrado de prefijos de clientes, las políticas explícitas de importación y exportación EBGP, la validación RPKI, las alertas de filtración de rutas y los contactos de escalada las 24 horas.

Para las plataformas, la decisión es tratar el enrutamiento externo como parte de la resiliencia del servicio. Un proveedor puede tener excelentes centros de datos, TLS fuerte y aplicaciones robustas y aun así volverse inaccesible si las redes remotas prefieren un trayecto filtrado. Eso significa que la monitorización global de rutas, los simulacros de escalada con proveedores, la higiene de ROA, la higiene de objetos de ruta y la comunicación con los clientes deben situarse cerca de la ingeniería de disponibilidad ordinaria.

"La 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 filtración de ruta famosa haga público el problema. No se debe permitir que una sesión de cliente o par se convierta en un camino 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 inverosímiles, alertar sobre la expansión repentina 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 las juntas y los 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 RPKI inválido, la cobertura de filtros de clientes, la cobertura de políticas explícitas, las alertas de filtración, 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 las relaciones 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, monitorización, coordinación, comunicación con los clientes y evidencia pública.

Una prueba operativa final es preguntar si la próxima filtración de rutas sería notada primero por los clientes, los investigadores externos o 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 parece de repente transitar una red de hiperescala, cuándo un cliente exporta un conjunto de rutas fuera de su autoridad y cuándo los trayectos de tráfico contradicen las relaciones comerciales. Esa visibilidad convierte los contratos de enrutamiento de papeleo en infraestructura aplicable.

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

Por lo tanto, el incidente de Google/MainOne es un recordatorio de que los propietarios de aplicaciones heredan cierta dependencia del enrutamiento, ya sea que sus equipos toquen o no la política del router. La responsabilidad comienza cuando esa dependencia heredada se nombra, se mide y se asigna a un propietario de control en lugar de ser tratada como el clima incognoscible de Internet.

Ese propietario también debería controlar el lenguaje utilizado durante una interrupción. Las filtraciones de rutas pueden sonar como trivialidades remotas de los operadores, pero la pregunta del cliente es inmediata: ¿pueden los usuarios acceder al servicio? ¿Es confiable el trayecto? ¿Qué cambió? ¿Cuándo volverá a la normalidad? Una nota de incidente sólida distingue la pérdida de accesibilidad, el trayecto de tránsito inesperado, el estado del cifrado, el compromiso sospechoso y la remediación. El registro de Google muestra por qué importan esas distinciones.

La tranquilidad de que el tráfico estaba cifrado es importante, pero no responde a la pregunta de disponibilidad. Un retiro 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 los compradores, usuarios y operadores aprendan del evento.

Tipografía

La conclusión

El estándar de responsabilidad es el control práctico unido a la evidencia pública. El registro más sólido no pretende que todos los actores controlaran todos los resultados. Identifica quién podría haber prevenido el fallo, quién podría haberlo detectado, quién podría haber limitado el radio de explosión, quién podría haber notificado a las partes afectadas, quién podría haber reparado la relación de confianza y qué evidencia demuestra que la reparación llegó a los sistemas y personas que dependían de ella.