Resumen

  • Los análisis públicos vincularon a Vodafone Idea AS55410 con un conjunto extraordinariamente grande de anuncios de origen observados el 16 de abril de 2021.
  • Catchpoint informó que, a las 13:48:58 GMT, AS55410 aparecía como origen de más de 34.000 redes. La cifra, la unidad y la hora pertenecen a esa observación publicada.
  • Catchpoint también describió aproximadamente 225.000 mensajes de actualización BGP entre las 13:45 y las 15:00 GMT en RIPE RIS rrc00, y señaló que 64 de sus 73 pares recibieron al menos una red afectada.
  • Según Catchpoint, la mayoría de las rutas anómalas se retiraron después de alrededor de una hora y los efectos involucraron a más de 3.500 empresas. Esas cifras no representan una medición universal de Internet.
  • MANRS presentó un recuento diferente: describió a AS55410 como una red que normalmente anunciaba 824 rutas y que anunció más de 31.000 rutas adicionales.
  • MANRS llamó al episodio un secuestro BGP y atribuyó en su análisis la propagación observada a Bharti Airtel AS9498, mientras señaló que otros proveedores identificados no propagaron el mismo conjunto de rutas.
  • The Register resumió el episodio como la aparición de más de 30.000 prefijos falsos. Esa formulación es una síntesis periodística, no una validación individual de cada ruta.
  • La evidencia pública demuestra anuncios de origen anómalos y una propagación extensa, pero no establece intención maliciosa, negligencia, ilegalidad, responsabilidad jurídica ni la configuración privada de cada operador.
  • RPKI puede ayudar a rechazar un origen cubierto que resulte inválido, pero no valida por sí solo toda la ruta AS_PATH ni protege los prefijos sin una ROA aplicable.
  • La responsabilidad operativa sigue el control práctico: quién podía impedir la originación, limitar la exportación, rechazar las rutas de un cliente, frenar su propagación, detectar la anomalía, verificar la retirada y conservar evidencia suficiente para una reparación duradera.

El acontecimiento observado el 16 de abril de 2021

BGP permite que sistemas autónomos intercambien información sobre los prefijos que pueden alcanzar. Cada anuncio incluye un prefijo, un origen y una ruta de sistemas autónomos, además de otros atributos que influyen en la selección y propagación. Ese mecanismo hace posible el alcance global de Internet, pero también permite que un error local se extienda si atraviesa los límites de aceptación de otras redes.

Los informes públicos sitúan el episodio de AS55410 el 16 de abril de 2021. No ofrecen una visión omnisciente del estado de todos los routers, y sus recuentos no deben fusionarse como si procedieran de una única medición. Cada publicación examinó el evento desde fuentes, ventanas y criterios propios.

Catchpoint informó que a las 13:48:58 GMT AS55410 aparecía como origen de más de 34.000 redes. Su análisis empleó, entre otros elementos, observaciones del colector RIPE RIS rrc00. En la ventana comprendida entre las 13:45 y las 15:00 GMT, Catchpoint describió aproximadamente 225.000 mensajes de actualización BGP en ese colector. Un mensaje de actualización no equivale necesariamente a un prefijo nuevo ni a un usuario afectado: un mismo prefijo puede generar múltiples anuncios y retiradas, y las decisiones pueden variar entre pares.

En el conjunto observado por Catchpoint, 64 de los 73 pares de rrc00 recibieron al menos una red afectada. Esa proporción demuestra una difusión amplia dentro de ese universo de observación. No demuestra que 64 de cada 73 redes de Internet aceptaran las rutas, ni que todos esos pares seleccionaran la ruta anómala como mejor camino, ni que la exportaran posteriormente.

Catchpoint indicó además que la mayoría de las rutas anómalas fueron retiradas después de aproximadamente una hora. La formulación “la mayoría” importa: no fija una hora única de recuperación para todos los prefijos y todos los lugares. La retirada se propaga de manera distribuida, y las redes pueden procesarla en momentos distintos. Tampoco permite concluir que todos los servicios afectados recuperaran su comportamiento normal al mismo tiempo.

