Fuga de rutas de Safe Host de 2019 y filtrado entre pares

Resumen

Límite del evento congelado:Este artículo aborda la fuga de rutas de Safe Host (AS21217) hacia China Telecom (AS4134) observada el 6 de junio de 2019 y las pruebas inmediatas de propagación y recuperación. No fusiona el evento con la fuga separada del 24 de junio de 2019 que afectó a Verizon, DQE y Cloudflare ni con otras controversias de enrutamiento de China Telecom.
Los recuentos requieren atribución:Los relatos públicos describen más de 70.000 rutas en algunas mediciones y más de 40.000 rutas IPv4 en otra reconstrucción. Las cifras dependen del colector, el intervalo, la familia de rutas, la gestión de duplicados y de lo que un analista considere parte del evento. Ningún recuento público debe presentarse como una tabla global universal.
Una ruta de plano de control no es una conclusión de vigilancia:Los colectores de rutas y las mediciones de rutas pueden mostrar que AS4134 entró en las rutas observadas y que parte del tráfico siguió rutas inesperadas desde puntos de observación concretos. Por sí solos no demuestran la ubicación física de cada paquete, la inspección de paquetes, el acceso a los datos ni la intención maliciosa.
La responsabilidad sigue al control operativo:Safe Host controlaba lo que exportaba AS21217. China Telecom controlaba lo que AS4134 aceptaba y propagaba. Otras redes de tránsito y acceso controlaban sus propias decisiones de importación, preferencia, exportación posterior, monitoreo y escalamiento. Los usuarios finales no tenían medios prácticos para corregir el estado de las rutas.
La incertidumbre sobre la relación debe seguir siendo visible:El debate público entre operadores no estableció una única etiqueta comercial incontestable para la conexión Safe Host–China Telecom. El fallo de rendición de cuentas observable es la propagación más allá del alcance previsto, no una afirmación retrospectiva de que se conocen todas las condiciones contractuales privadas.
La evidencia de los registros es necesaria pero no se aplica sola:Los registros de ASN, direcciones, IRR y RPKI pueden identificar recursos y orígenes esperados. No pueden codificar todas las relaciones ni obligar a un enrutador a rechazar una ruta no deseada. La política en ejecución determinó qué anuncios se convirtieron en rutas alcanzables.
RPKI solo aborda parte del problema:La validación de origen de rutas puede rechazar un origen conflictivo cuando existe un ROA válido. Una fuga de rutas puede conservar un origen autorizado mientras atraviesa un proveedor, par o relación de cliente no deseados. Siguen siendo necesarios filtros que tengan en cuenta las relaciones, la validación del cono de clientes, los controles de prefijos máximos, los valores predeterminados explícitos, el monitoreo y la coordinación.
La recuperación necesita pruebas independientes:Una corrección local de configuración no es un registro completo de recuperación. La corrección responsable muestra las retiradas, las rutas de sustitución, la convergencia desde múltiples puntos de observación, las excepciones residuales, los filtros actualizados, las alarmas probadas y una reproducción que demuestre que la misma clase de anuncios ahora se rechaza o contiene.

Congela el evento antes de asignar responsabilidades

La rendición de cuentas de la infraestructura comienza por fijar el límite del evento. El 6 de junio de 2019, observadores públicos de enrutamiento informaron de que Safe Host, sistema autónomo 21217, anunció un conjunto muy grande de rutas a China Telecom, sistema autónomo 4134, a través de una interconexión en Fráncfort. China Telecom aceptó los anuncios y los propagó. Para algunos destinos y puntos de observación, AS4134 apareció en consecuencia en rutas que normalmente no lo habrían incluido.

Informes contemporáneos y posteriores asociaron el evento con una alcanzabilidad interrumpida o degradada que afectó a partes de la infraestructura móvil y de servicios europea. [1][2][3][4][5][6][7]

Esas proposiciones son suficientemente sólidas para respaldar un análisis de rendición de cuentas del enrutamiento. No respaldan todas las afirmaciones que circularon en torno al incidente.

El registro público no revela la configuración completa de exportación de Safe Host, la configuración completa de importación de China Telecom, todos los objetos de política de rutas, todas las condiciones bilaterales, todas las decisiones de preferencia local, todos los historiales de alertas ni la identidad de cada persona que aprobó o cambió la política. No establece una intención maliciosa. No demuestra que todo el tráfico europeo se viera afectado. No demuestra que cada paquete cuya ruta en el plano de control incluyera AS4134 se reenviara físicamente por la misma geografía, se inspeccionara, se retuviera o se alterara.

La fecha es importante porque junio de 2019 incluyó otros incidentes de enrutamiento. La fuga posterior de Verizon, DQE y Cloudflare implicó redes, mecanismos y efectos de servicio diferentes. Combinar esos eventos produciría una historia dramática, pero un registro de rendición de cuentas débil. El responsable de una corrección no puede arreglar un incidente cuyo conjunto de rutas, intervalo temporal, límite de relación y controles responsables se hayan difuminado con otro evento.

La pregunta acotada es, por tanto, precisa: ¿cómo salió de AS21217 un conjunto extraordinario de rutas, por qué AS4134 aceptó y propagó esas rutas, cómo respondieron otras redes, qué pruebas muestran los cambios de ruta resultantes y qué pruebas demostrarían que el estado de ruta fue retirado y limitado para evitar su repetición?

