Fuga de rutas de Indosat 2014: controles de exportación

Resumen

El límite del evento es estrecho:Este artículo cubre el origen indebido masivo de AS4761 observado el 2 de abril de 2014, aproximadamente entre las 18:26 y las 21:15 UTC. Excluye un incidente anterior de Indosat en 2011, anomalías posteriores de AS4761 y otros incidentes de enrutamiento de Indonesia no relacionados.
La cifra principal necesita un observador:BGPMon informó de 417 038 orígenes nuevos, mientras que RIPE NCC describió más de 400 000 prefijos afectados. Esas mediciones establecen una escala extraordinaria en puntos de observación identificados. No prueban que todas las redes instalaran todas las rutas ni que reenviaran tráfico a través de Indosat.
La causa raíz sigue siendo una atribución:Los relatos contemporáneos describieron un problema operativo y repetidos informes de una ventana de mantenimiento fallida o de un proveedor ascendente sin filtros. La configuración completa de Indosat, el registro de cambios, el estado de generación de políticas y el informe interno del incidente no son públicos.
La responsabilidad sigue al control del enrutamiento:Indosat controlaba lo que AS4761 originaba y exportaba. Los vecinos directos controlaban los filtros de prefijos, de origen, de relación y de límite máximo de prefijos. Otros sistemas autónomos controlaban la aceptación, la preferencia, la exportación posterior, la supervisión y la escalada.
Los registros documentan la autoridad; los enrutadores aplican la alcanzabilidad:Los registros de ASN y de recursos numéricos identifican a los titulares y los orígenes esperados. RIS, RouteViews y otros recolectores conservan el estado operativo seleccionado. Ni una entrada de registro ni un recolector bloquean automáticamente un anuncio.
La autorización de origen y la política de rutas son distintas:La validación de origen de ruta puede rechazar un origen que contradiga una ROA válida, cuando existen los registros y la validación pertinentes. Por sí sola no demuestra que una ruta de relación o un volumen de rutas sean adecuados.
La recuperación no es una simple declaración de configuración local:Un cierre creíble muestra retiros, orígenes de reemplazo, convergencia en múltiples puntos de observación independientes, excepciones residuales, políticas modificadas, comportamiento del límite máximo de prefijos probado y evidencia de repetición de que la misma clase de fallo está ahora contenida.
El estándar de rendición de cuentas es una contención reproducible:Los operadores deben poder mostrar el conjunto de rutas autorizado, la política generada y en ejecución, el delta anómalo, la primera oportunidad de contención, la cronología de las acciones y una prueba independiente de recurrencia.

Congelar el incidente antes de interpretarlo

La primera disciplina de la rendición de cuentas en el enrutamiento es definir exactamente qué evento se está examinando. El 2 de abril de 2014, observadores públicos de BGP informaron de que AS4761, asociado a Indosat, comenzó a originar un número extraordinario de prefijos que normalmente originaban otros sistemas autónomos. BGPMon contó 417 038 prefijos nuevos y situó el intervalo visible aproximadamente entre las 18:26 y las 21:15 UTC.

El análisis de RIPE NCC describió más de 400 000 prefijos afectados y utilizó datos del Servicio de Información de Enrutamiento de RIPE y visualizaciones de RIPEstat para reconstruir ejemplos de propagación y alcanzabilidad. [1][2]

Esas observaciones bastan para establecer un evento grave de enrutamiento interdominio. No bastan para establecer todas las afirmaciones que podrían asociársele.

Este artículo no combina el evento de abril de 2014 con un evento de enrutamiento anterior de Indosat en 2011. No incorpora anomalías posteriores de AS4761 ni otros incidentes que afectaran a redes indonesias. No infiere un defecto operativo continuo a partir de eventos separados por años. Esa agregación podría construir una narrativa más amplia, pero debilitaría la evidencia necesaria para asignar controles, medir correcciones y comprobar recurrencias.

El evento delimitado comienza con los primeros orígenes anómalos de AS4761 observados por los monitores citados en torno a las 18:26 UTC. Incluye su propagación por redes seleccionadas, los cambios de alcanzabilidad visibles desde puntos de observación concretos, la detección y la comunicación entre operadores, el retiro de los orígenes anómalos y el retorno hacia el estado de rutas esperado. Termina con las últimas observaciones relevantes en torno a las 21:15 UTC, reconociendo que distintos recolectores pueden ver horas de inicio y fin diferentes.

Este límite también restringe la afirmación sobre la causa raíz. BGPMon caracterizó la escala como compatible con un problema operativo y se refirió a informes de una ventana de mantenimiento fallida. Los debates entre operadores mencionaron un proveedor ascendente sin filtros. [2][3] Se trata de descripciones contemporáneas, no de un registro forense publicado con el comando exacto, el mecanismo de redistribución de rutas, el estado del compilador de políticas, la decisión de aprobación o el comportamiento del dispositivo que creó los anuncios.

Un análisis responsable comienza, por tanto, con lo que la red en funcionamiento expuso: AS4761 apareció como origen de cientos de miles de prefijos; los orígenes anómalos fueron visibles más allá de la red de origen; algunas rutas y la alcanzabilidad cambiaron; y los orígenes se retiraron posteriormente. Trata la intención, la causa interna y la reparación completa como desconocidas salvo que existan pruebas adicionales.

Esa distinción no es cautela por sí misma. Crea un problema reparable. Una afirmación como «un error de mantenimiento causó un secuestro global» es demasiado amplia para comprobarla. Una afirmación como «AS4761 exportó un conjunto de rutas radicalmente superior a sus orígenes autorizados esperados, los vecinos directos aceptaron una parte suficiente de ese conjunto para propagarlo y la evidencia pública no muestra el conjunto completo de controles que posteriormente impidieron la recurrencia» identifica límites observables y registros ausentes.

El recuento de rutas es una medición, no un mapa de cada decisión de reenvío