La misma publicación relacionó los efectos con más de 3.500 empresas. Ese número debe conservarse como una evaluación de Catchpoint, no como un censo completo de usuarios, organizaciones, aplicaciones o pérdidas. Una empresa puede tener múltiples prefijos o servicios, y la recepción de una ruta anómala no implica automáticamente una interrupción total.

MANRS publicó un análisis separado. Describió a AS55410 como un sistema autónomo que normalmente anunciaba 824 rutas y que, durante el episodio, anunció más de 31.000 rutas adicionales. Esta comparación ofrece una señal clara de desviación respecto de su línea de base, pero no es intercambiable con las “más de 34.000 redes” de Catchpoint. Las unidades, el momento de observación, las fuentes y el método de conteo pueden producir cifras diferentes sin que una de ellas deba sustituir silenciosamente a la otra.

MANRS denominó el evento un secuestro BGP. En su examen de la propagación observada, atribuyó la difusión a Bharti Airtel AS9498 y señaló que otros proveedores identificados no propagaron el mismo conjunto de rutas. Esa diferencia es relevante para el análisis de controles: indica que los resultados en los límites de red no fueron necesariamente uniformes. No revela las políticas privadas exactas de cada proveedor ni prueba que todos los enlaces de AS9498 actuaran del mismo modo.

The Register resumió el episodio mediante la expresión de más de 30.000 prefijos falsos. La cifra sirve para reflejar la magnitud comunicada públicamente, pero el artículo periodístico no reemplaza un examen ruta por ruta, una instantánea íntegra del plano de control o los registros de configuración de las redes implicadas.

Fuga, anuncio erróneo de origen y secuestro

Los términos usados para describir el incidente no son sinónimos perfectos.

Una fuga de rutas ocurre cuando información de alcance se propaga más allá de la relación o el ámbito previsto. Puede involucrar rutas cuyo origen es válido, pero que se exportan en una dirección no autorizada por la relación comercial. La taxonomía de RFC 7908 ayuda a distinguir varios patrones de fuga según la relación entre cliente, proveedor y par.

Un anuncio erróneo de origen ocurre cuando un sistema autónomo aparece como origen de prefijos que no debía originar. Esta descripción se ajusta a la característica central observada en los informes sobre AS55410: un volumen extraordinario de redes apareció públicamente con ese origen. Puede ser consecuencia de una configuración incorrecta, una importación defectuosa, una redistribución no prevista u otra causa, pero los datos públicos examinados no identifican con certeza el mecanismo interno.

El secuestro de rutas es un término usado con frecuencia cuando una red anuncia espacio de direcciones ajeno o atrae tráfico mediante rutas no autorizadas. En algunos contextos, “secuestro” describe el efecto técnico sin resolver la intención; en otros, sugiere una acción deliberada. MANRS empleó esa denominación para el episodio. Sin embargo, ninguna de las fuentes disponibles demuestra un motivo malicioso. Por eso, la descripción prudente es una fuga de rutas con anuncios de origen anómalos, sin negar la terminología atribuida a MANRS.

Esta distinción evita convertir una observación del plano de control en una acusación no demostrada. La evidencia disponible no prueba sabotaje, engaño deliberado, ocultamiento, negligencia o infracción legal. Tampoco identifica la orden concreta, el proceso humano, la automatización o el cambio de configuración que originó el evento.

Cómo una anomalía de origen puede propagarse

RFC 4271 describe el intercambio de información de alcance entre sistemas autónomos. BGP distribuye rutas y permite que cada operador aplique su propia política. No incorpora por defecto una autoridad global que evalúe cada anuncio y ordene a todos los routers aceptarlo o rechazarlo.