Este planteamiento también impide que la inferencia geopolítica sustituya a la evidencia de ingeniería. El enrutamiento transfronterizo puede tener implicaciones de seguridad, y los operadores deben tratar con seriedad las rutas internacionales inesperadas. Pero una ruta inesperada es ante todo un evento de enrutamiento observable. La intención, el acceso y la consecuencia jurídica requieren pruebas adicionales. El análisis de rendición de cuentas debe volverse más cuidadoso, no menos, cuando la ruta cruza una frontera políticamente sensible.

El desacuerdo sobre el recuento de rutas es un problema de evidencia, no una razón para descartar el evento

Las descripciones públicas suelen decir que AS21217 filtró más de 70.000 rutas y que el evento duró más de dos horas. Otra reconstrucción del incidente describe más de 40.000 rutas IPv4. [1][2][4][5] Estas cifras no son necesariamente excluyentes entre sí. Pueden reflejar distintos colectores, familias de direcciones, ventanas temporales, recuentos de actualizaciones frente a prefijos, deduplicación de rutas y definiciones de qué anuncios pertenecen al evento.

Un colector BGP registra lo que sus pares participantes le exportan. Un colector puede recibir una ruta anómala que otro nunca ve. Un par puede exportar solo su mejor ruta seleccionada. Un analista puede contar prefijos únicos, actualizaciones de rutas, variantes de ruta o combinaciones de origen. La primera actualización observada en un colector no es necesariamente el primer anuncio incorrecto en cualquier lugar, y la última retirada en un colector no es necesariamente el fin del estado obsoleto en toda la red.

Los informes responsables necesitan por tanto un protocolo de recuento. Un informe de incidente defendible indicaría:

qué puntos de observación de RouteViews, RIPE RIS, operadores o mediciones se utilizaron;
las marcas de tiempo exactas de inicio y fin y el estándar horario;
si se incluyeron tanto IPv4 como IPv6;
si la métrica cuenta prefijos únicos, actualizaciones, variantes de ruta u orígenes;
cómo se gestionaron los anuncios duplicados y las sustituciones de rutas;
qué patrón de ruta AS definió una ruta afectada;
cómo se emparejaron las retiradas y las rutas normales posteriores con el conjunto anómalo; y
qué partes de la red quedaron fuera de la observación.

Sin ese protocolo, un recuento de rutas puede convertirse en una señal de autoridad en lugar de evidencia. Una cifra mayor puede atraer la atención, mientras que una menor puede parecer más conservadora. Ninguna de las dos es fiable a menos que otro analista pueda reproducir el método.

La incertidumbre no hace que el evento sea pequeño. Decenas de miles de rutas fueron extraordinarias en relación con cualquier conjunto de anuncios acotado plausible para una sola interconexión. Un control de prefijos máximos o de volumen de rutas no debería necesitar un recuento final perfectamente acordado del incidente para detectar que el conjunto recibido se aleja radicalmente de lo esperado.

Esta distinción es importante operativamente. Los umbrales deben basarse en el conjunto de rutas autorizado y esperado para una relación, con márgenes de crecimiento documentados y excepciones explícitas. No deben basarse en la suposición de que el próximo fallo se parecerá a la cifra final de un informe histórico. El control debe reaccionar cuando la realidad se aparta del contrato de relación, no solo cuando se supera una cifra famosa de un incidente.

Una fuga de rutas es un fallo ejecutable de la política de relación

BGP distribuye alcanzabilidad entre sistemas autónomos operados de forma independiente. El protocolo base transporta prefijos, rutas, atributos y retiradas. No contiene una verdad comercial universal para cada sesión. Los operadores expresan las relaciones de cliente, proveedor, par, servidor de rutas, respaldo y fines especiales mediante configuración, generación de políticas, comunidades, filtros y procesos operativos.

Una ruta aprendida en una relación no es automáticamente apta para exportarse a todas las demás relaciones. Un cliente generalmente anuncia sus propios prefijos y las rutas para las que está autorizado a prestar servicio. Un proveedor puede anunciar una alcanzabilidad amplia a un cliente. Los pares suelen intercambiar su propia alcanzabilidad y la de sus clientes, en lugar de proporcionar tránsito gratuito entre proveedores no relacionados. Los acuerdos reales pueden ser más complejos, pero la existencia de excepciones hace que la política explícita sea más importante, no menos.

RFC 7908 proporcionó más tarde una taxonomía para las rutas propagadas más allá del alcance previsto. [14] El valor de esa taxonomía es que se centra en la propagación observable y en la política de relación, en lugar de asumir una intención maliciosa. El debate de los operadores en torno al evento de 2019 no resolvió todas las etiquetas de relación ni un único tipo de fuga incontestado. [8][9] Esa incertidumbre debe permanecer en el registro.

El comportamiento externo central sigue siendo visible. AS21217 anunció un conjunto de rutas cuya escala y alcance eran incompatibles con una expectativa de interconexión estrecha. AS4134 aceptó y exportó una parte suficiente de ese conjunto para que las rutas se propagaran. Otras redes aplicaron después su propia política: algunas aceptaron la ruta, algunas pudieron preferirla, algunas la propagaron, algunas la filtraron y otras mantuvieron alternativas no afectadas.

Llamar a esto un fallo distribuido no debe dejarlo sin dueño. Safe Host controlaba la frontera de exportación en AS21217. China Telecom controlaba la primera frontera visible de importación y exportación posterior en AS4134. Cada sistema autónomo posterior controlaba si la ruta entraba en su base de información de enrutamiento, se convertía en ruta seleccionada, entraba en la tabla de reenvío o se anunciaba a otro vecino. Los colectores de rutas controlaban la calidad y retención de la evidencia independiente. Los operadores de servicios y de acceso controlaban la resiliencia y la comunicación con los usuarios.