El número 417 038 es central en el registro público porque transmite la escala extraordinaria del evento. También debe permanecer ligado a su fuente y método. BGPMon informó de ese recuento como orígenes nuevos asociados a AS4761. RIPE NCC utilizó la formulación más amplia de más de 400 000 prefijos afectados. [1][2] Las cifras son lo bastante cercanas como para corroborar una anomalía a escala de tabla completa, pero ninguna de las dos debe presentarse como un recuento universal instalado por todos los sistemas autónomos.

BGP es un protocolo de control distribuido. Un recolector de rutas recibe actualizaciones seleccionadas de sus pares participantes. Su registro refleja qué rutas decidieron exportar esos pares al recolector, en qué momento y conforme a sus propias políticas. Otro recolector con pares diferentes puede ver un subconjunto distinto, una primera marca temporal distinta y una secuencia de retiros distinta.

En la información sobre incidentes se suelen mezclar varias magnitudes:

la cantidad de prefijos únicos para los que se observó un origen anómalo;
la cantidad de mensajes de actualización BGP;
la cantidad de variantes de ruta;
la cantidad de recolectores o pares que vieron una actualización;
la cantidad de redes que seleccionaron la ruta anómala como mejor ruta;
la cantidad de tablas de reenvío que la instalaron;
el volumen de tráfico transportado por esas rutas; y
la cantidad de usuarios que sufrieron pérdida, retardo, desvío o ningún efecto visible.

No son intercambiables. Un prefijo puede generar muchas actualizaciones. Un recolector puede ver una ruta que su par no utilizó para todo el tráfico. Una red puede aceptar una ruta en una base de información de enrutamiento sin seleccionarla. Una ruta seleccionada puede afectar solo al tráfico de ciertos orígenes porque las rutas de Internet son asimétricas y dependen de políticas. Un servicio puede seguir siendo alcanzable por una ruta alternativa mientras otra red pierde el acceso.

El recuento sigue respaldando una conclusión de control sólida. AS4761 solía estar asociado a un conjunto de rutas pequeño en relación con la tabla global. Un aumento observado hasta más de 400 000 orígenes fue muy superior a cualquier margen de crecimiento ordinario. Un vecino directo no necesitaba un recuento global perfecto para reconocer que el conjunto recibido se había alejado del contrato esperado de cliente, par o proveedor.

Por eso la rendición de cuentas debe centrarse en el conjunto de rutas esperado y en el delta observado. El responsable de una sesión debería poder decir cuántos prefijos y orígenes estaban autorizados inmediatamente antes de un cambio, qué aumento se esperaba, qué umbrales de aviso y límites estrictos se aplicaban y qué ocurrió cuando el conjunto recibido o anunciado los superó.

Una medición reproducible del incidente documentaría los nombres de los recolectores, sus pares, las familias de direcciones, los intervalos UTC exactos, las reglas de deduplicación, el recuento de prefijos frente al de actualizaciones y el predicado de ruta AS utilizado para identificar las rutas afectadas. Conservaría las referencias de actualización en bruto o los comandos de extracción. El propósito no es producir una cifra perfecta. Es permitir que otro operador reproduzca la escala, la cronología y los límites de propagación sin confiar en un titular no examinado.

El origen indebido es visible; la intención no

En condiciones normales, un sistema autónomo de origen indica que puede entregar tráfico para un prefijo anunciado. Durante el evento de abril de 2014, AS4761 apareció como origen de prefijos normalmente asociados a muchas otras redes. Ese comportamiento suele describirse como un secuestro porque el origen cambió a un sistema autónomo que no se esperaba que originara el espacio de direcciones. BGPMon utilizó el lenguaje de secuestro en su informe contemporáneo. [2]

El estado de origen observable no establece una intención maliciosa. Un secuestro de rutas malicioso, una redistribución accidental, una asociación de política incorrecta, un error de servidor de rutas, una fuga de prueba y un procedimiento de mantenimiento fallido pueden producir síntomas superpuestos en el plano de control. Distinguirlos requiere configuración interna, registros, autorizaciones, testimonios de operadores y, con frecuencia, evidencia de tráfico o seguridad que los recolectores públicos no poseen.

La escala de este evento es compatible con un fallo operativo amplio. Es una inferencia, no un informe completo de causa raíz. Por tanto, el artículo atribuye las explicaciones de mantenimiento y filtrado a los observadores contemporáneos y no afirma que se haya probado un comando exacto o una acción concreta del operador.

Este límite importa tanto para la equidad como para la calidad técnica. Si un evento accidental se describe como una interceptación intencionada sin evidencia, el relato se debilita jurídica y técnicamente. Si el mismo evento se despacha como «solo un error», desaparece el fallo de los controles en múltiples límites de enrutamiento. La rendición de cuentas no exige acusación ni excusa. Exige un registro de lo que se permitió ejecutar.

Las preguntas sobre la evidencia son concretas:

¿Qué proceso suministró los prefijos que originó AS4761?
¿Qué política permitió que esos orígenes entraran en un anuncio externo?
¿Se generó el conjunto de rutas a partir de un inventario autorizado o se heredó de otra sesión?
¿Pasó el cambio por revisión, simulación o despliegue canario?
¿Qué instantánea de rutas anunciadas existía antes y después del cambio?
¿Qué vecino directo aceptó primero el conjunto anómalo?
¿Qué alertas se dispararon, quién era responsable de ellas y qué acción siguió?
¿Qué datos demostraron que el retiro y la normalización estaban completos?

El registro público solo responde partes de esta lista. Esa incompletitud debe registrarse como una brecha de rendición de cuentas, no rellenarse con especulación.

La red de origen es dueña del primer límite de exportación

AS4761 controlaba el límite del lado del origen. Independientemente del desencadenante interno, el sistema de enrutamiento en funcionamiento de Indosat originó y exportó un conjunto de rutas que excedía radicalmente el alcance esperado asociado al sistema autónomo. La primera obligación es, por tanto, definir y aplicar qué estaba autorizado a originar y anunciar AS4761.

