Fuga de rutas de Rostelecom: límites de la validación de origen

Resumen

La cuenta de monitorización de Qrator sitúa el inicio del incidente en torno a las 19:28 UTC del 1 de abril de 2020 y describe una observación de aproximadamente una hora. Se trata de una ventana de observación externa atribuida, no de una cronología interna completa de Rostelecom ni de una prueba de inicio y final exactos en cada red afectada.[1]
Qrator informó de 8.870 prefijos afectados pertenecientes a casi 200 sistemas autónomos. CERT-EU resumió por separado más de 8.800 rutas de más de 200 redes. Las cifras describen la escala visible desde perspectivas de reporte diferentes; ninguna fuente establece cada ruta de datos, cada usuario afectado o el impacto comercial total.[1][2]
Qrator observó anuncios AS12389 propagándose a través de Rascom AS20764, Cogent AS174 y Level 3 AS3356. Esta cadena muestra que el evento cruzó dominios de enrutamiento con control independiente, pero no revela ni los filtros de importación exactos, ni los contratos, ni el estado de validación ni la configuración de enrutador de ninguna red concreta.[1]
La evidencia de enrutamiento requiere mantener separadas varias categorías: una ruta aprendida y exportada fuera del alcance de política previsto; un anuncio de origen no autorizado; una re-originación más específica; y una ruta cuyo origen autorizado permanece intacto aunque su camino infringe una relación comercial esperada. Esas categorías interactúan de forma distinta con los filtros y con la validación de origen por RPKI.[4][17]
Hubo un incidente distinto en RIPE NCC en el plano de control de RPKI. Tras una actualización de software del registro, se eliminaron 2.669 Route Origin Authorisations después de que algunas asignaciones independientes del proveedor se clasificaran como no certificables. RIPE NCC restauró las ROA faltantes el 2 de abril.[3][5]
La coincidencia temporal no estableció causalidad. La revisión retrospectiva de RIPE NCC y un análisis independiente del Grupo de Trabajo de Enrutamiento no encontraron relación directa entre la eliminación de ROA y el incidente de enrutamiento de Rostelecom.[4][5]
La intersección medida entre los incidentes fue reducida: tres titulares independientes de recursos y 12 prefijos. Ese solapamiento no puede extrapolarse a los 8.870 prefijos, y el registro público no respalda describir todas las rutas afectadas como RPKI Invalid.[4][5]
Route Origin Validation puede comparar un prefijo y su ASN de origen con ROA validadas y clasificar el resultado como Valid, Invalid o NotFound. No valida la ruta AS completa, no determina si cada exportación respetó una relación comercial, no reconstruye un cambio de configuración ni establece intención.[13]-[15]
El control práctico estaba distribuido. Rostelecom controló sus anuncios y su política de exportación; las redes receptoras controlaron su propia política de importación, exportación y validación; los titulares de prefijos controlaron sus registros y ROA; RIPE NCC controló su certificación y su servicio de gestión de ROA; los relying parties controlaron la frescura de caché y la aplicación; los proveedores de monitorización controlaron su observación y sistemas de alerta.
Quedan hechos importantes sin conocer: la secuencia interna iniciadora, la división exacta entre leaks de rutas aprendidas y re-originaciones más específicas, el estado RPKI visible para cada relying party, los filtros aplicados en cada salto, la cronología completa de respuesta y el impacto total en plano de datos, y si el incidente comenzó de forma accidental o intencional.
La conclusión de responsabilidad es, por tanto, operacional y no acusatoria. Los registros del registro y de ROA aportaron evidencia sobre recursos y autorización de origen, mientras que las configuraciones en ejecución, los cachés actuales, las políticas de vecinos, la monitorización y la recuperación coordinada determinaron si esa evidencia modificó el comportamiento de enrutamiento en vivo.

La cuestión de la responsabilidad

El incidente del 1 de abril de 2020 fue relevante porque expuso una separación entre la autoridad registrada y el control en ejecución. RIPE Database pudo identificar el objeto administrativo asociado con AS12389 y RPKI pudo expresar algunas autorizaciones de origen de los titulares de prefijos.[8][10] Ninguno de esos sistemas dictó de forma independiente lo que cada enrutador aceptaría, preferiría o propagaría.

Los speakers BGP intercambiaron mensajes UPDATE, seleccionaron rutas según política local y anunciaron resultados permitidos a sus vecinos.[12] Cuando anuncios inesperados cruzaron una frontera de red, cada operador receptor tomó otra decisión localmente controlada.

Eso excluye una explicación simple en la que un único registro, un mecanismo único de seguridad o una organización gobernaran todo el resultado. El tránsito de Qrator a través de AS20764, AS174 y AS3356 colocó varios planos de control operativo en la cadena observada.[1] El comportamiento de Rostelecom fue central porque AS12389 aparecía en los anuncios examinados. Sin embargo, el alcance de esos anuncios también dependía de qué vecinos los aceptaron, qué rutas exportaron esos vecinos y qué redes aguas abajo las seleccionaron.

Por eso el evento se convirtió en una prueba de los límites de la validación de origen. Si un anuncio usaba un origen no autorizado o una longitud de prefijo no permitida en una ROA, un operador con datos validados actualizados y una política de cumplimiento podía potencialmente clasificarlo y rechazarlo como Invalid. Si una ruta mantenía un origen autorizado pero se transportaba por un AS path inapropiado, el mismo chequeo de origen podía devolver Valid. Si no existía una ROA de cobertura, el resultado sería normalmente NotFound y no Invalid.

Los controles técnicos tenían por tanto distinta capacidad de influencia sobre distintas partes del evento observado.