Cuando una red cliente anuncia rutas a un proveedor, el proveedor decide cuáles acepta. Una política sólida puede mantener una lista de prefijos autorizados para ese cliente, contrastarla con información operativa aprobada y establecer límites cuantitativos. Si aparece un prefijo fuera de la autorización, la ruta puede rechazarse antes de entrar en la tabla de enrutamiento y antes de propagarse a terceros.

El control de máximo de prefijos cumple una función diferente. Puede detectar un salto brusco desde una línea de base reducida hasta decenas de miles de rutas. No confirma quién tiene derecho a originar cada prefijo, pero puede detener o limitar una sesión cuyo comportamiento excede el contrato esperado. Debe ajustarse con margen suficiente para cambios legítimos y con procedimientos que eviten una desconexión innecesaria.

La autorización de prefijos y el límite máximo son complementarios. Una lista de autorización identifica qué espacio puede anunciar el cliente; el máximo de prefijos limita cuánto puede anunciar en conjunto. Una red puede cumplir un máximo alto y aun presentar un prefijo no autorizado, o puede anunciar muchos prefijos legítimos más específicos y superar un umbral mal calibrado. Ningún control aislado cubre todos los fallos.

Las políticas de exportación en la red de origen son la primera frontera. AS55410 controlaba qué información se originaba o se redistribuía en su BGP y qué rutas se entregaban a cada vecino. Una lista explícita de los prefijos propios, aplicada al punto de exportación, podría impedir que rutas ajenas salieran como originadas por AS55410. Pero las fuentes públicas no permiten determinar qué política existía, qué falló o qué mecanismo se modificó después.

La segunda frontera corresponde a los proveedores que reciben las rutas del cliente. Cada proveedor controla su aceptación, sus límites, el uso de datos IRR o RPKI y la exportación posterior. Que MANRS haya observado la propagación a través de Bharti Airtel AS9498, mientras otros proveedores identificados no propagaron el mismo conjunto, hace visible esa separación de responsabilidades. No autoriza a inferir las configuraciones exactas ni a afirmar que una única decisión explicó todo el alcance global.

La tercera frontera está en las redes posteriores. Operadores de tránsito, pares y redes de destino aplican sus propias políticas de importación y selección. Algunos pudieron rechazar determinados anuncios, otros recibirlos sin elegirlos y otros seleccionarlos. Los colectores solo muestran las rutas que sus pares les transmitieron; no muestran todas las alternativas internas ni el resultado de reenvío de cada dispositivo.

Lo que RPKI puede validar, y lo que no

RPKI permite asociar recursos numéricos con autorizaciones de origen. Una ROA expresa qué sistema autónomo está autorizado a originar un prefijo y hasta qué longitud de prefijo. Un validador puede clasificar una ruta cubierta como válida, inválida o no encontrada, de acuerdo con la terminología y el proceso de validación de origen descritos en RFC 6811 y RFC 8893.

Si un prefijo estaba cubierto por una ROA que autorizaba un origen diferente de AS55410, el anuncio podía resultar inválido. Una red que hubiera integrado el estado RPKI en una política de rechazo habría tenido un control capaz de descartar esa ruta. Pero la existencia de una ROA no obliga por sí misma a un router a rechazar nada. El operador debe obtener los datos, validarlos, distribuir el estado a sus routers y aplicar una política concreta.

Un resultado válido tampoco confirma la legitimidad completa del camino. La validación de origen verifica la relación entre prefijo y AS de origen conforme a la ROA aplicable. No verifica cada salto de AS_PATH, la relación comercial entre vecinos ni la autorización de exportar la ruta en esa dirección.

Los prefijos sin una ROA aplicable aparecen como no encontrados. La validación de origen no puede declarar inválido un anuncio no cubierto simplemente porque parezca extraño. Por ello, RPKI debe combinarse con autorizaciones de cliente, listas de prefijos, límites, relaciones BGP explícitas y vigilancia del comportamiento.

Los objetos de enrutamiento en un IRR también pueden apoyar la construcción de filtros. Son registros declarativos y su calidad depende de la exactitud, actualidad y autoridad de los datos. Un objeto existente no configura automáticamente un router, y un filtro generado sin controles sobre la procedencia de los objetos puede aceptar información obsoleta o indebidamente mantenida.