Las obligaciones no son idénticas. El exportador tiene la obligación más directa de limitar lo que sale de su red. Un importador directo tiene una potente oportunidad de contención porque conoce la relación bilateral y puede rechazar anuncios que no se ajusten a ella. Otras redes pueden tener un conocimiento menos específico, pero aun así controlan los límites de prefijos máximos, la validación de origen, la política sensible a las relaciones, el monitoreo de anomalías y el escalamiento.

La frase «BGP aceptó las rutas» es, por tanto, incompleta. El software que ejecutaba una política configurada aceptó las rutas. El protocolo transportó el anuncio; los operadores determinaron las restricciones.

La rendición de cuentas de la exportación comienza con un contrato de rutas autorizado

Un exportador debe poder definir el conjunto de rutas que una sesión tiene permitido anunciar. Ese contrato puede construirse a partir del inventario de clientes, los objetos de los registros de enrutamiento, los datos RPKI, los registros internos de servicios, la autoridad delegada y las excepciones explícitas. Sean cuales sean las fuentes, la política resultante necesita un propietario, un momento de generación, una versión, una vía de revisión y un método para demostrar qué llegó al enrutador.

Para AS21217, un registro de rendición de cuentas posterior al evento distinguiría al menos cuatro conjuntos:

rutas que Safe Host estaba autorizado a originar;
rutas de clientes que Safe Host estaba autorizado a transitar;
rutas amplias aprendidas de otro proveedor o par;
rutas que la política AS21217 a AS4134 exportó realmente durante el evento.

La diferencia entre el conjunto previsto y el real es el hallazgo técnico central. Es más útil que una declaración genérica de que se produjo un error de configuración.

La política de exportación debe asumir por defecto que no se anuncia nada hasta que se adjunte una política prevista. RFC 8212 formaliza el valor operativo de una política explícita de importación y exportación eBGP. [15] Una postura de rechazo por defecto no resuelve todos los errores de generación o adjunción, pero elimina la suposición peligrosa de que una sesión nueva o mal clasificada debe intercambiarlo todo hasta que alguien añada filtros.

El contrato de rutas también necesita pruebas negativas. Una cadena de políticas debe demostrar que rechaza:

una tabla de enrutamiento completa recibida de una fuente de la que se espera un conjunto acotado;
un prefijo no presente en el inventario de clientes autorizado;
una ruta que contenga una secuencia de relaciones imposible o no autorizada;
una ruta por defecto inesperada;
un aumento repentino del recuento de rutas fuera de una ventana de crecimiento documentada;
rutas obsoletas que permanezcan después de retirarse la autorización; y
una excepción cuya aprobación haya caducado.

La revisión de configuración por sí sola es una evidencia débil, porque la fuente revisada puede diferir de la configuración generada, del candidato desplegado o del estado en ejecución. Un proceso creíble registra los datos de origen, el filtro generado, la diferencia del dispositivo, el resultado de la confirmación, el conjunto de rutas anunciadas observado y el resultado del colector independiente.

El control de cambios debe ser escalonado. Una actualización de política puede probarse con datos BGP registrados, aplicarse a una sesión canario, monitorearse para detectar deltas de ruta inesperados y revertirse sin una propagación amplia. Una reproducción de la fuga de rutas debe formar parte de las pruebas de resiliencia, no reservarse para un incidente.

La rendición de cuentas de la exportación también incluye la preparación para la retirada. Un operador debe saber cómo detener rápidamente un anuncio anómalo sin sustituir un evento de enrutamiento por una interrupción más amplia. Eso exige autoridad nominada, comandos o automatización probados, contactos de pares, criterios de refresco de rutas y reinicio de sesión, y monitores externos que muestren si el cambio se propagó.

La rendición de cuentas de la importación es la primera oportunidad de contención externa

La responsabilidad del importador se describe a veces como secundaria porque no creó el anuncio incorrecto. Eso es demasiado débil para la infraestructura interdominio. Un vecino directo controla la primera frontera externa y a menudo posee información que las redes distantes no tienen: la relación bilateral, el volumen de rutas esperado, los prefijos autorizados, las rutas AS conocidas, el historial de excepciones y el canal de contacto.

AS4134 importa, por tanto, con independencia de AS21217. La evidencia pública respalda que China Telecom aceptó y propagó el conjunto extraordinario de rutas. El registro no revela todos los filtros ni todas las decisiones internas, pero el resultado observado muestra que los controles de importación y exportación posterior no contuvieron el evento en esa frontera.

Un importador consciente de la relación puede combinar varios controles.

Primero, los filtros de prefijos pueden generarse a partir de los registros de clientes y recursos autorizados. Los datos deben estar actualizados, versionados y conciliados con el contrato de servicio real. Una lista blanca obsoleta puede rechazar un crecimiento legítimo; una lista blanca excesivamente amplia puede convertir el filtro en teatro.

Segundo, las restricciones de rutas AS pueden comprobar si un anuncio es plausible para la relación. Un cliente no debería anunciar generalmente una ruta que implique tránsito entre proveedores no relacionados. Los datos del cono de clientes son imperfectos, por lo que las excepciones y la incertidumbre necesitan un tratamiento operativo, pero una evidencia imperfecta de relación puede respaldar la detección y la revisión.

Tercero, los controles de prefijos máximos y de volumen de rutas pueden detectar una desviación radical de lo esperado. El umbral de advertencia debe alertar a un canal con propietario antes del límite máximo. La respuesta firme debe estar documentada: rechazar rutas nuevas, cerrar la sesión, poner en cuarentena el conjunto o invocar otra acción acotada. El comportamiento de apertura ante fallos debe ser explícito, no accidental.