La evidencia pública respalda un análisis de responsabilidad solo si esas distinciones se mantienen. Quitar los anuncios BGP, la evidencia AS12389, las observaciones de propagación, el estado de ROA, las decisiones de aceptación de upstream, monitorización y coordinación de incidente dejaría una discusión de seguridad genérica en lugar de explicar este incidente. De forma inversa, tratar todas las rutas como un mismo tipo de fallo asignaría capacidades a RPKI que ese mecanismo no estaba diseñado para tener.

La responsabilidad aquí significa identificar quién tenía control práctico sobre una decisión medible y qué evidencia puede demostrar esa decisión. No implica inferir negligencia, criminalidad, culpa individual, brecha, responsabilidad legal o intención de interceptación a partir de observaciones de enrutamiento externas. CERT-EU dijo que no estaba claro si el evento fue accidental.[2] El registro disponible no resuelve esa incertidumbre, por lo que el análisis no debe resolverla por afirmación.

Línea temporal forense

Una reconstrucción forense debe distinguir observaciones reportadas directamente de inferencias y eventos internos no resueltos. Coleccionistas de rutas públicos y plataformas de monitorización muestran vistas parciales del plano de control en lugar de una transcripción universal. La documentación de RIPEstat también encuadra los datos de enrutamiento como observación desde fuentes disponibles, con límites impuestos por puntos de vista y cobertura de datos.[9] La siguiente cronología identifica lo que se informó, lo que es separado y lo que permanece desconocido.

Hora	Acontecimiento con evidencia
Antes de las 19:28 UTC, 1 de abril	El registro público no identifica el cambio de configuración inicial en Rostelecom, el enrutador, el comando, el empleado o la secuencia interna de aprobación. Tampoco establece el estado preincidente preciso de filtros y RPKI en cada red que más tarde aceptó un anuncio.
Alrededor de las 19:28 UTC	Qrator sitúa el comienzo de su observación alrededor de las 19:28 UTC. Informó que AS12389 anunciaba rutas asociadas con un gran conjunto de otras redes.[1] Esta marca temporal pertenece a la cuenta de monitorización de Qrator; no prueba que cada enrutador afectado viera su primera actualización en ese instante.
Durante la propagación posterior	Qrator informó que los anuncios se propagaron mediante Rascom AS20764, Cogent AS174 y Level 3 AS3356.[1] La observación establece propagación visible adicional a través de esos sistemas autónomos, pero no cada decisión por sesión, evaluación de route-map ni relación comercial subyacente.
Durante la ventana aproximada de una hora	Qrator contó 8.870 prefijos afectados asociados a casi 200 sistemas autónomos.[1] CERT-EU resumió más tarde más de 8.800 rutas de más de 200 redes.[2] Se trata de medidas atribuidas, no de prueba de que cada ruta tuviera el mismo estado de validación de origen o produjera la misma consecuencia de plano de datos.
Durante la respuesta del incidente	Qrator dijo que Rostelecom recibió una advertencia en tiempo real y trabajó con Qrator en resolución de problemas y restauración.[1] CERT-EU también registró cooperación con la firma de reporte.[2] La secuencia interna exacta de escalamiento, mitigación y reversión en Rostelecom no es pública.
Alrededor de una hora después de la primera observación	Qrator describió el evento como con duración aproximada de una hora.[1] El registro público apoya la restauración dentro de ese intervalo observado, pero no establece qué configuración o retirada terminó cada ruta afectada ni si la convergencia se completó simultáneamente en todos los lugares.
Incidente contemporáneo de RPKI	Por separado, una actualización del software de RIPE NCC causó que ciertas asignaciones independientes del proveedor se clasificaran como no certificables, lo que llevó a la eliminación de 2.669 ROA.[3][5] Este fue un fallo de gestión de registros en el plano de control y distinto del comportamiento de enrutamiento AS12389.
2 de abril	RIPE NCC restauró las ROA faltantes.[3][5] Esa restauración pertenece a la cronología independiente de recuperación del servicio RPKI y no debe presentarse como el mecanismo que terminó el evento de Rostelecom.
Análisis posterior	Un análisis del Routing Working Group y la revisión retrospectiva posterior de RIPE NCC no encontraron relación directa entre ambos incidentes. Identificaron una intersección de tres titulares PI y 12 prefijos.[4][5]

Esta cronología contiene dos secuencias simultáneas pero analíticamente separadas. Una apareció en anuncios BGP y su aceptación entre fronteras de red. La otra ocurrió en la producción y disponibilidad de registros de autorización de origen. La primera dependía de política de enrutamiento en vivo; la segunda afectaba qué datos de ROA validados podían estar disponibles para los relying parties. Su intersección limitada permite preguntar legítimamente si los registros faltantes cambiaron el tratamiento de 12 prefijos. No convierte la eliminación de ROA en causa del evento de 8.870 prefijos.

La línea temporal también separa tiempo de detección y tiempo de activación. La observación aproximada de las 19:28 UTC de Qrator es evidencia de cuándo el evento se volvió visible en sus puntos de vista. No identifica cuándo se introdujo, confirmó o distribuyó un cambio interno. De igual modo, la duración aproximada de una hora describe la observación externa. No puede establecer el período exacto durante el cual cada ruta individual estuvo presente en cada base de información de enrutamiento.

La ausencia de una cronología por enrutador es relevante. Sin ella, no se puede extraer una conclusión fiable sobre el primer vecino receptor, la secuencia de evaluaciones de política, qué rutas se retiraron o corrigieron primero, o si algunas redes contenían partes del evento mientras otras continuaban propagándolo. Una reconstrucción responsable conserva esos huecos en vez de convertir una traza de monitorización de rutas en un registro interno imaginado.