Un inventario de orígenes autorizado debería conectar los registros de recursos numéricos, las delegaciones de clientes, los registros internos de servicio, los datos del registro de enrutamiento y las excepciones explícitas. Debería tener versión, responsable, historial de aprobación y fecha de entrada en vigor. La política generada del enrutador debería estar vinculada por suma de comprobación a ese inventario, de modo que un auditor pueda distinguir la entrada prevista de la configuración realmente desplegada.

El contrato de exportación debería responder a cuatro preguntas distintas:

¿Qué prefijos puede originar AS4761 por sí mismo?
¿Qué prefijos de clientes puede transportar AS4761 como tránsito?
¿Qué rutas aprendidas de proveedores o pares pueden volver a anunciarse, y a quién?
¿Qué excepciones temporales existen, por qué existen y cuándo expiran?

Combinar estos conjuntos en un único filtro permisivo crea las condiciones para una exportación de tabla completa. Una ruta aprendida de un proveedor, una tabla de enrutamiento completa usada internamente o una alimentación amplia de un servidor de rutas pueden cruzar una sesión externa si falta la política de exportación, está asociada en la dirección equivocada, se genera a partir de datos incorrectos o se omite mediante una excepción.

Los valores predeterminados de política explícita reducen este riesgo. El RFC 8212, publicado años después del incidente, especifica que las rutas eBGP no deben importarse ni exportarse sin una política explícita. [8] No debe proyectarse hacia atrás como prueba de la implementación de Indosat en 2014. Es útil como comparación duradera: una sesión debería fallar de forma cerrada cuando falta la política prevista, en lugar de intercambiarlo todo hasta añadir un filtro.

El exportador también necesita un control de volumen de rutas sobre su propio conjunto anunciado. El límite máximo de prefijos suele tratarse como una función de entrada, pero los operadores pueden supervisar el recuento y el delta de rutas de salida antes de que las actualizaciones salgan de una red. Una comprobación previa al despliegue puede comparar los anuncios candidatos con el conjunto autorizado. Una salvaguarda en vivo puede alarmar o bloquear un aumento que no tenga un registro de cambio aprobado.

La evidencia más valiosa es la diferencia entre el estado esperado y el estado en ejecución. Una declaración posterior al incidente de que «se añadieron filtros» no basta. Un registro responsable conservaría:

el conjunto autorizado de prefijos y orígenes antes del evento;
la fuente de configuración y la política generada;
los hashes de la configuración candidata y confirmada del dispositivo;
instantáneas de rutas anunciadas de la sesión afectada;
el conjunto anómalo y cómo entró en el procesamiento de exportación;
los comandos de retiro o el cambio de política;
el conjunto autorizado después de la recuperación; y
una repetición que demuestre que el conjunto anómalo se rechaza.

Esta evidencia convierte una narrativa de configuración en una prueba de control. También impide que una limpieza posterior de políticas oculte lo que realmente se estaba ejecutando durante el evento.

Los vecinos directos tienen la primera oportunidad de contención externa

La red de origen no es el único operador con control. Un vecino directo que recibía un conjunto de rutas de AS4761 tenía la primera oportunidad externa de contenerlo. Ese vecino conocía, o debería haber documentado, el tipo de relación, el conjunto de prefijos esperado, el volumen ordinario de rutas y el contacto de escalada de la sesión.

El registro público indica que gran parte de la visibilidad anómala de rutas llegó a través de proveedores de Tailandia, y que algunas rutas se propagaron más lejos. [1][2] Las relaciones comerciales y técnicas completas no son públicas, por lo que cada etiqueta específica de cliente, par o proveedor debe usarse solo cuando esté respaldada. El principio de control no depende de una etiqueta en disputa. Cualquier vecino que aceptara un conjunto de rutas radicalmente fuera del alcance bilateral esperado controlaba un límite de importación.

Allí pueden operar varias salvaguardas.

El filtrado de prefijoscompara las rutas recibidas con un inventario autorizado de cliente o vecino. Es más eficaz cuando el conjunto de rutas bilateral está acotado y cuando las actualizaciones del inventario tienen responsable y plazo.

El filtrado o la validación de origencomprueba si el origen está autorizado para un prefijo. La validación de origen de rutas basada en RPKI puede aportar autorización criptográfica cuando existe una ROA que cubra el prefijo y hay validadores desplegados. No es la única fuente de evidencia de origen y en 2014 estaba mucho menos extendida.

La política de rutas AS y de relacionescomprueba si la ruta es plausible para la sesión. Un cliente no debería, por regla general, proporcionar tránsito entre proveedores ascendentes no relacionados. Las relaciones reales pueden ser complejas, por lo que la política necesita excepciones explícitas en lugar de suponer que cualquier ruta es aceptable.

Los controles de prefijos máximoscomparan el volumen de rutas recibido con un rango documentado. Una sesión normalmente asociada a cientos o miles de rutas no debería entregar silenciosamente cientos de miles. Los límites de aviso y los límites estrictos necesitan respuestas operativas distintas, y ambos requieren un responsable.

Los valores predeterminados de importación explícitosimpiden que una sesión nueva o mal clasificada lo acepte todo porque falta un mapa de rutas.

Los controles de exportación posteriorseparan lo que una red recibe de lo que anuncia a clientes, pares y proveedores. Una ruta conservada para diagnóstico no necesita propagarse.

El RFC 7454 describe el filtrado operativo, los límites de prefijos máximos, los controles de bogon y otras prácticas de seguridad BGP. [9] La publicación NIST SP 800-189 organizó posteriormente las prácticas de intercambio de tráfico interdominio resiliente, incluidos filtrado, validación de origen de ruta, supervisión y coordinación. [13] MANRS enmarca de manera similar el filtrado, la lucha contra la suplantación, la coordinación y la información de enrutamiento como acciones del operador.

[14] Son puntos de comparación modernos, no evidencia de que todas las salvaguardas estuvieran disponibles o desplegadas en las sesiones pertinentes de 2014.

La pregunta al vecino directo no es «¿por qué Internet confió en BGP?», sino «¿por qué una política bilateral en ejecución aceptó este conjunto, y qué evidencia muestra ahora que el mismo conjunto sería rechazado o puesto en cuarentena?»