Cuarto, una política de importación explícita evita que una sesión se vuelva permisiva porque falta un mapa de rutas, está mal nombrado o adjunto en la dirección incorrecta.

Quinto, la validación de origen puede rechazar un origen no válido cuando un ROA válido cubre el prefijo. Añade evidencia sólida, pero no demuestra que la ruta sea adecuada.

Sexto, el monitoreo de anomalías puede comparar las rutas recibidas y aceptadas con la línea base de la relación, los colectores globales y los cambios conocidos. Una alerta debe incluir la ruta infractora, el recuento de rutas, el conjunto esperado, la versión de la política, los pares afectados y una acción de contención segura.

El importador también controla la exportación posterior. Incluso si una ruta se conserva para diagnóstico, no es necesario propagarla a clientes, pares y proveedores. Separar los controles de aceptación, selección, reenvío y anuncio puede evitar que un fallo se convierta en un evento distribuido.

Estos controles imponen costes operativos. Los filtros necesitan mantenimiento. Los límites de prefijos máximos pueden crear interrupciones si se configuran sin cuidado. Los datos de relación pueden estar incompletos. Las excepciones de emergencia pueden ser necesarias. La rendición de cuentas no niega esas contrapartidas. Exige que los operadores las documenten, las prueben y muestren por qué la exposición resultante es aceptable.

La evidencia de rutas AS no debe confundirse con la prueba sobre cada paquete

El carácter transfronterizo del evento atrajo una preocupación comprensible. Los análisis públicos mostraron a AS4134 apareciendo en rutas para destinos asociados a operadores y servicios móviles europeos. Los informes de medición también describieron tráfico que seguía rutas inesperadas desde puntos de observación concretos. [1][2][3][4][5][7]

Deben permanecer diferenciadas cuatro capas de evidencia.

La primera es lapropagación en el plano de control. Una actualización BGP observada por RouteViews, RIPE RIS u otro colector muestra que una ruta se anunció al par de ese colector. Respalda afirmaciones sobre la visibilidad de la ruta en un momento y desde un punto de observación.

La segunda es laselección de rutas. Una red puede recibir múltiples rutas y seleccionar una según la preferencia local, la longitud de la ruta, las comunidades, la validación de origen y otras políticas. Un colector suele ver solo la ruta que su par exporta, no todas las rutas consideradas.

La tercera es elcomportamiento de reenvío. Una ruta seleccionada puede entrar en la tabla de reenvío y transportar tráfico, pero se necesita traceroute o una medición activa para probar la ruta desde un origen concreto. Incluso entonces, el mapeo IP a ubicación, los saltos ocultos, MPLS, el enrutamiento asimétrico, el equilibrio de carga y las diferencias de la ruta de respuesta limitan la inferencia.

La cuarta es lagestión de paquetes y la consecuencia de seguridad. Una ruta de reenvío a través de un sistema autónomo no demuestra por sí sola la inspección de paquetes, el acceso al contenido, la retención, la alteración o la intención. Importan el cifrado, los protocolos de aplicación, el comportamiento del punto final y las operaciones internas de la red.

Un relato sólido del incidente alinea estas capas por marca de tiempo. Puede decir que una ruta con una ruta AS concreta se hizo visible, que mediciones activas desde ubicaciones especificadas observaron después un cambio en la ruta de reenvío o una degradación del servicio, y que el comportamiento se normalizó tras las retiradas. No debe colapsar esas observaciones en una declaración universal sobre todo el tráfico.

Esta disciplina es especialmente importante cuando la ruta es políticamente sensible. La evidencia puede justificar una investigación de seguridad y controles más estrictos. No justifica sustituir la sospecha geopolítica por la prueba a nivel de paquete.

Los operadores deben conservar los datos necesarios para esa distinción: actualizaciones en bruto, bases de información de enrutamiento, resultados de looking-glass, traceroutes, resúmenes de flujo, mediciones de pérdida de paquetes, estado de las aplicaciones, registros de sincronización horaria y el método utilizado para mapear los saltos de red. La retención debe ser suficiente para reconstruir el periodo anterior, durante y posterior al evento.

Los colectores de rutas son infraestructura de rendición de cuentas con puntos ciegos conocidos

RouteViews y RIPE RIS proporcionan evidencia independiente indispensable para incidentes interdominio. Sus archivos de junio de 2019 y la documentación de medición hacen posible la reconstrucción posterior. [12][13] RIPEstat también ofrece una superficie de evidencia para AS21217 y AS4134, aunque los registros actuales no deben proyectarse al pasado sin matices. [10][11]

Los colectores no son omniscientes. Reciben rutas de pares seleccionados según las políticas de exportación de esos pares. Pueden no ver una ruta que está confinada a otra parte de la topología. Pueden ver una mejor ruta, pero no las alternativas. Sus marcas de tiempo registran la llegada al colector, no la primera causa global. Los reinicios de sesión, las actualizaciones duplicadas, la amortiguación de rutas y la disponibilidad del colector pueden afectar al registro.

Una reconstrucción responsable debe utilizar más de un colector y documentar sus diferencias. Debe conservar los archivos en bruto o referencias de archivo precisas, el código o los comandos de análisis, las reglas de normalización y los conjuntos de datos derivados. Debe registrar el par del colector utilizado para cada afirmación.

La telemetría del operador puede cerrar algunas lagunas. Las instantáneas de rutas recibidas y anunciadas en la sesión directa muestran qué cruzó la frontera de la relación. Las bases de información de enrutamiento locales muestran la selección. Las tablas de reenvío y los flujos muestreados muestran el uso. Los registros de cambios y los repositorios de políticas conectan el estado observado con la configuración desplegada. Los informes de pares añaden confirmación independiente.