Lo que establece la propagación observada

Las observaciones del AS path establecen que información de alcanzabilidad inesperada no permaneció confinado en una sola red. BGP es un protocolo distribuido: un UPDATE aceptado por un sistema autónomo puede entrar en el proceso de decisión de otro sistema y, sujeto a política, anunciarse a vecinos adicionales.[12] La propagación reportada AS12389–AS20764–AS174–AS3356 por tanto marca una secuencia de decisiones operativas en dominios administrativos separados.[1]

Esta secuencia no prueba que cada red nombrada aceptara cada uno de los 8.870 prefijos ni que un mismo camino idéntico alcanzó toda Internet. Tampoco revela por qué una política de importación concreta aceptó una ruta. Un operador pudo apoyarse en filtros de prefijos de clientes, datos de IRR, validación RPKI, excepciones mantenidas manualmente, límites amplios o supuestos contractuales, o una combinación de todo ello. La evidencia congelada no muestra la configuración de abril de 2020 de ninguna upstream o peer concreto.

Aun así, la evidencia de propagación es valiosa porque identifica dónde existían oportunidades de contención. AS12389 controlaba si originaba o exportaba los anuncios. Cada red receptora conectada directamente controlaba si los aceptaba. Cada anunciante posterior controlaba otra decisión de exportación. Las redes aguas abajo controlaban la selección de rutas y cualquier política local de validación. Este es un control compartido en sentido técnico preciso: múltiples operadores tenían mecanismos independientes capaces de cambiar al menos algunos resultados de enrutamiento.

El control compartido no debe convertirse automáticamente en culpa compartida. Un AS path visible no revela los términos de una relación de enrutamiento, la precisión del inventario de prefijos de un operador, el estado de sus cachés o si una ruta pertenecía a la porción de leak de ruta aprendida o a la porción re-originada más específica del evento. Identifica un punto de decisión, no el significado legal o moral de esa decisión.

Cuatro condiciones de enrutamiento que no deben fusionarse

La palabra leak suele usarse con flexibilidad, pero este incidente no se interpreta con precisión sin separar cuatro condiciones de enrutamiento. RFC 7908 define route leaks alrededor de la propagación de anuncios de enrutamiento más allá de su alcance de política previsto, especialmente donde el path resultante viola el orden esperado entre relaciones de cliente, proveedor y peer.[17] Ese concepto difiere de la autorización de origen.

Fuga de política de ruta aprendida.Una red aprende una ruta legítima de un vecino y la exporta a otro vecino fuera del alcance de política previsto para esa ruta. El origen autorizado del titular del prefijo puede permanecer al final del AS path. El error está en el alcance de exportación: la red intermedia actúa como tránsito donde la política no pretendía eso. Como el ASN de origen original y la longitud de prefijo aún pueden coincidir con una ROA, la validación de origen de ruta ordinaria puede clasificar la ruta como Valid aun cuando el camino sea comercial u operacionalmente inadecuado.
Anuncio de origen no autorizado.Un ASN origina un prefijo que el titular de recurso correspondiente no ha autorizado. Si una ROA de cobertura autoriza un ASN diferente y el relying party dispone de datos validados actuales, el anuncio puede clasificarse como Invalid por desajuste de origen.[13]-[15] El término técnico origin hijack a veces se aplica a esta condición, pero la etiqueta por sí sola no establece intención maliciosa, interceptación de tráfico, conducta delictiva ni titularidad legal.
Re-originación más específica.Un ASN anuncia un prefijo más largo dentro del agregado de otra red y se presenta como origen. Una ROA de cobertura puede hacer que la ruta más específica sea Invalid porque el ASN de origen difiere o porque la longitud anunciada supera elmaxLengthde la ROA. Una más específica puede atraer la selección por ruta porque la coincidencia de prefijo más largo ocurre antes de la comparación ordinaria del path BGP. Aun así, el registro público no establece el propósito de cada re-originación ni el efecto en plano de datos de cada prefijo.
Fuga de política con origen válido.El prefijo, ASN de origen y longitud están autorizados, pero el AS path o la relación de exportación viola una política prevista. Esta es la demostración más clara de la frontera de ROV. La validación de origen responde si el origen está autorizado bajo los datos ROA disponibles. No responde si una AS intermedia estaba autorizada para proveer tránsito, si el camino siguió una relación permitida o si la ruta debía haberse exportado a ese vecino.

Las análisis públicos indican que las observaciones de abril de 2020 incluyeron una mezcla de rutas aprendidas y re-originaciones más específicas.[4] La división exacta es desconocida. Por ello sería inexacto describir las 8.870 rutas como todas orígenes no autorizados, todas fugas de política con orígenes autorizados o todas RPKI Invalid. Cada descripción sustituiría una distribución no resuelta por una categoría uniforme sin soporte en la evidencia.

NotFound también debe permanecer distinto. Cuando no existe una ROA de cobertura, la validación de origen responde normalmente NotFound.[14] Ese estado es común en un sistema de enrutamiento con cobertura incompleta. No es evidencia positiva de que el origen esté autorizado, pero tampoco es por sí mismo un resultado Invalid ni identifica de forma independiente mala conducta. Una red puede aplicar una política local para NotFound; aun así, ese estado solo indica que el conjunto de ROA validadas disponible no aportaba autorización de cobertura para evaluar el anuncio.