El control de prefijos máximos es necesario, pero una cifra por sí sola no es una política

El extraordinario volumen de rutas convierte la protección de prefijos máximos en un control obvio. También es fácil describirla con excesiva simpleza. Un límite estricto puede contener una fuga masiva, pero un límite mal elegido puede desconectar clientes legítimos, dispararse durante un crecimiento normal o incitar a los operadores a fijar umbrales tan altos que nunca actúen.

Un diseño responsable de prefijos máximos comienza por el conjunto autorizado. El umbral debe reflejar las rutas actuales, el crecimiento documentado, el comportamiento de agregación, los anuncios de respaldo y las excepciones aprobadas. No debe ser una fracción genérica de la tabla global ni un valor copiado de otra relación.

Un diseño maduro tiene al menos tres estados:

un rango operativo normal;
un rango de aviso que alerta a un canal de respuesta con responsable y congela los cambios arriesgados; y
un umbral de contención estricto con una acción documentada.

La acción estricta puede variar. Un enrutador puede rechazar prefijos adicionales, derribar la sesión, poner en cuarentena el conjunto recibido, reducir la preferencia o invocar automatización. Cada elección tiene consecuencias. Rechazar rutas nuevas puede preservar la alcanzabilidad establecida mientras se bloquea el crecimiento. Reiniciar una sesión puede crear una interrupción mayor. Seguir aceptando rutas mientras solo se envía una alerta puede fallar en abierto durante el periodo en que la propagación más importa.

Por tanto, la respuesta debe probarse. Los operadores deberían reproducir un conjunto de rutas parecido al fallo de abril de 2014 y registrar si el dispositivo avisa, rechaza, reinicia o continúa. Deberían probar tanto un aumento repentino a escala de tabla completa como una fuga más lenta diseñada para quedar por debajo de una alerta basada en tasa. Deberían verificar que la escalada llega a un responsable con dotación y que ese responsable tiene autoridad para contener la sesión.

El límite de prefijos máximos también necesita protección contra la deriva de excepciones. Los aumentos de emergencia y las migraciones puntuales pueden volverse permanentes. Cada anulación debe tener motivo, aprobador, intervalo de vigencia y caducidad o revisión automática. El umbral en ejecución debe ser visible en la evidencia del incidente junto al recuento de rutas autorizado.

La pregunta de rendición de cuentas no es si una configuración contiene una instrucciónmaximum-prefix. Es si el umbral corresponde al contrato de relación, si la respuesta es segura, si las alarmas tienen responsable y si una repetición demuestra la contención.

La autorización de origen y la autorización de rutas resuelven problemas distintos

El evento de Indosat es un caso sólido a favor de la validación de origen porque AS4761 apareció como origen de prefijos asociados a muchas otras redes. Cuando una ROA válida autoriza un origen distinto y la red receptora realiza validación de origen de ruta, la ruta inesperada puede clasificarse como inválida y rechazarse o degradarse según la política.

El RFC 6811 especifica la validación de origen de prefijos BGP mediante RPKI. El RFC 6483 ofrece orientación sobre las operaciones de validación de origen. [10][11] Esos documentos explican el mecanismo, pero no prueban la cobertura de 2014, el estado de las ROA, la disponibilidad de validadores ni la política de enrutamiento de los vecinos de Indosat.

Deben permanecer explícitas tres limitaciones.

Primera, la cobertura de RPKI en 2014 era limitada. Una ruta sin una ROA que la cubra no es automáticamente inválida; generalmente es «no encontrada». El estado actual de las ROA no debe proyectarse hacia atrás sobre el evento.

Segunda, la validación de origen comprueba la relación entre un prefijo y su ASN de origen. No valida todas las relaciones de la ruta AS. Una ruta puede tener un origen autorizado y aun así fugarse a través de una ruta no prevista de proveedor, par o cliente.

Tercera, la validación solo modifica el enrutamiento cuando los operadores despliegan validadores, mantienen la disponibilidad de la caché, adjuntan políticas y deciden cómo tratar cada estado. Un registro de registro no se aplica por sí mismo.

El RFC 9234 introdujo posteriormente los roles BGP y el atributo Only-to-Customer para mejorar la prevención de fugas de rutas mediante señalización explícita de relación. [12] De nuevo, es una comparación de control moderna, no una descripción de la red de 2014. Los roles y OTC pueden ayudar a los enrutadores a detectar anuncios que violan las expectativas de relación sin valles, pero dependen del despliegue y de una configuración de roles correcta.

La arquitectura defendible dispone los controles por capas:

registros de recursos y orígenes para la autoridad esperada;
filtros de prefijos y de origen en los límites de cliente;
validación de origen de ruta donde existan datos;
políticas de importación y exportación conscientes de las relaciones;
roles BGP y OTC donde estén soportados;
contención de prefijos máximos y de delta de rutas;
política predeterminada explícita;
supervisión independiente de anomalías; y
coordinación y retiro probados.

Ningún control debe presentarse como una solución completa. El objetivo de rendición de cuentas es la defensa en profundidad con evidencia de que cada capa aborda un modo de fallo definido.

Los registros son libros de rendición de cuentas, no soberanos de la alcanzabilidad

Los registros de números de Internet, los registros de enrutamiento, las ROA y las bases de datos de operadores son superficies de evidencia esenciales. Ayudan a identificar a los titulares de recursos, la autoridad de origen, los contactos y las políticas esperadas. La vista AS4761 de RIPEstat ofrece una interfaz actual de registro y observaciones de enrutamiento, mientras que el análisis histórico debe vincular las afirmaciones al tiempo pertinente. [4]

Estos registros no determinan la alcanzabilidad en ejecución por declaración. Un enrutador acepta, rechaza, selecciona y exporta rutas según el software y la configuración desplegados. Un registro preciso puede coexistir con un filtro permisivo. Un registro inexacto u obsoleto puede hacer que un filtro generado rechace rutas legítimas. Una ROA firmada puede clasificar un origen, pero solo la política de una red que valida determina el resultado operativo.