La evidencia también debe conservar los resultados negativos. Si un colector no vio la ruta, eso no demuestra que la ruta estuviera ausente globalmente, pero puede restringir la propagación. Si un servicio siguió siendo alcanzable desde una ubicación, eso no refuta el impacto en otros lugares, pero puede revelar la diversidad de rutas.

Los informes públicos de incidentes suelen citar un gráfico de un colector sin explicar estos límites. Eso crea una falsa precisión y hace que las disputas sobre cifras parezcan disputas sobre si el evento ocurrió. Un mejor informe trata al colector como un testigo acotado: valioso, reproducible e incompleto.

Los registros son libros de contabilidad, no mecanismos de aplicación del enrutador

El evento de Safe Host se asienta directamente sobre la superficie de control del enrutamiento BGP, la evidencia de los registros de ASN y direcciones IP, y las relaciones de interconexión o tránsito.

Un registro de ASN puede identificar a AS21217 y AS4134. Los registros de direcciones pueden identificar asignaciones y adjudicaciones. Los objetos del Internet Routing Registry pueden publicar orígenes y políticas previstos. RPKI puede proporcionar autorización de origen firmada. Estos registros mejoran la unicidad, la exactitud, el historial de transferencias, los metadatos de seguridad y la coordinación operativa.

No determinan la ruta en ejecución.

Una entrada de registro no conoce todas las relaciones comerciales privadas. Un objeto IRR no obliga a un enrutador a cargar un filtro generado. Un ROA dice qué origen está autorizado para un prefijo y su longitud máxima; no dice qué proveedores o pares pueden transportar esa ruta. Un contacto de abuso o NOC no garantiza que una alerta llegue a una persona con autoridad para retirar rutas.

Por eso la legitimidad de los registros debe entenderse por la calidad del libro de contabilidad, no por una soberanía imaginada sobre el enrutamiento. El registrador proporciona evidencia que los operadores pueden utilizar. Los sistemas en ejecución, las políticas y las interconexiones determinan la alcanzabilidad.

La primacía del código en ejecución hace que la gobernanza sea comprobable. Un consejo puede exigir registros de autorización de rutas, pero también debe exigir evidencia de que esos registros se obtienen, validan, transforman en política, despliegan y monitorean. Un auditor puede inspeccionar un objeto de ruta IRR, pero debe rastrearlo a través del generador de políticas hasta un dispositivo e inyectar un anuncio de prueba conflictivo.

El libro de contabilidad también necesita controles. Los registros de recursos deben ser únicos, actuales, autenticados, transferibles mediante un proceso documentado y recuperables durante interrupciones organizativas o de infraestructura. Los registros obsoletos o ambiguos pueden hacer que el filtrado estricto sea operativamente arriesgado. Los operadores pueden crear entonces excepciones amplias, que deben tener propietarios, fechas de caducidad y monitoreo.

La capa de realidad rechaza dos historias fáciles. Una dice que el enrutamiento descentralizado significa que nadie rinde cuentas. La otra dice que un registro central puede ordenar que las rutas sean correctas. El sistema real es una red de operadores autónomos que utilizan evidencia compartida, política bilateral, código en ejecución y coordinación. La rendición de cuentas sigue a los puntos donde esos elementos pueden cambiarse y verificarse.

Eliminar de este artículo a AS21217, AS4134, los anuncios BGP, la política de relación, los colectores de rutas y la evidencia de retirada destruye la tesis. La superficie de control de la red no es una metáfora añadida a un incidente corporativo genérico. Es el incidente.

RPKI es valioso, pero la validez del origen no es una autorización de ruta

RPKI y la validación de origen de rutas se proponen a menudo tras incidentes de enrutamiento. Merecen un tratamiento preciso.

RFC 6811 describe cómo un enrutador puede clasificar una ruta con datos ROA validados. [16] Una ruta puede ser válida, no válida o no encontrada según el origen anunciado, el prefijo, la longitud máxima y los registros validados disponibles. Rechazar o quitar preferencia a las rutas no válidas puede evitar algunos orígenes erróneos y secuestros.

Una fuga de rutas puede conservar el origen legítimo. El problema puede ser que una ruta autorizada se exportó a través de una relación no deseada y luego se propagó aún más. El origen sigue siendo válido mientras la política de ruta es incorrecta. La validación de origen por sí sola no codifica quién es cliente, proveedor o par, ni si una ruta aprendida en una relación puede exportarse a otra.

Esa limitación no es un argumento contra RPKI. Es un argumento a favor de controles en capas.

Un operador debe desplegar la validación de origen con una política documentada, monitorear las rutas no válidas y no encontradas, mantener sus propios ROA y coordinar las excepciones. También debe mantener filtros de prefijos y rutas, una política de importación y exportación explícita, evidencia del cono de clientes, controles de prefijos máximos, detección de fugas de rutas, coordinación entre pares y monitoreo independiente.

RPKI también puede reforzar la rendición de cuentas después de un incidente. Ayuda a distinguir un conflicto de origen de una fuga de relación y aporta evidencia firmada sobre la autorización en un momento dado. La validación histórica exige un estado validado archivado; utilizar los ROA actuales para juzgar una ruta de 2019 sin matices puede inducir a error.

La misma cautela se aplica a estándares y prácticas posteriores. RFC 8212, las acciones de MANRS y la guía del NIST ofrecen marcos de control útiles. [15][17][18] Deben utilizarse para diseñar la corrección presente, no para inventar pruebas sobre lo que cada operador había desplegado o debía contractualmente durante el evento.