Estas categorías definen el alcance de controles posibles. Filtros de origen basados en un inventario de prefijos acordado del cliente pueden contener tanto orígenes no autorizados como rutas aprendidas exportadas incorrectamente en un límite de cliente. ROV podría identificar algunos anuncios de origen no autorizado o con longitud impermisible cuando existieran ROA adecuadas. Controles de relación de camino podrían abordar fugas de política con origen válido. Ninguna categoría de filtro cubre por sí sola la mezcla completa.

Lo que podría establecer la validación de origen RPKI

RPKI provee una estructura criptográficamente soportada mediante la cual titulares de recursos de direcciones pueden crear Route Origin Authorisations. Una ROA expresa que un ASN especificado está autorizado para originar un prefijo, sujeto a una longitud máxima permitida.[13] Un relying party recupera y valida material RPKI, genera cargas útiles de ROA validadas y pone esa información a disposición de sistemas de enrutamiento o motores de política. RIPE NCC opera servicios de certificación y gestión de ROA para recursos en su región de servicio, pero no programa centralizadamente cada enrutador de cada red participante.[10]

Frente a un conjunto de datos validado concreto, la validación de origen puede producir tres resultados relevantes. Una ruta esValidcuando una autorización de cobertura permite el ASN de origen y la longitud de prefijo observados. EsInvalidcuando existen autorizaciones de cobertura pero ninguna permite la combinación de origen y longitud. EsNotFoundcuando no existe autorización de cobertura disponible.[14] Son declaraciones relativas a los datos que un relying party posee en un momento dado, no propiedades globales atemporales incrustadas en la ruta.

Ese matiz importa durante un incidente de gestión de registro. Dos redes dependientes de rutas pueden poseer vistas validadas temporalmente distintas por diferencias en tiempos de sincronización de repositorio, estados de caché, caducidad o respuestas operativas. RFC 7115 analiza la importancia operacional del procesamiento por relying-party y de la información validada.[15] La evidencia congelada no revela los contenidos exactos de caché vistos por cada red durante la observación de una hora de Rostelecom.

Una afirmación de que un operador nombrado “vio un Invalid” requeriría evidencia sobre los datos validados y la política de ese operador en el momento relevante.

ROV aporta evidencia de origen útil. Si un anuncio AS12389 para un prefijo cubierto entraba en conflicto con el ASN autorizado, o si un más específico superaba unmaxLengthaplicable, un operador con política de cumplimiento podría potencialmente rechazarlo como Invalid. Esa afirmación condicional depende de que exista la ROA relevante, esté correctamente expresada, alcance una caché de relying party actual, se pase al sistema de enrutamiento y se aplique sin excepción que la anule. Quitar cualquiera de esos elementos puede cambiar el resultado en vivo.

Un resultado Valid prueba mucho menos que una ruta segura. No valida la secuencia AS intermedia. No certifica relaciones cliente-proveedor o peer. No muestra que una red intermedia estuviera habilitada para exportar una ruta aprendida. No establece que el path de datos alcanzó el destino previsto, que el tráfico no fue desviado o que los contactos operativos responderían. Un origen autorizado puede aparecer detrás de un path no previsto.

Un resultado Invalid también tiene significado acotado. Muestra un conflicto con las autorizaciones validadas de cobertura disponibles para ese relying party. Puede surgir por un origen no autorizado, una longitud de prefijo excesiva, desalineación operacional de intención o una ROA errónea. No prueba por sí mismo intención, interceptación o conducta criminal. Los operadores siguen necesitando gestión de cambios, tratamiento de excepciones e investigación para distinguir un ataque de un error de configuración o de registro.

NotFound aporta la evidencia menos específica sobre origen. No hay autorización validada de cobertura en la vista de relying party, por lo que ROV no puede confirmar ni contradecir el origen mediante una ROA. Tratar toda ruta NotFound como hostil sería una elección política local separada, no una implicación del estado de validación. También implicaría rechazar rutas ordinarias sin cobertura ROA.

La eliminación de RIPE NCC ilustra esta distinción. Eliminar 2.669 ROA podría cambiar algunas rutas de Valid o Invalid a NotFound en vistas de relying-party después de la sincronización, según las autorizaciones de cobertura restantes y el tiempo de caché.[3][5] No creó anuncios BGP AS12389, no causó que redes intermedias los exportaran, ni alteró los AS paths completos. Para el evento de Rostelecom, la intersección documentada fue solo tres titulares PI y 12 prefijos, y análisis posteriores no hallaron relación directa entre ambos incidentes.[4][5]

Por eso, la ROV universal no puede sostener que habría evitado todo el incidente. Podría haber limitado la porción que incluía anuncios Invalid bajo datos ROA vigentes, validados y con política de cumplimiento. No rechazaría por diseño de forma inherente una fuga de política de ruta aprendida cuyo origen autorizado permaneciera sin cambios. Tampoco validaría el AS path completo. Ese límite no es una debilidad de la evidencia; es la descripción correcta de para qué estaba diseñado el mecanismo.

Causa raíz

La secuencia interna iniciadora en Rostelecom es desconocida. Las fuentes públicas no identifican un cambio de configuración, comando, enrutador, empleado o fallo de automatización específico. Mostraron comportamiento de anuncio y propagación AS12389 observables externamente, no el mecanismo interno que lo generó. En consecuencia, la causa raíz del incidente de enrutamiento no puede reducirse a una acción o individuo concreto con la evidencia disponible.

Al nivel observable, el incidente comenzó con comportamiento de origen o exportación AS12389 que introdujo rutas inesperadas en BGP, incluyendo evidencia interpretada como fuga de rutas aprendidas y re-originaciones más específicas.[1][4] La aceptación y exportación posterior por otras redes amplió el alcance visible. Esta es una secuencia respaldada por observaciones de enrutamiento; no una determinación completa de causa raíz.