Los registros de ASN y prefijos, RIPE Stat, CAIDA ASRank y CIDR Report aportan contexto sobre recursos y topología visible. Los datos actuales no deben presentarse como una fotografía perfecta de abril de 2021. Las relaciones entre sistemas autónomos, los anuncios, los registros y la cobertura RPKI pueden cambiar. Su valor está en documentar contexto y formular preguntas, no en reemplazar evidencia contemporánea del incidente.

Colectores: observación, no autorización

RIPE RIS y RouteViews reciben rutas de pares participantes y conservan observaciones útiles para analizar cambios. Permiten estudiar cuándo llegó un anuncio a determinados puntos, qué AS_PATH se vio, cuándo apareció una retirada y cómo difirieron los resultados entre observadores.

Un colector no autoriza la ruta. No ordena a los operadores aceptarla, no comprueba la intención del anunciante y no controla la política privada de los routers. La aparición de una ruta en un colector demuestra que al menos un camino de observación la recibió y la anunció al colector bajo ciertas condiciones.

Tampoco demuestra que todas las redes seleccionaran la misma ruta. Un par del colector puede mostrar su mejor ruta externa mientras conserva alternativas. Una red que no aporta datos puede observar algo distinto. Los routers internos pueden aplicar preferencias locales, y el camino seleccionado para el reenvío puede variar por ubicación, familia de direcciones o momento.

La ausencia de una ruta en un colector tampoco prueba que no existiera en ningún lugar. La visibilidad depende del conjunto de pares. Una investigación rigurosa debe combinar múltiples puntos de observación, conservar las marcas temporales y declarar las limitaciones de cobertura.

En este caso, los datos de rrc00 usados por Catchpoint permiten medir una propagación amplia dentro de ese colector. No justifican extrapolar automáticamente sus 73 pares a todo Internet. RouteViews y otros colectores pueden complementar la cronología, pero ninguna colección pública reconstruye por sí sola todos los caminos privados.

Evidencia del impacto y sus límites

Una ruta de origen anómala puede atraer tráfico hacia un camino que no tiene conectividad adecuada con el destino real. El resultado potencial incluye pérdida de paquetes, desvío, aumento de latencia, inestabilidad o cambios repetidos de ruta. El efecto concreto depende de qué red recibió el anuncio, qué ruta seleccionó, cómo reenviaba el tráfico y cuándo procesó la retirada.

No puede afirmarse que cada prefijo anunciado quedara inaccesible. Algunos anuncios pudieron no ser seleccionados. Otros pudieron conducir a un camino que descartaba tráfico, mientras algunos destinos conservaron alternativas. Tampoco puede sostenerse que todas las empresas experimentaran el mismo tiempo de interrupción o la misma degradación.

La referencia de Catchpoint a efectos que involucraron a más de 3.500 empresas proporciona una medida atribuida de amplitud. No constituye una lista completa de usuarios afectados ni prueba un perjuicio uniforme. No hay en el paquete de fuentes un cálculo completo de pérdidas financieras, una enumeración íntegra de servicios o un recuento exacto de personas afectadas.

El plano de control sí ofrece una conclusión firme y limitada: numerosos observadores recibieron rutas en las que AS55410 aparecía como origen de una cantidad excepcional de redes, y algunas de esas rutas se propagaron a través de otros sistemas autónomos. Esa evidencia basta para evaluar las fronteras de control sin exagerar las consecuencias.

La diferencia entre plano de control y plano de datos resulta decisiva. Un anuncio BGP describe alcance; no es una captura de los paquetes enviados por cada usuario. Para demostrar un resultado de reenvío serían necesarias mediciones del plano de datos, como trazas, pérdida, latencia o registros de servicio, vinculadas a lugares y momentos concretos.

Prevención: controles en la red de origen