Esta distinción respalda un modelo de rendición de cuentas basado en la realidad. Los registros deben evaluarse como libros de contabilidad:

¿Son precisos los registros de recursos y contactos?
¿Quedan registrados los cambios y son atribuibles?
¿Pueden los operadores derivar filtros de forma reproducible?
¿Son visibles las excepciones?
¿Están actualizados los metadatos de seguridad?
¿Puede otra red verificar el origen esperado?

Los enrutadores y los sistemas de políticas deben evaluarse como aplicación en ejecución:

¿Se desplegó realmente la política derivada?
¿Qué versión se ejecutó en la sesión afectada?
¿Rechazaba por defecto?
¿Aceptó el dispositivo el conjunto anómalo?
¿La exportación posterior conservó o amplificó el error?
¿Coincidía el estado en ejecución con la intención derivada del libro de contabilidad?

El evento de abril de 2014 no puede explicarse solo como un problema de registro ni solo como un problema de enrutador. Expuso la costura entre la autoridad registrada y la política ejecutable. Si los registros eran precisos pero faltaban filtros, falló la aplicación. Si la generación de políticas dependía de registros inexactos, tanto el libro como su uso operativo necesitan corrección. Si una redistribución amplia omitió la ruta de datos prevista, fallaron los controles de despliegue.

La evidencia necesaria para distinguir estos casos no es exótica. Incluye registros de recursos fechados, datos de origen de políticas, filtros generados, hashes de configuración, rutas recibidas y anunciadas, y observaciones independientes de recolectores. La ausencia de un registro conjunto de este tipo es en sí misma un hallazgo de rendición de cuentas.

La evidencia de los recolectores prueba observaciones seleccionadas, no una convergencia universal

RIPE RIS y RouteViews conservan datos históricos de BGP que hacen posible una reconstrucción independiente. RIPE describe RIS como un sistema de medición que recopila y almacena datos de enrutamiento de Internet. RouteViews archiva las actualizaciones de abril de 2014. [5][6] El BGPStream de CAIDA proporciona un marco para procesar datos BGP de los principales proyectos de recolección. [18]

Estos sistemas son infraestructura de rendición de cuentas porque conservan evidencia fuera de la red que causó o propagó un incidente. Permiten a los analistas comprobar si apareció un origen anómalo, qué rutas AS lo transportaron a determinados pares, cuándo se hicieron visibles los retiros y si regresaron los orígenes esperados.

Sus límites deben formar parte de toda afirmación.

Un recolector ve las rutas exportadas por sus pares. No ve todas las rutas que esos pares recibieron ni todas las alternativas que consideraron. Una marca temporal de primera observación es la primera observación en ese recolector, no necesariamente el primer anuncio en el origen. Un retiro observado en un par no prueba la convergencia global. Una mejor ruta visible en un recolector no prueba la ruta de reenvío de todos los usuarios.

La diversidad de recolectores mejora la confianza. Una reconstrucción del incidente debería comparar pares de RIS y RouteViews en redes y regiones distintas. Debería identificar si el origen anómalo fue visible desde cada punto de observación, cuánto tiempo permaneció visible, qué rutas lo transportaron y cuándo regresó el origen esperado. Las diferencias deberían conservarse en lugar de promediarse.

El análisis también necesita un predicado reproducible. Para este evento, un analista podría identificar actualizaciones en las que AS4761 sea el origen de prefijos fuera de su conjunto esperado. Deberían documentarse la fuente exacta del conjunto esperado, el tiempo, la familia de direcciones, la gestión de duplicados y la normalización de rutas. Los recuentos de rutas derivados deberían enlazar con intervalos o comandos de archivo en bruto.

Sistemas de investigación como BGPInspector muestran cómo pueden examinarse eventos históricos mediante múltiples dimensiones y vistas de evidencia. [15] Trabajos académicos posteriores sobre fugas y detección de rutas demuestran además que la clasificación depende de la topología, las relaciones y la observación. [16] Estas herramientas no sustituyen la telemetría del operador, pero hacen posible la impugnación independiente.

Por tanto, el cierre de un operador debería emparejar evidencia interna y externa. Las rutas internas recibidas y anunciadas explican lo que cruzó una sesión. Los recolectores externos muestran lo que escapó al sistema de enrutamiento más amplio. Ambos registros deberían converger en una cronología acotada sin perder la incertidumbre de cada punto de observación.

El impacto debe medirse como alcanzabilidad, no inferirse del volumen de rutas

La reconstrucción de RIPE NCC mostró que los efectos variaban según el punto de observación y la ruta. BGPMon informó de que muchas rutas anómalas eran visibles a través de proveedores de Tailandia y de que algunas se propagaron más ampliamente. [1][2] Esto respalda una conclusión de propagación desigual e impacto desigual en la alcanzabilidad.

No respalda la afirmación de que el evento redirigió la mayor parte del tráfico global de Internet a través de Indonesia. Un recuento cercano al tamaño de la tabla global puede sonar equivalente a controlar Internet, pero las decisiones de enrutamiento son distribuidas. Las redes aplican preferencia local, política de rutas AS, especificidad de prefijos, validación de origen y relaciones comerciales. Algunas conservan una ruta no afectada; otras prefieren el origen anómalo; otras nunca lo reciben.

El impacto debe medirse por capas:

Visibilidad del plano de control:¿Qué recolectores y pares vieron a AS4761 como un origen inesperado?

Selección de rutas:¿Qué redes seleccionaron la ruta, cuando esa información es observable?

Evidencia de reenvío:¿Desde qué ubicaciones de origen mostraron traceroute, looking glass o datos de flujo que el tráfico seguía una ruta modificada?

Rendimiento del servicio:¿Qué destinos sufrieron pérdida, latencia, inestabilidad o ninguna degradación observable?

Alcance de usuarios:¿Qué clientes, regiones o servicios resultaron afectados, según la telemetría del proveedor y no solo el recuento de rutas?

Consecuencia de seguridad:¿Hubo evidencia de acceso, inspección o alteración de paquetes? El registro público de rutas por sí solo no lo establece.