El incidente de RIPE NCC siguió una secuencia técnica distinta. Una actualización del software del registro clasificó algunas asignaciones independientes del proveedor como no certificables y eliminó 2.669 ROA.[3][5] Esa falla de software y gestión de registros alteró datos RPKI, mientras que el incidente de Rostelecom alteró anuncios BGP en vivo. Análisis posteriores no hallaron relación causal directa entre ambos.[4][5] Unir ambos en una única causa raíz contradice el registro documentado.

Condiciones contribuyentes

La primera condición contribuyente fue la dependencia de BGP en política local en cada frontera de red. BGP distribuye alcanzabilidad, pero los operadores determinan qué aceptar, preferir y anunciar.[12] Una ruta que debería permanecer dentro de una sola relación de política puede propagarse cuando sucesivas configuraciones lo permiten. El paso observado por AS20764, AS174 y AS3356 demuestra múltiples puntos de aceptación y exportación, aunque no revela la política concreta de ninguno.[1]

La segunda condición fue la relevancia desigual de la autorización de origen. Rutas con ROA conflictivas y cubriendo podrían ser candidatas para rechazo por ROV. Las fugas de política con origen válido no lo serían. Rutas sin ROA de cobertura serían NotFound. La mezcla desconocida de categorías impide una interpretación defendible que asigne una sola remedio de validación al conjunto completo.

La tercera condición fue la dependencia de datos operativos actuales. Una ROA correctamente creada no tiene efecto de enrutamiento a menos que relying parties la recuperen y validen, los cachés permanezcan actuales, los enrutadores reciban el resultado y la política local actúe sobre él. La eliminación en RIPE NCC afectó temporalmente la capa de registros; la sincronización de caché y la aplicación local determinaron cuándo o si ese cambio afectó las decisiones de una red.[3][10][15]

La cuarta condición fue la visibilidad fragmentada. Los proveedores de monitorización pueden ver anuncios anómalos desde puntos de observación seleccionados y advertir a operadores, pero no tienen cada Adj-RIB-In de enrutador, tabla de información de enrutamiento local, tabla de reenvío o historial de configuración. La alerta de Qrator aportó evidencia externa accionable.[1] No pudo reconstruir por sí sola la falla interna iniciadora ni garantizar que toda red afectada convergiera al mismo tiempo.

La quinta fue la distribución de controles. Filtros de prefijo de clientes, límites de prefijo máximo, registries de ruta, validación RPKI y controles de política de exportación pueden complementarse.[11][16] El registro público no establece cuáles de esos controles estaban presentes, ausentes, omitidos o mal acotados en Rostelecom o en las redes de propagación en abril de 2020. Son categorías de control relevantes, no conclusiones sobre configuraciones no documentadas.

Evento desencadenante

El desencadenante inmediato dentro de Rostelecom sigue sin identificarse. No puede asignarse responsablemente a una persona, comando, enrutador, contrato o motivo con la evidencia pública. El primer evento externo defendible es la aparición de anuncios AS12389 relevantes en los puntos de observación de Qrator alrededor de las 19:28 UTC.[1]

“Desencadenante” no debe confundirse con “condición”. Una política de vecino permisiva, cobertura ROA incompleta, datos obsoletos o monitorización limitada pueden permitir que un evento se expanda o retrasar su contención, pero ninguna de esas condiciones prueba lo que inició los anuncios. De forma similar, la eliminación separada de ROA fue contemporánea, no el disparador documentado del comportamiento de enrutamiento AS12389.[4][5]

Detección

Qrator informó detectar el evento en tiempo real y advertir a Rostelecom.[1] Sus mediciones proporcionaron el inicio aproximado, la duración, la escala y la cadena de propagación visible que sirven de ancla al análisis público. CERT-EU resumió luego el evento y señaló tanto la incertidumbre sobre si fue accidental como la cooperación de Rostelecom con la firma de reporte.[2]

La detección externa es un control de continuidad importante porque la vista interna de un operador puede no mostrar cómo vecinos o redes distantes reciben sus rutas. No revela la hora exacta del disparador interno, cada decisión de selección posterior o el impacto total en plano de datos. Una detección robusta combina telemetría local de sesiones y política con observaciones de ruta independientes.

Respuesta

Qrator señaló que Rostelecom trabajó con ella en diagnóstico y restauración tras recibir la advertencia en tiempo real.[1] Eso apoya una conclusión de coordinación de incidente. No revela la cadena interna de escalada, la identidad de los respondedores, la configuración inspeccionada, la acción correctiva seleccionada o la hora exacta de cada paso.

La respuesta de las redes de propagación no está documentada con igual detalle en el registro congelado. Sus opciones prácticas pudieron incluir filtrado de anuncios, cambio de preferencia de ruta, contacto con redes adyacentes o espera de actualizaciones corregidas, pero sería especulativo afirmar que un operador concreto usó un método determinado. La responsabilidad exige separar controles disponibles de acciones demostradas.

La respuesta de RIPE NCC siguió su propia cronología. Investigó las ROA faltantes, las restauró el 2 de abril y luego describió mejoras de monitorización.[3][5] Esa respuesta abordó la integridad y disponibilidad de los registros RPKI. No fue el mecanismo de respuesta de enrutamiento por el que se corrigieron los anuncios AS12389.

Recuperación

La observación aproximada de una hora y el informe de Qrator sobre diagnóstico y restauración respaldan la conclusión de que el evento de enrutamiento visible se puso bajo control dentro de esa ventana amplia.[1] No identifican si la recuperación resultó de retiros, anuncios corregidos, cambios de política de exportación, filtrado de vecinos o una combinación. Tampoco prueban convergencia simultánea en toda la red.