Los límites de prefijos máximos son necesarios y fáciles de usar mal

El extraordinario volumen de rutas hace que el control de prefijos máximos sea una pregunta obvia. Un vecino directo que normalmente anuncia un conjunto acotado no debería poder enviar decenas de miles de rutas inesperadas sin advertencia ni contención.

Sin embargo, un límite de prefijos máximos no es una única cifra copiada de una lista de comprobación del sector. Debe derivarse del conjunto de rutas esperado de la relación, el crecimiento legítimo, los patrones de mantenimiento, las familias de direcciones y el impacto del fallo. Un límite demasiado alto no contiene el evento. Un límite demasiado bajo puede desconectar una sesión sana y provocar una interrupción.

Un diseño maduro separa los umbrales de advertencia y de acción. La advertencia debe llegar a un canal operativo con propietario y contexto antes de la respuesta firme. La respuesta firme puede rechazar rutas excesivas, conservar el último conjunto autorizado conocido, poner la sesión en cuarentena o cerrarla. El comportamiento elegido debe probarse.

Los cambios de umbral necesitan gobernanza. Un aumento de emergencia debe identificar al solicitante, la evidencia, al aprobador, la caducidad y el monitoreo. De lo contrario, una excepción temporal puede convertirse en una exposición permanente.

El volumen es solo una dimensión. Un pequeño número de prefijos estratégicamente importantes puede causar un impacto grave. Los controles deben combinar el volumen con la autorización, la validez del origen, la plausibilidad de la ruta, el alcance de la relación, la criticidad del destino y la velocidad de cambio.

El evento de Safe Host ilustra por qué los importadores deben conocer el recuento de rutas esperado antes de un incidente. Si la línea base se construye solo después de que comience una fuga, la contención se convierte en una negociación bajo presión. Un conjunto autorizado congelado y un umbral probado convierten el volumen anómalo en una señal inmediata y procesable.

Otras redes siguen controlando su propia aceptación y propagación

El exportador e importador directos son centrales, pero la ruta viajó a través de un ecosistema más amplio. Cogent y otras redes aparecieron en discusiones e informes contemporáneos, a veces de formas luego corregidas o aclaradas. [3][5][6] La lección no es asignar una puntuación de culpa indiferenciada. Es mapear cada segmento de ruta observado al control disponible en esa red.

Una red de tránsito posterior puede no conocer los detalles privados de la relación original Safe Host–China Telecom. Aun así, puede preguntarse si la ruta es plausible, si el origen de la ruta está autorizado, si el volumen es anómalo, si la ruta entra en conflicto con los datos del cono de clientes y si los feeds independientes informan de una fuga.

Los operadores de acceso y móviles controlan la diversidad de rutas y la resiliencia de los servicios. Si los servicios críticos dependen de rutas que comparten dependencias ascendentes, una fuga puede afectar a múltiples marcas o regiones a pesar de una aparente diversidad contractual. La evidencia topológica debe complementar, por tanto, el recuento de proveedores.

Los operadores de contenido y nube pueden monitorear sus prefijos desde puntos de observación externos, mantener contactos de alerta de rutas y coordinarse con los proveedores ascendentes. No pueden configurar directamente todas las redes de tránsito, pero pueden detectar rutas inesperadas y aportar evidencia que acelere la contención.

Los operadores de puntos de intercambio de Internet y de servidores de rutas tienen funciones diferentes según la topología. Sus controles pueden incluir la política de participantes, el filtrado del servidor de rutas, la configuración de prefijos máximos y la coordinación de incidentes. La evidencia debe establecer que realmente estaban en la ruta relevante antes de asignar obligaciones.

Los reguladores y clientes deben evitar tratar a todas estas partes como intercambiables. Las preguntas más eficaces siguen la ruta:

¿Qué recibió esta red?
¿Qué aceptó?
¿Qué seleccionó?
¿Qué reenvió?
¿Qué anunció hacia delante?
¿Qué política y evidencia gobernaron cada decisión?
¿Qué alerta se disparó, quién era su propietario y qué acción siguió?
¿Cómo demostró la red que el estado anómalo fue retirado?

Este método ruta por ruta hace concreta la responsabilidad distribuida sin pretender que todos los operadores tenían una visibilidad o autoridad idénticas.

La resiliencia transfronteriza debe diseñarse, no inferirse de los nombres de los proveedores

El evento también expuso una debilidad de planificación. Las organizaciones suelen contar proveedores, centros de datos o contratos y asumen que cada nombre representa una ruta de red independiente. La política BGP puede hacer que servicios nominalmente separados converjan en un tránsito, intercambio, cable o sistema autónomo compartido.

La evaluación de la resiliencia debe inspeccionar las rutas reales desde las regiones de usuario relevantes hasta los prefijos críticos. Debe probar condiciones normales y de fallo, incluir IPv4 e IPv6 e identificar sistemas autónomos e instalaciones comunes. Una fuga de rutas puede cambiar esas rutas dinámicamente, por lo que un monitoreo externo continuo o muestreado es más útil que un diagrama puntual.

Las restricciones transfronterizas necesitan un tratamiento explícito. Un servicio puede tener requisitos de latencia, jurisdicción, acceso operativo o exposición. Esos requisitos no pueden aplicarse solo con una cláusula contractual si los cambios de enrutamiento son invisibles. El monitoreo debe alertar cuando una ruta entra en un AS o geografía inesperados, pero la alerta debe preservar la incertidumbre en la geolocalización y distinguir la evidencia del plano de control del reenvío de paquetes.