La primera obligación operativa recae sobre la red que puede originar o exportar la información. Esto no equivale a una conclusión jurídica. Significa que la configuración bajo su control es la primera oportunidad práctica para impedir que el anuncio salga.

Una política de origen debería enumerar los prefijos que el sistema autónomo está autorizado a anunciar. La lista debe derivarse de una fuente gestionada, estar sometida a cambios controlados y aplicarse a todos los puntos de salida pertinentes. Las rutas aprendidas de clientes, pares, tablas internas o redistribuciones no deberían convertirse accidentalmente en anuncios propios.

La política de exportación debe ser explícita. RFC 8212 respalda el principio de no intercambiar rutas en sesiones eBGP sin políticas configuradas. RFC 7454 reúne prácticas operativas de filtrado, límites y protección de sesiones. Son opciones y recomendaciones de ingeniería; no demuestran que estuvieran implantadas por Vodafone Idea o por cualquier proveedor durante el incidente.

Los cambios masivos requieren una validación previa. Antes de aplicar una nueva política, el operador puede comparar el conjunto de prefijos previsto con la línea de base, simular su efecto y definir un umbral de aborto. Un aumento desde cientos hasta decenas de miles de rutas debería producir una señal crítica antes de llegar a un proveedor.

La separación de funciones también reduce el riesgo. La persona o sistema que prepara un cambio no debería ser el único que valida la lista de exportación. Para automatizaciones, la autorización debe estar codificada y limitada, con registros que permitan saber qué entrada produjo cada anuncio.

La vigilancia posterior al cambio debe comprobar el resultado desde fuera de la red. Una configuración puede parecer correcta localmente y aun producir una exportación inesperada por interacción con otra política. Los colectores públicos, las sesiones de supervisión y las alertas de terceros sirven como controles secundarios, no como sustitutos del filtro de salida.

Prevención en el límite cliente-proveedor

Un proveedor no controla la configuración interna del cliente, pero sí controla qué acepta de él. Esa diferencia evita dos errores: atribuir todo el incidente al tránsito o absolverlo porque el anuncio se originó en otro sistema autónomo.

La autorización de prefijos por cliente es el control más directo. Cada sesión debe disponer de un conjunto esperado, con mecanismos para actualizarlo cuando el cliente obtiene o deja de anunciar recursos. La evidencia puede combinar contratos técnicos, información del cliente, objetos IRR validados y RPKI. Ninguna fuente debe aceptarse sin evaluar su autoridad y actualidad.

El límite máximo de prefijos debería reflejar el perfil normal y el crecimiento razonable. Según MANRS, AS55410 pasaba de una línea de base de 824 rutas a más de 31.000 adicionales. Un umbral compatible con cientos de rutas pero no con decenas de miles podría haber detectado una desviación extrema. No obstante, las fuentes no revelan los umbrales reales ni si la agregación, la sesión o el momento permitían ese control concreto.

La validación RPKI añade una comprobación independiente para prefijos cubiertos. Rechazar rutas inválidas por origen puede impedir una parte sustancial de una originación anómala. Su alcance depende de la cobertura ROA y no sustituye las listas de cliente.

RFC 9234 define roles BGP y el atributo Only-to-Customer como herramientas para expresar y restringir determinadas relaciones de propagación. Estas medidas pueden reducir fugas incompatibles con la relación cliente-proveedor. No son una prueba de que se utilizaran en 2021 ni garantizan corregir todos los anuncios de origen erróneo.

El proveedor también debe controlar la exportación posterior. Aceptar una ruta no obliga a anunciarla a todos los vecinos. La política de distribución puede limitar el daño mientras se investiga. La atribución de MANRS a AS9498 para la propagación observada plantea precisamente esta pregunta operativa: qué control permitió la aceptación y qué control permitió la difusión. No responde por sí sola cómo estaban configurados los routers.

Detección: reconocer una desviación antes de que se normalice