La recuperación operativa tiene al menos tres capas. La capa de anuncio requiere detener o corregir rutas inesperadas. La capa de propagación requiere que vecinos y redes downstream procesen el cambio. La capa de evidencia requiere monitorización que confirme que los caminos anómalos desaparecieron en puntos de observación útiles. Una declaración basada solo en un enrutador local puede perder propagación residual; una basada solo en colectores externos puede perder estado interno.

La recuperación del servicio RPKI fue independiente: RIPE NCC restauró las ROA eliminadas el 2 de abril.[3][5] Los relying parties luego dependieron de sus procesos de sincronización y validación para recibir el estado reparado. La restauración en repositorio y la convergencia en cada relying party son eventos relacionados pero no idénticos.

Asignación de control práctico

La responsabilidad se aclara cuando el control se asigna por decisión y no por etiqueta institucional amplia.

Actor	Control práctico	Límite de evidencia
Rostelecom / AS12389	Política de origen y exportación de rutas, filtros específicos por vecino, inventarios de prefijos, revisión de cambios, despliegue de cambios, monitorización, escalada y rollback	La secuencia de configuración interna y la secuencia de respuesta no es pública
Rascom AS20764, Cogent AS174, Level 3 AS3356 y otras redes de propagación	Sus propios filtros de importación y exportación, política de relaciones, límites de prefijos, uso de ROV, excepciones, respuesta de anomalías y anuncios posteriores	Las configuraciones de abril de 2020, estados de caché y contratos son desconocidos
Titulares de prefijos	Exactitud de registros de recursos, creación de ROA, elección de ASN de origen y`maxLength`, contactos operativos e monitorización de ruta independiente	Sus decisiones individuales no pueden inferirse uniformemente en casi 200 sistemas autónomos afectados
RIPE NCC	Sistemas de certificación y gestión de ROA, pruebas de software, monitorización de servicio, rollback, restauración y divulgación de incidentes dentro de su función	No seleccionó ni impuso centralmente los caminos usados por enrutadores operados independientemente
Relying-party operators	Sincronización de repositorios, frescura de caché, entrega de resultados de validación, políticas locales de Invalid/NotFound, excepciones y decisiones finales de enrutamiento	Ningún observador global puede inferir la vista de validación de cada relying party en cada momento
Proveedores de monitorización de ruta	Recogida desde puntos de observación, análisis de anomalías, entrega de alertas, evidencia de coordinación e informes posteriores al incidente	Observan vistas de rutas seleccionadas y no controlan anuncios ni reconstruyen cada acción interna

Esta asignación evita dos errores opuestos. El primero es concentrar toda responsabilidad en la red de origen y ignorar las decisiones de aceptación independientes que hicieron posible la propagación. El segundo es dispersar tanto el control que ningún acto tiene dueño. Rostelecom controló lo que AS12389 anunció o exportó. Cada vecino controló su propia aceptación. Cada red posterior controló otra decisión de propagación. El operador del registro controló la disponibilidad de registros de origen. Los relying parties controlaron si esos registros afectaron realmente el enrutamiento.

El control sobre una capa no implica control sobre otra. Un titular de prefijo puede publicar una ROA correcta pero no obligar a cada red a recuperarla o aplicarla. RIPE NCC puede restaurar un registro borrado pero no retirar directamente una ruta BGP de un operador no relacionado. Un proveedor de monitorización puede alertar a Rostelecom pero no ejecutar rollback. Un upstream puede rechazar una ruta en su frontera pero no reparar la configuración de origen. La continuidad operacional surge cuando estos controles trabajan en conjunto.

La asignación también fija un límite a la inferencia. Un sistema autónomo que aparece en un path reportado es evidencia de que su identificador de red apareció en la observación. No es, por sí solo, prueba de estado mental de un empleado, de violación contractual o de responsabilidad legal. Esas conclusiones requerirían registros más allá de la evidencia de enrutamiento considerada aquí.

Evidencia de causa raíz frente a evidencia contribuyente

La evidencia de causa raíz identificaría el mecanismo interno que primero produjo el comportamiento inesperado AS12389: por ejemplo, un delta de configuración, log de automatización, historial de commits, traza de sesión y marcas de tiempo coincidentes. Ninguno aparece en el registro público. Las observaciones externas de ruta establecen el evento y su alcance, pero no llenan ese hueco de evidencia interna.

La evidencia contribuyente tiene función distinta. Una ruta aceptada y exportada por redes sucesivas muestra que las políticas en vivo a lo largo de ese path observado no la bloquearon en límites anteriores. Un anuncio Invalid visible más allá de un validating network puede levantar dudas sobre frescura de datos, cumplimiento o excepciones, pero solo si se conoce el estado RPKI real de esa red. Una fuga de origen válido que pasa ROV demostraría en cambio que la autorización de origen era el control equivocado para esa porción.

La evidencia de disparo conectaría una acción interna con las primeras actualizaciones inesperadas. La evidencia de detección mostraría cuándo sistemas de monitorización identificaron la anomalía. La evidencia de respuesta registraría contactos, decisiones y cambios. La evidencia de recuperación mostraría retirada o corrección en vistas locales y externas. Mantener estas clases de evidencia separadas hace el análisis trazable y evita que un timestamp de detección haga de timestamp de disparo.

Remediación medible

El incidente respalda una remediación en capas, pero las medidas deben expresarse como controles observables y no como afirmaciones de culpa.