El cifrado sigue siendo esencial porque el control de rutas es imperfecto. Reduce la consecuencia de un tránsito inesperado, pero no elimina los riesgos de disponibilidad, metadatos, análisis de tráfico o punto final. Los controles de enrutamiento y los controles criptográficos resuelven problemas distintos.

Los ejercicios de incidentes deben incluir una fuga de rutas que envíe rutas a través de una red internacional inesperada. El ejercicio debe probar la detección técnica, el escalamiento al NOC, los contactos con los proveedores, la comunicación con los clientes, la evaluación jurídica y la conservación de evidencias. El objetivo no es dramatizar el riesgo geopolítico. Es hacer ejecutables las responsabilidades de respuesta antes de que ocurra un evento ambiguo.

Un registro de recuperación creíble demuestra la retirada y la normalización

Los informes públicos indican que el enrutamiento anómalo persistió más de dos horas en algunas observaciones antes de que las rutas se normalizaran. [1][2][4][5][7] Al igual que con los recuentos de rutas, la duración exacta depende del punto de observación y de la definición. La última ruta anómala de un observador puede no representar la convergencia global.

Un registro de recuperación responsable debe distinguir:

cuándo comenzó la exportación desencadenante;
cuándo la detectó el primer observador externo;
cuándo llegó una alerta a un equipo con propietario;
cuándo Safe Host cambió o desactivó la exportación;
cuándo AS4134 dejó de aceptar o propagar las rutas;
cuándo los vecinos directos observaron retiradas;
cuándo los principales colectores volvieron a las rutas esperadas;
cuándo se normalizaron el reenvío y el estado de los servicios; y
cuándo se eliminaron las rutas residuales obsoletas o excepcionales.

El registro debe identificar la fuente de cada marca de tiempo. Los registros del enrutador, las actualizaciones de los colectores, los sistemas de tickets, los registros de chat, las mediciones activas y el estado de las aplicaciones pueden utilizar relojes diferentes. La sincronización horaria y la normalización forman parte de la evidencia.

La prueba de retirada debe operar en múltiples capas. Un enrutador local puede mostrar que ya no anuncia la ruta. Un vecino directo puede mostrar la recepción de una retirada o una sustitución. Los colectores de rutas pueden mostrar que la ruta AS anómala desaparece de sus pares. Las mediciones activas pueden mostrar la normalización del reenvío. La telemetría del servicio puede mostrar la recuperación.

Ninguna de estas observaciones por sí sola demuestra una convergencia universal. Juntas forman un registro acotado y auditable.

El informe también debe identificar qué cambió de forma permanente. Algunos ejemplos:

un rol de sesión corregido o un adjunto de mapa de rutas corregido;
un filtro de prefijos autorizados generado;
una restricción de cono de clientes o de ruta;
umbrales de advertencia y máximos de prefijos más bajos;
una política explícita de rechazo por defecto;
validación RPKI y mantenimiento de ROA;
una alerta de anomalía con propietario;
mejores datos de contacto y escalamiento;
un proceso de despliegue canario o escalonado; y
una prueba de repetición con el patrón de ruta histórico.

Decir que «se añadieron filtros» no es suficiente. La evidencia debe mostrar la entrada del filtro, la salida generada, el resultado del despliegue, el estado en ejecución, la prueba negativa y el resultado del monitoreo.

El riesgo residual debe permanecer visible. Los datos de relación pueden estar incompletos. Una fuga con origen válido puede evadir la validación de origen. Las excepciones pueden ampliar el alcance. Los colectores tienen puntos ciegos. Un cierre firme de sesión puede afectar a la disponibilidad. El registro de corrección debe explicar cómo se gestionan esas contrapartidas.

La prueba de recurrencia es más importante que una declaración de política

La evidencia más sólida de que la corrección funciona es una repetición controlada de la clase de fallo.

El entorno de prueba debe reproducir una sesión con el rol de relación relevante y un conjunto de rutas esperado congelado. Debe introducir después:

una ruta fuera del conjunto de prefijos autorizado;
un anuncio de tabla completa o de gran volumen;
una ruta AS inesperada;
una ruta con origen válido propagada a través de una relación no deseada;
una excepción caducada;
una ruta obsoleta tras la eliminación de autoridad; y
un fallo de una fuente de datos de política.

El operador debe mostrar qué hace cada capa. El exportador debe rechazar o suprimir el conjunto no válido. El importador debe contener lo que escape. Los controles de prefijos máximos y de anomalías deben alertar. La exportación posterior debe permanecer acotada. El propietario de la respuesta debe recibir contexto suficiente para actuar. La reversión debe restaurar el último estado autorizado conocido.

Las pruebas deben utilizar la ruta real de generación y despliegue de políticas. Un filtro de laboratorio que difiere de la producción demuestra poco. Los resultados deben incluir versiones de software y de política, hashes de configuración, rutas esperadas y reales, tiempos, entrega de alertas, decisiones humanas y observación independiente.

La prueba también debe incluir el fallo del propio control. ¿Qué ocurre si el feed IRR está obsoleto, el validador RPKI no está disponible, el compilador de políticas falla o el colector de monitoreo pierde una sesión? Las decisiones de abrir o cerrar ante fallos deben ser deliberadas y estar vinculadas a la criticidad del servicio.

Los ejecutivos no necesitan inspeccionar todas las rutas. Deben exigir evidencia de que la prueba se realizó, de que se explicaron las excepciones, de que los fallos tienen propietarios y de que la próxima prueba está programada. Los auditores pueden muestrear los artefactos subyacentes.