Una alerta útil combina volumen, identidad y novedad. El volumen identifica un salto en el número de prefijos; la identidad comprueba si pertenecen al conjunto autorizado; la novedad determina si el comportamiento apareció después de un cambio o en un vecino específico.

La detección local debe ser rápida porque evita depender del tiempo que tarda un observador externo en encontrar el problema. Los contadores de rutas recibidas y anunciadas por sesión, los cambios en la tabla de enrutamiento y el estado RPKI pueden alimentar umbrales automáticos. Un salto de varios órdenes de magnitud merece una escalada inmediata, incluso antes de clasificar el incidente.

La detección externa aporta independencia. Una alerta desde RIPE RIS, RouteViews, una plataforma comercial o un titular de prefijos puede revelar que la red está difundiendo algo que su telemetría interna no señaló. Es importante conservar el mensaje exacto, el prefijo, el origen, el AS_PATH, la comunidad, el colector, el par y la hora.

No toda anomalía es un ataque. Un cambio legítimo de conectividad, una deagregación temporal o una migración puede alterar los anuncios. Por ello, la alerta debe iniciar verificación, no una acusación. La severidad aumenta cuando el origen no está autorizado, la cantidad se aparta radicalmente de la línea de base o varios observadores confirman propagación.

Los equipos de origen y tránsito necesitan un canal de coordinación que funcione fuera del mismo sistema potencialmente afectado. Los contactos operativos en registros y directorios pueden facilitar la respuesta, pero solo si están actualizados y se usan. El registro es una ayuda para localizar responsables; no retira rutas por sí mismo.

Contención y retirada verificada

Una vez confirmada una originación anómala, la prioridad es detener nuevos anuncios. La red de origen puede retirar las rutas, deshabilitar la política que las genera o filtrar la exportación afectada. La elección depende de la causa y del riesgo de interrumpir anuncios legítimos.

Los proveedores pueden aplicar filtros temporales a los prefijos o al origen observado. También pueden limitar la sesión, suspender la aceptación de nuevas rutas o impedir su exportación a otros vecinos. Una medida demasiado amplia puede afectar conectividad válida, de modo que la contención necesita un alcance definido y una revisión rápida.

La retirada no es instantánea ni uniforme. Cada red procesa los mensajes según sus sesiones y estado local. Algunas rutas pueden persistir en observadores durante un intervalo, y los cambios de camino pueden generar actualizaciones adicionales. El final de la emisión desde el origen no es por sí solo evidencia de desaparición global.

La verificación debe observar múltiples puntos. Un operador puede confirmar que su router ya no anuncia un prefijo, pedir al proveedor que compruebe su tabla y consultar colectores independientes. El cierre debe registrar la última observación anómala conocida y distinguirla de la recuperación de servicios.

RFC 7999 define una comunidad de blackhole bien conocida para ciertos usos de descarte remoto. Es relevante como contexto general sobre mecanismos de control y contención, pero ninguna fuente demuestra que esa comunidad se utilizara en este incidente. No debe presentarse como parte de la respuesta de Vodafone Idea, Bharti Airtel o cualquier otra red.

Una contención exitosa detiene la propagación; no constituye una reparación completa. Si el origen del problema fue una generación defectuosa de filtros, una redistribución imprevista o una autorización excesiva, volver al estado anterior sin corregir esa causa deja abierta la repetición.

Recuperación y reparación duradera

La recuperación comienza cuando las rutas legítimas permanecen estables y las anómalas dejan de observarse. Aun así, la restauración técnica debe separarse de la investigación. La presión por recuperar conectividad puede justificar una medida temporal, pero no la eliminación de registros que permitan comprender el fallo.

La evidencia mínima incluye configuraciones anteriores y posteriores, registros de cambios, comandos ejecutados, rutas recibidas y anunciadas por vecino, alertas, marcas temporales, comunicaciones operativas y confirmaciones de retirada. Cuando sea posible, deben conservarse los mensajes BGP relevantes y la versión exacta de las fuentes usadas para generar filtros.