Primero, una red origen o de tránsito puede mantener un inventario de rutas por vecino y probar políticas de importación y exportación antes del despliegue. Medidas útiles incluyen el número de prefijos permitidos por vecino, cambios respecto a la base de referencia aprobada, ASNs de origen inesperados, anuncios más específicos y rutas cuyo estado de clasificación relacional cambia durante una actualización propuesta. Una prueba debe distinguir rutas originadas localmente de rutas aprendidas en otro lugar.

Segundo, los operadores pueden medir contención en fronteras externas. Sesiones de cliente y peer pueden verificarse para comportamiento default-deny, listas de permitidos explícitos, umbrales de prefijo máximo y reglas de exportación que impidan enviar rutas aprendidas de cliente o peer hacia relaciones no adecuadas. Prácticas de filtrado y validación generales descritas en guías operativas proporcionan un modelo en capas en lugar de una sola comprobación universal.[11][16]

Tercero, las operaciones RPKI pueden medirse de extremo a extremo. Indicadores relevantes incluyen antigüedad de sincronización de repositorio, progreso de serie de caché, disponibilidad del feed validado, conteo de rutas Valid, Invalid y NotFound por sesión, excepciones de política y alarmas por cambios abruptos en cobertura de ROA. Un registro existente en el sistema emisor es insuficiente si un caché desactualizado o un motor de política desconectado impide que influya en decisiones en vivo.[10][15]

Cuarto, los titulares de prefijos pueden revisar si las ROA reflejan orígenes actuales y simaxLengthes más restrictivo de lo operativamente necesario. Una autorización más estrecha puede hacer que algunas sub-rutas de origen no autorizado sean Invalid, pero un valor excesivamente restrictivo también puede invalidar anuncios legítimos de ingeniería de tráfico. La configuración correcta depende de los planes de enrutamiento reales, y el análisis posterior demaxLengthy exposición de subprefijos falsificados refuerza la necesidad de tratarlo como una decisión operativa precisa.[20]

Quinto, la respuesta de incidente puede evaluarse mediante métricas temporales: tiempo desde la primera actualización anómala a la alarma interna; tiempo a observación corroboradora externa; tiempo para contactar al vecino relevante; tiempo para identificar la política afectada; tiempo para detener nueva propagación; y tiempo para confirmar recuperación en múltiples puntos de observación. La cuenta de Qrator demuestra el valor de la advertencia en tiempo real y la coordinación sin revelar todos esos intervalos.[1]

Un registro posterior útil preservaría la primera actualización observada, el estado de configuración, los resultados de evaluación de política de ruta, el estado de caché RPKI, los contactos operativos, el cambio correctivo y la verificación externa final. Esa evidencia permitiría en una revisión posterior distinguir fallo de origen, fallo de exportación, fallo de aceptación, datos RPKI obsoletos y coordinación retardada. Sin ello, los investigadores se ven forzados a inferir causas internas desde observaciones globales parciales.

Estas medidas permanecen neutrales sobre intención y responsabilidad legal. Preguntan si un control existía, si operó, si su salida fue observada y la rapidez con que el sistema recuperó. Ese es un método de responsabilidad más sólido que suponer que una anomalía de ruta prueba necesariamente malicia o que una tecnología de seguridad debía haber prevenido cada categoría de ruta.

La evidencia de registro y la realidad operativa

Objetos de registro y ROA son evidencia esencial. Un registro de base de datos asocia información administrativa con un recurso de red, mientras que una ROA expresa la autorización de origen de un titular.[8][13] Exactitud, unicidad y metadatos de seguridad actuales hacen útiles esos registros para operadores e investigadores. Ayudan a responder quién está registrado para un recurso y qué ASN fue autorizado para originar un prefijo.

Los registros no operan Internet por decreto. Un speaker BGP aplica su política en ejecución a las actualizaciones recibidas. Un relying party debe obtener datos RPKI actuales. Un enrutador debe recibir resultados de validación. Un operador debe decidir qué rechazar, preferir o investigar. Los filtros de exportación deben codificar relaciones previstas, y la monitorización debe revelar cuando la propagación real diverge de esas intenciones. La recuperación coordinada debe convertir entonces evidencia en acción correctiva.

El incidente separado de RIPE NCC subraya ambos lados de esta estructura. El registro y el servicio RPKI importaron porque quitar autorizaciones podía modificar la evidencia de origen disponible para relying parties. Sin embargo, la eliminación no reescribió centralmente AS paths ni forzó que las redes aceptaran anuncios AS12389. La continuidad operacional dependió de la restauración de registros, de cachés actuales, de políticas de enrutamiento locales, de filtros activos y de coordinación de respuesta operando como cadena.

Esta visión de realidad operacional evita tratar al registro como una autoridad soberana de camino. También evita descartar los registros como irrelevantes solo porque la ejecución es local. Las ROA pueden aportar evidencia verificable por máquina que vuelve accionables ciertos conflictos de origen. Su valor es mayor cuando la precisión del registro, la distribución, la salud de caché y la política del operador son todas medibles.

Contexto de diseño posterior, no requisitos retroactivos

RFC 8212 describe una postura de rechazo por defecto para sesiones BGP externas cuando la política de importación o exportación no está configurada explícitamente.[18] Como contexto de diseño, ese enfoque reduce el riesgo de que una relación incompletamente especificada intercambie rutas por defecto. Es relevante para disciplina futura de configuración, pero no es evidencia de que todos los operadores nombrados desplegaran ese comportamiento en abril de 2020 ni que ese RFC provea un estándar retroactivo de responsabilidad.