Esta división por capas evita tanto la exageración como la minimización. Evita tratar cada prefijo visible como una ruta de reenvío instalada globalmente. También evita descartar el incidente porque algunas redes mantuvieran la alcanzabilidad.

Para eventos futuros, los operadores deberían conservar mediciones activas, tablas de enrutamiento, resúmenes de flujo, estado de las aplicaciones y datos de impacto en clientes con marcas temporales sincronizadas. La metodología debe tener en cuenta rutas asimétricas, saltos ocultos, anycast, equilibrio de carga y geolocalización incompleta.

La medida clave de rendición de cuentas no es la mayor población afectada plausible. Es si cada operador puede conectar un estado de ruta anómalo con efectos concretos de alcanzabilidad, explicar la incertidumbre y mostrar cómo sus controles limitaron o no limitaron la propagación.

La supervisión solo tiene valor cuando está ligada a la acción

El evento fue visible para los monitores externos porque el cambio de origen y el volumen de rutas eran extraordinarios. Los sistemas públicos y las comunidades de operadores ayudaron a sacar a la luz la anomalía. Esa visibilidad no contiene por sí misma una fuga de rutas.

La supervisión debería conectar cuatro elementos:

una línea base que defina orígenes, prefijos, rutas y volumen de rutas esperados;
una regla de detección que explique por qué el estado observado es anómalo;
un responsable con autoridad y vías de contacto; y
una acción segura que pueda contener o retirar la ruta.

Una alerta que diga «AS4761 originó 417 038 prefijos nuevos» es útil para el triaje. Una alerta operativa debería añadir las sesiones afectadas, los recuentos recibidos y aceptados, el inventario esperado, los proveedores ascendentes observados, la versión actual de política, los cambios recientes y una acción de contención recomendada.

Debe conservarse el horario de las alertas. Una cronología completa distingue la primera actualización anómala, la primera observación del recolector, la primera alerta automatizada, la primera confirmación humana, el primer contacto con el origen o el ascendente, la primera acción de contención, el primer retiro y la normalización posterior. Esas marcas temporales revelan si el retardo fue de detección, escalada, autoridad, diagnóstico o convergencia.

Los datos de coordinación también importan. Los incidentes de enrutamiento cruzan fronteras organizativas. Los contactos deben estar vigentes, ser alcanzables y tener capacidad de decisión. MANRS trata la validación global y la coordinación como una responsabilidad central del operador. [14] Un registro de contacto que existe pero no llega a un responsable operativo no es un control que funcione.

La automatización puede acelerar la contención, pero necesita barandillas. Un cierre automático de sesión basado en un falso positivo puede crear una interrupción. Una alerta que falla en abierto puede permitir que una fuga de tabla completa se propague mientras los humanos investigan. Un diseño acotado puede poner en cuarentena rutas nuevas, congelar cambios, reducir preferencia o exigir confirmación bajo umbrales definidos.

El evento prueba, por tanto, algo más que la detección de anomalías. Prueba si la observación se convierte en acción responsable con la rapidez suficiente para importar.

El retiro inicia la recuperación; no prueba el cierre

Los relatos públicos indican que los orígenes anómalos se retiraron después de varias horas y que el estado de rutas volvió a acercarse a los orígenes esperados. [1][2] El retiro es esencial, pero es solo el comienzo de un registro de recuperación.

La convergencia BGP depende del observador. Las redes reciben y procesan los retiros en momentos distintos. Algunas pueden conservar rutas obsoletas, rutas anómalas alternativas o estado de sesión durante más tiempo que otras. La amortiguación de rutas inestables, los reinicios de sesión, la política local y la visibilidad del recolector pueden alterar la hora de fin aparente.

Un registro de recuperación creíble debería mostrar:

el conjunto exacto de rutas objetivo del retiro;
el comando, cambio de política o acción de sesión utilizado;
quién lo autorizó;
cuándo lo recibieron los vecinos afectados;
cuándo se normalizaron los recuentos internos de rutas recibidas, seleccionadas y anunciadas;
cuándo varios recolectores independientes dejaron de ver a AS4761 como origen inesperado;
cuándo reaparecieron los orígenes esperados;
qué excepciones residuales quedaron; y
si la alcanzabilidad de cara al usuario se recuperó en la misma cronología.

El registro debería separar el retiro de rutas de la reparación de configuración. Un operador puede retirar rutas incorrectas manualmente dejando intacto el mecanismo de fallo. A la inversa, un cambio de configuración puede ser correcto localmente mientras rutas obsoletas o alternativas siguen visibles en otros lugares.

La recuperación también necesita una línea base conocida y correcta. «Normal» debería significar un estado de origen y ruta autorizado vinculado por suma de comprobación, no la mera ausencia de una alarma actual. Si el conjunto autorizado cambió durante el incidente, el cambio debería documentarse en lugar de ocultarse dentro del cierre.

La evidencia independiente es especialmente valiosa porque comprueba afirmaciones fuera de la red de origen. RIS, RouteViews, los looking glass y los operadores afectados pueden mostrar si los orígenes anómalos desaparecieron desde distintos puntos de observación. Sus observaciones no serán perfectamente simultáneas, y esa variación debería formar parte del registro.

El registro público no proporciona un informe de reparación firmado completo, una reproducción de rutas ni un inventario de excepciones para el evento de 2014. La ausencia no prueba que no hubiera reparación. Significa que los observadores externos no pueden verificar la durabilidad de la reparación con la evidencia disponible.

Una prueba de recurrencia debe reproducir la clase de fallo sin exportarla

El cierre más sólido es una prueba de recurrencia controlada. No envía cientos de miles de rutas no autorizadas a la Internet pública. Recrea la clase de fallo en un laboratorio, simulador de políticas, sistema de reproducción de rutas o sesión aislada, y demuestra que cada límite previsto responde correctamente.

La prueba debería comenzar con un conjunto esperado congelado para la relación de AS4761. Luego debería introducir:

un origen no autorizado;
un lote pequeño de prefijos no autorizados;
un conjunto a escala de tabla completa;
un aumento gradual diseñado para evadir un detector de picos súbitos;
una ruta que viole la relación documentada;
una excepción caducada;
una política explícita ausente;
un registro obsoleto o de cliente obsoleto; y
un retiro seguido de un intento de reanuncio.

Para cada caso, el registro debería mostrar el filtro generado, la configuración candidata, el resultado del dispositivo o simulador, la alerta, la confirmación del responsable, el comportamiento de contención y la evidencia exportada a la supervisión independiente.

La prueba debería ejecutarse tanto en el límite de origen como en el del vecino. El exportador debería rechazar o impedir el anuncio no autorizado. El vecino directo debería rechazar o poner en cuarentena un conjunto que cruce el alcance bilateral. La política de exportación posterior debería impedir que rutas de diagnóstico aceptadas se extiendan más.

Los controles negativos son importantes. El sistema debe seguir aceptando el crecimiento legítimo de clientes, rutas de respaldo autorizadas y cambios de mantenimiento documentados. De lo contrario, un filtro estricto puede convertirse en un riesgo de disponibilidad y los operadores lo omitirán.

La prueba de recurrencia debería repetirse cuando cambien el inventario de enrutamiento, los generadores de políticas, el software del enrutador, la topología o las relaciones. Una prueba superada en un entorno no demuestra que todas las sesiones de producción sigan protegidas.

Este enfoque cambia la pregunta de rendición de cuentas de «¿prometió el operador tener cuidado?» a «¿puede el operador reproducir el fallo y demostrar que sus controles actuales en ejecución lo contienen?»

Los controles modernos deben usarse como comparaciones, no como afirmaciones retroactivas

Varios estándares y marcos operativos publicados antes o después de 2014 proporcionan un mapa de control útil.

El RFC 7908 define categorías de fugas de rutas y terminología. [7] Su taxonomía ayuda a separar la propagación no intencionada del secuestro de origen, pero aplicar un tipo de fuga concreto requiere conocer relaciones que pueden no ser públicas.

El RFC 8212 promueve políticas explícitas de importación y exportación eBGP. [8] Aborda el valor predeterminado peligroso por el que las rutas fluyen cuando falta la política prevista.

El RFC 7454 describe prácticas de seguridad BGP que incluyen filtros, prefijos máximos, gestión de bogon y protecciones operativas. [9]

Los RFC 6811 y 6483 abordan la validación de origen de rutas mediante RPKI. [10][11] Ayudan a comprobar si un origen está autorizado, pero no establecen la idoneidad de la ruta completa.

El RFC 9234 añade los roles BGP y OTC para apoyar la prevención de fugas de rutas mediante señalización de relación. [12]

La publicación NIST SP 800-189 enmarca el intercambio de tráfico interdominio resiliente en torno al filtrado, RPKI, supervisión, seguridad y coordinación. [13]

MANRS identifica acciones del operador para filtrado, lucha contra la suplantación, coordinación y validación global. [14]

Las herramientas de investigación y medición añaden análisis independiente. BGPInspector ilustra la inspección multidimensional de incidentes, investigaciones posteriores sobre fugas de rutas examinan la detección y clasificación, RIPEstat conecta vistas de registro y enrutamiento, y BGPStream facilita el procesamiento reproducible. [15][16][17][18]

La disciplina histórica es esencial: estos documentos no prueban lo que Indosat o sus vecinos tenían desplegado el 2 de abril de 2014. Algunos controles eran inmaduros, poco comunes o aún no estaban estandarizados. Una comparación moderna puede identificar qué reduciría la recurrencia hoy sin reescribir la historia.

El objetivo de control por capas es estable en el tiempo: definir la autoridad, restringir la exportación, validar la importación, limitar el alcance de las relaciones, detectar volumen anómalo, preservar evidencia independiente, coordinar la respuesta, retirar de forma segura y probar la recurrencia.

La rendición de cuentas debe asignarse por límites, no diluirse en todo Internet

Los incidentes interdominio afectan a muchas redes, lo que puede hacer que la responsabilidad parezca colectiva y, por tanto, vaga. Un modelo mejor asigna deberes según el control.

Indosat / AS4761controlaba el estado de origen y exportación. Su carga de evidencia incluye el conjunto autorizado de orígenes, la fuente de política, la configuración generada y en ejecución, el registro de cambios, las rutas anunciadas, la acción de retiro y la prueba de recurrencia.

Los vecinos directoscontrolaban la primera aceptación externa. Su carga incluye documentación de relación, filtros de prefijos y de origen, umbrales de prefijos máximos, política de importación, política de exportación posterior, gestión de alertas y evidencia de contención.

Otros sistemas autónomoscontrolaban su propia aceptación, preferencia, propagación, supervisión y comunicación con clientes. Podían tener menos información específica de relación, pero seguían siendo dueños de su política en ejecución.

Los registros de números y de enrutamientocontrolaban la precisión, disponibilidad y auditabilidad de los registros de recursos y políticas dentro de su alcance. No controlaban la aplicación en los enrutadores.

Los operadores de supervisión y los investigadorescontrolaban la calidad de la medición, las marcas temporales, la retención, la metodología y los límites de las afirmaciones públicas. Podían exponer el evento, pero no retirar rutas.

Los proveedores de servicio y accesocontrolaban la resiliencia, la diversidad de rutas, la medición de impacto y la comunicación con los clientes afectados por sus redes.

Los clientes y usuarios finalespor lo general no tenían control práctico sobre la aceptación de rutas interdominio. No deberían cargar con la tarea de descubrir o reparar un fallo de política de un proveedor.

Esta asignación evita dos errores. Impide que el operador de origen trate la propagación posterior como problema de otros. También impide que otras redes afirmen que cualquier ruta recibida de un vecino es responsabilidad exclusiva del originador.

El primer límite evitable merece atención especial. Si el exportador podía haber detenido la ruta, su fallo es primario. Si un vecino directo tenía un contrato de rutas esperado y aceptó una tabla completa aun así, se trató de un fallo de contención separado. Si redes posteriores podían detectar una ruta o un volumen implausibles y no lo hicieron, sus controles también requieren examen.