La reparación debe probarse contra el mismo patrón de fallo. Si decenas de miles de rutas ajenas se intentan originar o exportar, el control de salida debe rechazarlas. Si llegan desde un cliente, el filtro de entrada y el límite máximo deben impedir la aceptación o generar una interrupción segura y visible. Si una ruta resulta inválida por RPKI, la política debe producir el resultado esperado.

La prueba debe incluir prefijos cubiertos y no cubiertos por ROA. Esto evita declarar resuelto un problema mediante validación de origen cuando la vulnerabilidad persiste para espacio sin cobertura. También debe comprobar rutas con origen válido pero propagación incompatible con la relación comercial.

No hay evidencia pública suficiente para afirmar qué correcciones permanentes realizaron Vodafone Idea, Bharti Airtel u otros operadores. Los RFC describen mecanismos disponibles, pero no prueban su implantación. La ausencia de evidencia pública tampoco demuestra que no hubiera cambios internos. La conclusión responsable es que la reparación duradera no puede verificarse con este conjunto de fuentes.

Una matriz de responsabilidad basada en el control

Etapa Control principal Evidencia necesaria Límite de la atribución
Originación AS55410 Política de origen, configuración, registros de cambios y rutas generadas La observación pública no revela la causa interna
Exportación inicial AS55410 Filtros de salida, rutas anunciadas por vecino y marcas temporales No se conoce qué sesiones compartían la misma política
Aceptación del cliente Cada proveedor directo Lista autorizada, datos IRR/RPKI, máximo de prefijos y registros de sesión La topología pública no revela toda relación o configuración privada
Propagación posterior Proveedores, tránsitos y pares que recibieron rutas Política de exportación, AS_PATH observado y rutas enviadas por vecino Un colector no muestra todos los caminos
Validación de origen Cada red receptora y los titulares de los prefijos ROA aplicable, estado RPKI y política de rechazo RPKI no valida todo el AS_PATH ni cubre todos los prefijos
Detección Origen, proveedores, redes receptoras y observadores Alertas, líneas de base, actualizaciones BGP y observaciones independientes Detectar no equivale a bloquear
Contención Origen y operadores capaces de filtrar Retiradas, filtros temporales, comunicaciones y comprobaciones El tiempo de convergencia varía
Recuperación Cada operador afectado en su ámbito Estabilidad de rutas legítimas y verificación del plano de datos No existe una hora universal de recuperación
Reparación Propietarios de los controles que fallaron Pruebas de regresión, cambios aprobados y vigilancia posterior Las fuentes no prueban una corrección duradera concreta

Esta matriz distribuye la responsabilidad sin diluirla. La existencia de múltiples fronteras no significa que nadie sea responsable. Significa que cada operador responde por los controles que podía aplicar y por la evidencia que puede conservar.

La red de origen tenía la primera oportunidad de impedir la originación y la exportación. Un proveedor tenía la oportunidad independiente de rechazar rutas fuera del conjunto autorizado, bloquear un volumen absurdo o evitar su propagación posterior. Las redes receptoras podían aplicar validación de origen y políticas propias. Los titulares de los prefijos podían mantener ROA y registros precisos, aunque esos datos solo adquieren efecto cuando los routers los consumen.

Los colectores y registros ocupan otra función: hacen visible parte de la realidad y permiten investigar. No son autoridades que configuren la política de los routers. Una entrada correcta en un registro no compensa un filtro ausente; una observación en rrc00 no determina qué ruta debía aceptar cada red.

La rendición de cuentas, por tanto, debe formular preguntas verificables: ¿qué ruta se originó?, ¿qué filtro debía bloquearla?, ¿qué vecino la aceptó?, ¿qué red la propagó?, ¿qué alerta se activó?, ¿qué retirada se emitió?, ¿cómo se confirmó su desaparición y qué prueba demuestra que el mismo fallo no puede repetirse? Estas preguntas son más útiles que una etiqueta retrospectiva sin acceso a los controles reales.