RFC 9234 especificó después BGP Roles y el mecanismo Only-to-Customer, aportando señales de protocolo destinadas a ayudar a identificar y prevenir ciertos leaks de ruta por estructura de relación.[19] Ese trabajo aborda información que ROV no cubre: si la propagación de un path es coherente con roles declarados. No debe describirse como requisito de 2020, prueba de la causa del evento o mecanismo conocido en las sesiones observadas.

RFC 9319 analizó posteriormente consideraciones operativas alrededor demaxLengthy exposición a subprefijos de origen forjado.[20] Ayuda a explicar por qué una autorización de cobertura puede o no restringir un anuncio más específico. No establece la configuración ROA exacta vista para cada prefijo afectado en 2020 y no puede convertir la cuenta de 8.870 prefijos en un conteo de rutas Invalid.

Juntos, estos documentos posteriores muestran por qué se necesita diseño en capas. La política de rechazo por defecto puede abordar configuración de relación incompleta. BGP Roles y señales de camino pueden abordar algunos leaks de alcance de política. RPKI puede abordar algunos conflictos de origen y violaciones de longitud de prefijo. Monitorización y coordinación siguen siendo necesarias porque ningún mecanismo único valida todas las propiedades de una ruta.

Lo que este artículo no confunde

El evento de 2020 es distinto de la anomalía financiera de rutas de Rostelecom en 2017. Ese evento anterior implicó un tiempo distinto, conjunto de rutas afectadas distinto, duración distinta y pregunta de atribución distinta. No se vuelve a contar aquí, y la evidencia de aquel episodio no puede usarse para inferir intención, causalidad repetitiva o responsabilidad para el incidente de 1 de abril de 2020. Este análisis está limitado a la cadena de propagación AS12389 observada, su ventana visible de aproximadamente una hora y los controles relevantes para ese evento específico.

El artículo también es distinto de un análisis genérico de errores de configuración de ROA y dependencia de fallo común. La eliminación de ROA de RIPE NCC importa aquí solo como incidente contemporáneo separado con una superposición medida de tres titulares PI y 12 prefijos.[4][5] Una teoría más amplia de errores de creación de ROA oscurecería la pregunta concreta: qué porciones de este evento mixto podía identificar la validación de origen y cuáles requerían controles de política sensibles al path y de filtrado fronterizo.

La distinción conserva el centro de evidencia del evento. La prueba de responsabilidad de 2020 depende de anuncios AS12389, propagación por AS20764, AS174 y AS3356, categorías de ruta diferenciadas, estado de ROA dependiente de tiempo y decisiones operativas independientes en control. Sin esos elementos, el análisis se convierte en una re-narrativa de otro incidente de Rostelecom o en un ensayo abstracto sobre RPKI.

Incertidumbres esenciales

La secuencia interna de fallo iniciador permanece desconocida. La división exacta entre fugas de rutas aprendidas y re-originaciones más específicas permanece desconocida. El conjunto completo de caminos de reenvío y síntomas de usuario afectados permanece desconocido. El estado RPKI visible para cada relying party en cada momento permanece desconocido. Los filtros de importación y exportación configurados por cada red de propagación permanecen desconocidos.

La cronología de respuesta completa tampoco está disponible. Qrator documentó advertencia en tiempo real, cooperación, diagnóstico y restauración, pero no cada decisión interna.[1] La evidencia no establece un responsable individual, interceptación intencional, acto criminal, negligencia o responsabilidad legal. Tampoco mide una caída de servicio en cada sistema cuya ruta pudo aparecer en el conjunto afectado.

Estas no son advertencias menores. Definen el límite entre comportamiento de infraestructura observado e interpretación especulativa. Un relato preciso puede identificar propietarios de control y oportunidades de contención dejando abiertas conclusiones de intención y responsabilidad legal.

Conclusión

El incidente de Rostelecom del 1 de abril de 2020 mostró que la evidencia de origen y la evidencia de política de ruta responden preguntas distintas. Qrator observó un gran evento AS12389 que comenzó alrededor de las 19:28 UTC, con una duración aproximada de una hora y propagación por Rascom, Cogent y Level 3. Contó 8.870 prefijos asociados a casi 200 sistemas autónomos e informó coordinación en tiempo real con Rostelecom.[1] Esas observaciones establecen escala, propagación y respuesta, pero no una causa interna completa.

La eliminación simultánea de 2.669 ROA en RIPE NCC fue un fallo operativo separado. Análisis posteriores no hallaron relación directa con la fuga de Rostelecom y solo identificaron tres titulares PI en intersección y 12 prefijos.[3]-[5] Esa evidencia impide tanto la fusión causal como la afirmación de que todas las rutas afectadas fueran Invalid.

ROV pudo aportar evidencia útil para algunos orígenes no autorizados o subprefijos más largos cuando existieran ROA de cobertura vigentes y políticas de cumplimiento aplicadas. No pudo validar AS paths completos ni rechazar cada fuga de política con origen válido. La responsabilidad operativa restante recaía en políticas de importación y exportación en ejecución, filtrado sensible a relaciones, cachés actuales, monitorización de rutas y recuperación coordinada.

La lección de responsabilidad es, por tanto, distribuida pero concreta. Rostelecom asumía sus decisiones de anuncio y exportación. Las redes de propagación asumían sus decisiones en frontera. Los titulares de prefijos asumían la exactitud de sus autorizaciones y sus contactos. RIPE NCC asumía la confiabilidad de su certificación y gestión de ROA. Los relying parties asumían frescura de datos y cumplimiento. Los proveedores de monitorización asumían calidad y velocidad de observaciones y alertas. Ninguno controlaba todo el sistema, pero cada uno controlaba una parte identificable de la continuidad operacional.

La fuga de rutas de Rostelecom en 2020 convirtió la validación de origen en una prueba de responsabilidad