Este enfoque convierte la seguridad del enrutamiento de una aspiración en una afirmación operativa que puede falsarse.

Las preguntas de gobernanza deben seguir al control y no a los titulares

Los consejos, reguladores, clientes y auditores pueden formular preguntas eficaces sin pretender operar sesiones BGP.

Los consejos deben preguntar:

¿Qué personas y sistemas pueden cambiar los anuncios públicos de rutas?
¿Cuántas sesiones externas carecen de un rol de relación explícito?
¿Qué proporción de sesiones de clientes utilizan filtros de prefijos autorizados actuales?
¿Qué sesiones tienen umbrales de advertencia y límites máximos de prefijos?
¿Cuántas excepciones están abiertas, quién las posee y cuándo caducan?
¿Cuándo fue la última repetición de fuga de rutas y qué falló?
¿Con qué rapidez puede la organización demostrar la retirada desde puntos de observación independientes?

Los proveedores de tránsito deben preguntar si los registros de clientes y pares coinciden con la configuración en vivo, si los filtros se generan y prueban, si la validación de origen se aplica de forma coherente y si la exportación posterior se restringe por separado.

Los operadores de centros de datos y alojamiento deben preguntar si las responsabilidades de enrutamiento están claras entre la instalación, la red, el inquilino, el revendedor y el proveedor de tránsito. Un contrato de alojamiento físico no define automáticamente quién es dueño de la política de exportación de AS21217.

Los clientes empresariales y móviles deben pedir evidencia topológica, monitoreo externo de rutas, contactos de incidentes y prueba del estado de las rutas en los informes posteriores al incidente. Deben evitar equiparar la diversidad de marcas de proveedores con la diversidad de rutas.

Los auditores deben rastrear una muestra de recursos desde la evidencia del registro, pasando por la generación de políticas, hasta la configuración en ejecución y una prueba de ruta negativa. Las capturas de pantalla de un portal o una política escrita no son evidencia de aplicación.

Los reguladores deben evitar imponer un único control como cura universal. Los ROA mejoran la evidencia de origen. No codifican todas las relaciones. Los límites de prefijos máximos contienen el volumen, pero pueden causar interrupciones si no se gestionan. Los requisitos eficaces deben centrarse en resultados: alcance autorizado, contención en capas, evidencia conservada, coordinación y recuperación probada.

Los revisores de incidentes deben rechazar el «error humano» como causa raíz. La frase no explica por qué una sola acción pudo exportar un conjunto enorme de rutas, por qué un vecino directo lo aceptó, por qué las salvaguardas posteriores no lo contuvieron, por qué las alertas se dispararon o no, ni por qué la recuperación tardó el tiempo observado.

Los informes públicos deben distinguir hecho, inferencia y desconocido. Deben atribuir los recuentos de rutas, la duración, las descripciones de relación, los servicios afectados, las observaciones de reenvío y el tiempo de recuperación. Deben corregir los errores sin borrar el rastro de evidencia.

La prueba de rendición de cuentas es la propagación acotada y la recuperación verificable

El evento de Safe Host del 6 de junio de 2019 sigue siendo instructivo porque une la política técnica de enrutamiento con la consecuencia transfronteriza.

AS21217 exportó un conjunto extraordinario de rutas. AS4134 aceptó y propagó lo suficiente de ese conjunto para cambiar las rutas observadas y afectar la alcanzabilidad de partes de la infraestructura de red europea. Otras redes tomaron sus propias decisiones de aceptación y propagación. Los colectores públicos y los sistemas de medición conservaron parte del registro.

La evidencia no justifica una conclusión de intención maliciosa, un recuento universal de rutas, una única etiqueta comercial de relación incontestada ni una afirmación de que cada paquete fue inspeccionado o siguió físicamente la misma ruta. Esos límites forman parte del registro de rendición de cuentas.

La responsabilidad sigue siendo concreta. El exportador controlaba el conjunto de rutas. El importador directo controlaba la primera frontera de contención. Otras redes controlaban la propagación posterior y la resiliencia. Los operadores de monitoreo controlaban la evidencia. Los operadores de servicios controlaban la respuesta al impacto en los usuarios. Los usuarios finales sufrieron las consecuencias sin autoridad sobre el estado de BGP.

El conjunto de controles duradero es en capas: política explícita de importación y exportación, filtros de prefijos y rutas autorizados, evidencia de relación, controles de prefijos máximos, validación de origen, monitoreo de anomalías, cambios escalonados, contactos de coordinación nominados, observación independiente de rutas y retirada verificada.

Los registros y los registros de política de enrutamiento son libros de contabilidad indispensables. Identifican recursos, orígenes y contactos. No aplican una ruta. El código en ejecución determina la alcanzabilidad.

Un operador creíble debe poder demostrar, por tanto, cuatro cosas:

sabe qué rutas está autorizado y se espera que anuncie un vecino;
su política en ejecución rechaza o contiene anuncios más allá de ese alcance;
su monitoreo detecta cambios anómalos de ruta y de volumen con suficiente rapidez para que un propietario actúe; y
tras la contención, la evidencia independiente muestra que las retiradas se propagaron y que el reenvío esperado regresó.

Esa es la prueba de filtrado entre pares y de rendición de cuentas transfronteriza expuesta por la fuga de Safe Host. El estándar no es la prevención perfecta. Es la propagación acotada, el control asignado, la evidencia reproducible y una recuperación que pueda verificarse fuera de la red que hace la afirmación.

La fuga de rutas de Safe Host de 2019 convirtió el filtrado entre pares en una prueba de rendición de cuentas transfronteriza

Por qué importa