El control distribuido crea deberes múltiples, no ausencia de deberes.

La gobernanza debe exigir evidencia sin fingir que la topología privada es pública

Parte de la evidencia de enrutamiento es necesariamente privada: contratos, configuraciones completas, topología, controles de seguridad y datos de clientes. La rendición de cuentas no exige divulgación indiscriminada. Exige suficiente evidencia independiente verificable para respaldar afirmaciones sobre control y recuperación.

Los operadores pueden publicar o compartir atestaciones acotadas:

el rango esperado de recuento de rutas sin revelar cada cliente;
hashes de inventarios autorizados y filtros generados;
confirmación de que hay políticas explícitas de importación y exportación adjuntas;
comportamiento de aviso y límite estricto de prefijos máximos;
marcas temporales de alertas, contención y retiro;
referencias de recolectores independientes;
resultados de pruebas de repetición de tabla completa y violación de relación;
el número y tipo de excepciones;
el responsable y el proceso de caducidad de esas excepciones; y
una declaración de brechas de evidencia sin resolver.

Los reguladores, clientes, pares y aseguradores deberían pedir estos artefactos en lugar de garantías amplias. El lenguaje contractual puede exigir notificación, retención de evidencia, pruebas de políticas de rutas, contactos vigentes y contención coordinada.

La divulgación debería distinguir hechos, inferencias y desconocidos. En el evento de Indosat, el estado de origen masivo y el amplio intervalo temporal son hechos sólidos. Una explicación de mantenimiento o filtrado es un relato atribuido. El mecanismo interno exacto y la reparación completa siguen siendo desconocidos en el registro público.

Este formato protege la confidencialidad legítima y, al mismo tiempo, hace impugnables las afirmaciones operativas. También posibilita la comparación entre incidentes. Un operador que puede aportar una diferencia reproducible de conjuntos de rutas y un resultado de repetición tiene evidencia más sólida que uno que solo ofrece una etiqueta de causa raíz.

La gobernanza no debe convertir los registros en autoridades centrales imaginarias sobre el enrutamiento. Los registros numéricos, las ROA, los objetos IRR y los contactos son insumos críticos. La alcanzabilidad sigue siendo el resultado de una política distribuida en ejecución. Por tanto, una supervisión eficaz comprueba la conexión entre la autoridad registrada y el comportamiento desplegado.

El evento de abril de 2014 fue una prueba de control de tabla completa

La lección más duradera del evento de AS4761 no es que BGP se base en la confianza ni que un operador cometiera un gran error. Esas afirmaciones son demasiado generales para asignar una reparación.

El evento puso a prueba si una red podía impedir que un conjunto de orígenes no autorizado a escala de tabla completa saliera de su límite. Puso a prueba si los vecinos directos podían comparar las rutas recibidas con una expectativa bilateral y contener una desviación radical. Puso a prueba si las redes posteriores podían evitar amplificar el estado. Puso a prueba si los monitores podían ofrecer evidencia precisa y ligada al observador. Puso a prueba si el retiro y la normalización podían probarse en lugar de afirmarse.

La evidencia pública establece que más de 400 000 orígenes inesperados asociados a AS4761 se hicieron visibles el 2 de abril de 2014 y se retiraron después de varias horas. Respalda una propagación y unos efectos de alcanzabilidad desiguales. No establece intención maliciosa, reenvío universal, una causa interna completa ni un programa de reparación verificable públicamente.

Una respuesta responsable del operador cerraría esas brechas con:

un inventario congelado de prefijos y orígenes autorizados;
políticas explícitas de importación y exportación de rechazo por defecto;
filtros generados de prefijos y de origen;
controles de ruta conscientes de las relaciones;
aviso de prefijos máximos y contención estricta;
validación de origen de ruta donde existan datos pertinentes;
excepciones controladas con responsable y caducidad;
supervisión independiente desde múltiples puntos de observación;
un registro fechado de contención y retiro; y
una repetición que demuestre que la misma clase de fallo se rechaza en los límites de origen y de vecino.

El estándar no es la perfección. El enrutamiento interdominio es distribuido, las relaciones cambian, los registros pueden quedarse atrás y la visibilidad es incompleta. El estándar es que cada operador pueda identificar el límite que controla, mostrar qué política se ejecutó allí, explicar qué se desvió de lo esperado, actuar dentro de un proceso probado y aportar evidencia de que el estado autorizado de rutas regresó.

Esa es la diferencia entre un incidente que simplemente termina y un incidente que produce rendición de cuentas.

Fuentes

[1]RIPE NCC Labs, «Fugas de BGP en Indonesia»

[2]BGPMon, «Evento de secuestro de hoy por Indosat»

[3]Archivo de la lista de correo RIPE BCOP, debate de operadores de abril de 2014

[4]RIPEstat, AS4761

[5]RIPE NCC, Servicio de Información de Enrutamiento

[6]RouteViews, archivo de actualizaciones BGP de abril de 2014

[7]RFC 7908, Definición del problema y clasificación de las fugas de rutas BGP

[8]RFC 8212, Comportamiento predeterminado de propagación de rutas BGP externas sin políticas

[9]RFC 7454, Operaciones y seguridad BGP

[10]RFC 6811, Validación de origen de prefijos BGP

[11]RFC 6483, Validación del origen de rutas mediante RPKI y ROA

[12]RFC 9234, Prevención y detección de fugas de rutas mediante roles en mensajes UPDATE y OPEN

[13]NIST SP 800-189, Intercambio resiliente de tráfico interdominio

[14]MANRS, Acciones para operadores de red

[15]Universidad de Oregón, informe de investigación BGPInspector

[16]arXiv, investigación sobre detección de fugas de rutas

[17]RIPE 68, presentación de RIPEstat

[18]Documentación de CAIDA BGPStream

La fuga de rutas de Indosat en 2014 convirtió los controles de exportación de la tabla completa en una prueba de rendición de cuentas