La fuga de rutas financieras de Rostelecom en 2017 convirtió la evidencia de atribución en una prueba de responsabilidad

Resumen

• BGPMon situó el evento AS12389 entre las 22:36 y aproximadamente las 22:43 UTC del 26 de abril de 2017. Contó 50 prefijos afectados en 37 sistemas autónomos. ThousandEyes utilizó un marco diferente: observó 137 prefijos originados por AS12389 durante la ventana, trató aproximadamente 100 como ordinarios o asociados con organizaciones rusas, e identificó 36 prefijos de empresas externas. Esos denominadores describen selecciones diferentes y no deben fusionarse. [1][2]
• El mecanismo de infraestructura directo fue la originación y propagación de rutas falsas. Algunos anuncios eran rutas más específicas. BGPMon destacó 203.112.90.0/24 frente a un /23 anunciado normalmente, una distinción que ayuda a explicar por qué la selección de rutas ordinaria podría preferir la ruta falsa sin comprometer el servicio afectado en sí mismo. [2]
• ThousandEyes observó que pares como Cogent, Hurricane Electric y Tata aceptaban y propagaban los anuncios de AS12389. Sus mediciones de ruta mostraron que el tráfico de al menos un servicio de comercio electrónico afectado entraba en Rostelecom y luego llegaba al destino previsto. Esto respalda el desvío de parte del tráfico de producción, no una afirmación de que cada ruta, usuario o paquete fue desviado. [1]
• Los servicios financieros, de pago, comercio electrónico, seguridad web y relacionados con certificados estaban representados entre los prefijos afectados. Los ejemplos nombrados en los informes incluían Mastercard, Visa, BNP Paribas, HSBC, Symantec y GeoTrust. La evidencia de enrutamiento no muestra que los sistemas internos de esas organizaciones estuvieran comprometidos. [1][2]
• La evidencia confirmada consiste en observaciones de origen de AS12389, la breve ventana del evento, algunos anuncios más específicos, propagación por múltiples pares y cambios de ruta medidos. Un fallo de enrutamiento o configuración es una explicación plausible. La focalización deliberada y la interceptación siguen siendo controvertidas. La identidad del actor, el desencadenante interno, la inspección de paquetes, el contenido descifrado, los efectos en las transacciones, las pérdidas y la remediación duradera siguen siendo desconocidos.
• La concentración de destinos financieros y de seguridad hizo que el patrón fuera sospechoso para BGPMon y ThousandEyes. BGPMon también observó anuncios que involucraban otros sistemas autónomos relacionados con Rostelecom, lo que respalda un fallo interno accidental como hipótesis competidora. Ninguna de las organizaciones de monitoreo tenía los registros internos de cambios, autenticación o configuración del operador. [1][2]
• La responsabilidad se deriva del control práctico, no de una conclusión no respaldada sobre el motivo. Rostelecom controlaba la creación y exportación de rutas dentro de AS12389. Los pares aceptantes controlaban los filtros, la validación, la aceptación y la propagación de rutas. Los titulares de prefijos controlaban los datos de autorización, el monitoreo externo y la escalada. Los monitores independientes controlaban la calidad y conservación de las observaciones externas.
• RPKI puede ayudar a una red a evaluar si un origen está autorizado mediante una Autorización de Origen de Ruta coincidente, pero no prueba la intención ni el mecanismo interno. El evento también es anterior a la aplicación generalizada de la Validación de Origen de Ruta. El estado histórico de ROA de cada prefijo afectado y la política de validación de cada par tendrían que establecerse antes de afirmar que RPKI habría bloqueado una ruta en particular. [11]-[14][18]
• El daño respaldado es una pérdida temporal del control de enrutamiento previsto y la exposición de parte del tráfico a una ruta de tránsito no autorizada. El registro no establece fraude en transacciones, credenciales robadas, compromiso de TLS, datos alterados, una interrupción total, una población afectada cuantificada o daños financieros. El cifrado puede reducir la exposición del contenido, pero la evidencia disponible no establece qué sesiones utilizaron un cifrado eficaz.
• Un relato decisivo requeriría registros que las observaciones de enrutamiento público no pueden proporcionar: registros de cambios y autenticación de AS12389, un informe de causa raíz, registros de filtros de pares y selección de rutas, análisis de archivos reproducibles, estado histórico de ROA, tráfico del lado del servicio y registros TLS, capturas de paquetes, registros de incidentes de clientes y evidencia sobre si las rutas medidas transportaban tráfico de producción.

Siete minutos crearon un problema de evidencia duradero

El evento fue breve, pero su estructura probatoria sigue siendo importante. BGPMon situó el inicio a las 22:36 UTC y el final alrededor de las 22:43 UTC del 26 de abril de 2017. Durante ese intervalo, los recolectores de rutas y los sistemas de monitoreo vieron a AS12389 anunciar accesibilidad para espacio de direcciones asociado con otros sistemas autónomos. Múltiples redes externas aceptaron al menos algunos de esos anuncios y los propagaron. ThousandEyes también midió cambios en las rutas de extremo a extremo en lugar de depender solo de las actualizaciones del plano de control. [1][2]

Esas observaciones establecen más que una vaga anomalía de enrutamiento. Identifican un sistema autónomo de origen, una ventana de tiempo, prefijos anunciados, propagación y una consecuencia de ruta. Los datos de enrutamiento distribuidos pueden, por lo tanto, respaldar una conclusión sólida sobre lo que se le dijo a Internet: AS12389 se representó a sí mismo como un origen para rutas que no formaban parte de su conjunto autorizado ordinario, incluido el espacio de direcciones utilizado por organizaciones externas a Rostelecom.

Las mismas observaciones establecen menos de lo que implican muchas descripciones. Una actualización BGP no contiene el motivo de un operador. Un camino cambiado no revela quién ingresó un comando, qué sistema lo generó, si se hizo mal uso de una cuenta o si una configuración planificada escapó de su alcance previsto. Incluso un conjunto sospechoso de destinos no revela la decisión interna que produjo el conjunto.

La distinción importa porque las palabras utilizadas para describir un incidente de enrutamiento pueden importar silenciosamente una conclusión. "Fuga" puede describir la propagación de rutas que no deberían haberse exportado. "Secuestro" puede describir una originación falsa o una ruta que desvía el tráfico, pero a menudo se interpreta como una prueba de intención hostil. El registro observable respalda los anuncios de origen falso y el desvío de tráfico. No establece por sí mismo una incautación deliberada, espionaje o un plan para atacar instituciones financieras.

Evaluaciones posteriores de CERT-EU y ENISA situaron el evento en debates más amplios sobre secuestro BGP y riesgo de seguridad de enrutamiento. Esas descripciones son útiles como evaluaciones institucionales atribuidas. No sustituyen los registros no divulgados de AS12389, los registros de políticas de pares ni la evidencia de tráfico del lado del servicio. [4]-[6]

La prueba de responsabilidad adecuada comienza con esa asimetría. La evidencia de enrutamiento público puede ser observada y reproducida de forma independiente. La causa interna y el propósito dependen en gran medida de los registros controlados por el operador originador y otras redes participantes. Cuanto más sólida es la evidencia externa de un cambio de enrutamiento, más específicas se vuelven las preguntas internas sin respuesta. Sin embargo, la evidencia externa no debe estirarse para proporcionar respuestas que no puede dar.

Por eso un evento de siete minutos puede permanecer sin resolver años después. La retirada puso fin a la condición de enrutamiento inmediata. No cerró la brecha de evidencia. La recuperación operativa y la explicación pública son deberes separados: uno restablece el enrutamiento, mientras que el otro muestra cómo surgió la falla, qué tráfico estuvo expuesto, por qué los controles no lo contuvieron y qué cambió después.

Los dos recuentos de prefijos responden a preguntas diferentes

BGPMon contó 50 prefijos afectados en 37 sistemas autónomos. ThousandEyes informó que AS12389 originó 137 prefijos durante la ventana relevante, luego separó aproximadamente 100 que parecían ordinarios o asociados con organizaciones rusas de 36 prefijos pertenecientes a organizaciones externas. [1][2]

Las cifras son lo suficientemente cercanas como para tentar un número titular único y lo suficientemente diferentes como para hacer que ese movimiento sea poco fiable. El recuento de 50 prefijos de BGPMon se refiere a su conjunto afectado en 37 sistemas autónomos. ThousandEyes comenzó con los 137 prefijos observados originados por AS12389 y luego los clasificó para aislar 36 prefijos de empresas externas. Cada organización utilizó sus propias observaciones y método de selección. El registro público proporcionado aquí no define una conversión que convierta un denominador en el otro.

Esto no es un detalle estadístico menor. Los recuentos son parte de la afirmación causal. Una cifra para todos los anuncios vistos desde un sistema autónomo no es lo mismo que una cifra para orígenes falsos sospechosos. Una cifra para prefijos no es una cifra para organizaciones víctimas, servicios, usuarios, sesiones o paquetes. Una cifra para sistemas autónomos no es una cifra para entidades legales. La combinación de estas unidades puede convertir una anomalía de enrutamiento acotada en una estimación de población no respaldada.

La formulación responsable conserva ambas mediciones y nombra lo que miden. BGPMon observó 50 prefijos afectados en 37 sistemas autónomos. ThousandEyes observó 137 prefijos originados por AS12389, trató alrededor de 100 como probablemente ordinarios o asociados con Rusia, e identificó 36 prefijos de empresas externas. La diferencia puede reflejar puntos de vista, sincronización, clasificación y opciones de recuento, pero esas explicaciones siguen siendo posibilidades a menos que una comparación reproducible las demuestre.

La reconstrucción histórica puede mejorar esa posición. El trabajo revisado por pares de Moriano y coautores utilizó datos históricos de BGPStream, mientras que CAIDA describe el acceso de BGPStream a material archivado de Route Views y RIPE RIS. Esas fuentes hacen posible un reanálisis reproducible en principio. No eliminan la necesidad de documentar la cobertura del recolector, los límites de tiempo, los filtros de prefijos y las reglas de clasificación. [7][8]

La disciplina del recuento es un control de responsabilidad porque limita la exageración. Una respuesta del operador, un monitor externo y una evaluación institucional deben divulgar su denominador. Si sus números difieren, la tarea es conciliar los métodos o preservar la diferencia, no elegir el número que haga que el evento parezca más grande o más pequeño.

Las rutas más específicas explican por qué la selección ordinaria podría desviar el tráfico

BGP es el sistema interdominio a través del cual las redes intercambian afirmaciones sobre la accesibilidad a bloques de direcciones IP. El mecanismo crucial del evento no fue meramente que AS12389 apareciera en algún lugar de una ruta inesperada. Se observó como el origen de rutas para espacio de direcciones asociado con otros sistemas autónomos. Algunas de esas rutas eran más específicas que las rutas cobertura utilizadas normalmente para el mismo espacio de direcciones. [1][2]

BGPMon destacó 203.112.90.0/24, mientras que el anuncio normal cubría un /23. Un /24 describe un bloque de direcciones más pequeño que un /23. Los enrutadores comúnmente prefieren la ruta más específica para el tráfico cuyo destino cae dentro de ese bloque más pequeño. Esta preferencia ocurre antes de muchas otras comparaciones de mejor ruta. El /24 falso podría, por lo tanto, atraer tráfico incluso si el /23 legítimo permaneciera visible.

Este mecanismo es importante para la disciplina de atribución. Una ruta desviada no requiere prueba de que un banco remoto, servicio de pago o proveedor relacionado con certificados fuera violado. El sistema de selección de rutas puede enviar tráfico hacia el origen falso porque la red recibió y prefirió una afirmación de accesibilidad más específica. La organización afectada puede continuar operando sus propios sistemas normalmente mientras algunos usuarios llegan a esos sistemas a través de una ruta de tránsito no prevista.

La observación de rutas más específicas también distingue el evento de una afirmación vaga de que AS12389 simplemente redistribuyó una ruta con una ruta más larga o inusual. RFC 7908 proporciona un marco de clasificación de fugas de rutas, y RFC 7454 proporciona pautas operativas de seguridad y filtrado. Esos estándares ayudan a los operadores a describir fallas de políticas de enrutamiento y controles. No determinan, solo con la evidencia pública, qué acción interna generó los anuncios de abril de 2017 ni si la acción fue intencional. [9][10]

Un análisis de responsabilidad debe separar creación, exportación, aceptación y selección. Primero, se creó o introdujo una ruta dentro de AS12389. Segundo, AS12389 la exportó a vecinos. Tercero, algunos vecinos la aceptaron y propagaron. Cuarto, los enrutadores posteriores la seleccionaron según su información y política local. Quinto, al menos parte del tráfico medido siguió la ruta resultante.

Cada paso tiene un propietario de evidencia diferente. Los registros de generación y autenticación de rutas estarían más cerca del origen. Los registros de políticas de exportación y sesión mostrarían lo que AS12389 envió a cada vecino. Los registros de pares mostrarían aceptación, filtrado y selección local. Los archivos de recolectores mostrarían lo que llegó a puntos de vista externos. Las mediciones activas mostrarían efectos de ruta de extremo a extremo. Los operadores de servicios tendrían evidencia de tráfico y aplicación.

Esa cadena evita una asignación simplista de toda la responsabilidad a un solo lugar. AS12389 era el origen falso observado y controlaba la primera exportación. Los pares no crearon la ruta, pero la aceptación y propagación ampliaron su alcance. Los titulares de prefijos no causaron el anuncio, pero su postura de autorización y monitoreo podría afectar la detección y el rechazo. Ningún participante controlaba todo Internet, sin embargo, varios controlaban puntos específicos donde el evento podría haberse prevenido, limitado o explicado.

Las mediciones de ruta prueban el desvío, no la intención de interceptación

Las observaciones del plano de control muestran qué rutas se anunciaron. Las mediciones de ruta añaden evidencia sobre dónde viajó el tráfico. ThousandEyes informó que algunos pares, incluidos Cogent, Hurricane Electric y Tata, aceptaron y propagaron los anuncios de AS12389. Sus mediciones para al menos un servicio de comercio electrónico afectado indicaron que el tráfico ingresó a la red de Rostelecom y luego continuó hasta el destino previsto. [1]

Esa forma de ruta es importante. Respalda más que un riesgo teórico de que una ruta falsa pudiera atraer tráfico. Indica que el tráfico de producción medido siguió una ruta de tránsito no autorizada. La ruta no simplemente terminó en AS12389 en el ejemplo citado; el tráfico luego llegó al destino previsto. Esto es consistente con un desvío seguido de una entrega posterior.

La medición no respalda una declaración universal. No todas las redes aceptaron o prefirieron la ruta. ThousandEyes señaló que la aceptación variaba. Una ruta vista desde uno o más puntos de medición no puede expandirse a una afirmación sobre todos los usuarios, todas las redes de origen o todos los paquetes. Las decisiones de enrutamiento varían según la ubicación, el proveedor, la sincronización y la política.

Tampoco la entrega posterior prueba interceptación. El tráfico que pasa a través de una red no prevista crea una oportunidad de observación o interferencia, pero la oportunidad no es evidencia de que se haya producido inspección. Los datos de ruta disponibles no muestran captura de paquetes, acceso a contenido, modificación, recolección de credenciales o manipulación de transacciones. No identifican un sistema de interceptación o un operador que lo haya utilizado.

El cifrado complica aún más la evaluación del daño. El cifrado eficaz puede limitar lo que una red de tránsito no prevista puede leer o cambiar, pero el registro público de enrutamiento no establece el estado de seguridad de cada sesión afectada. La presencia de servicios financieros y relacionados con certificados no prueba que el cifrado fallara. Tampoco prueba que cada conexión estuviera protegida correctamente. Se requerirían registros TLS del lado del servicio, telemetría de sesión y evidencia de paquetes para una conclusión más específica.

El daño respaldado más seguro es, por lo tanto, una pérdida del control de ruta previsto y la exposición temporal de parte del tráfico a una ruta de tránsito no autorizada. Esa es una consecuencia real de seguridad de red incluso sin prueba de compromiso de contenido. Los usuarios y operadores de servicios dependen del enrutamiento interdominio para entregar tráfico a través de relaciones de accesibilidad esperadas. Un origen falso puede romper ese límite de control mientras deja intactos los servidores de aplicaciones y las sesiones cifradas.

Esta distinción protege tanto la responsabilidad como la precisión. Minimizar el evento porque no se ha probado el robo de datos ignora el desvío de ruta demostrado. Llamar interceptación al evento porque el tráfico cruzó Rostelecom trata una posible capacidad como un acto consumado. La evidencia respalda la posición intermedia: se produjo desvío para el tráfico medido; la inspección, el descifrado, la alteración y la explotación siguen siendo desconocidos.

Cuatro clases de evidencia mantienen la atribución honesta

El evento se entiende mejor a través de cuatro clases de evidencia: confirmada, probable, disputada y desconocida. Mezclar esas clases es el camino principal desde una observación técnica hasta una acusación no respaldada.

La evidencia confirmada incluye las observaciones de origen de AS12389, la ventana de 22:36 a aproximadamente 22:43 UTC, anuncios falsos, algunas rutas más específicas, propagación por múltiples pares y cambios de ruta medidos. Las categorías de servicio mencionadas y los ejemplos también están respaldados cuando están vinculados a los informes de monitoreo. Estas conclusiones dependen de observaciones distribuidas en lugar de acceso a los sistemas privados de Rostelecom. [1][2]

Las explicaciones probables deben permanecer condicionales. Un fallo interno de enrutamiento o configuración es un candidato plausible de causa raíz. BGPMon observó anuncios simultáneos que involucraban otros sistemas autónomos relacionados con Rostelecom, un patrón que puede respaldar la hipótesis de un error interno más amplio en lugar de un conjunto objetivo externo cuidadosamente limitado. La evidencia no establece la configuración, comando o sistema exacto que falló.

Las interpretaciones disputadas se refieren a la focalización deliberada y la intención de interceptación. La concentración de destinos financieros, de pago, comercio electrónico y relacionados con la seguridad, combinada con rutas más específicas recién introducidas, hizo que el patrón pareciera sospechoso a BGPMon y ThousandEyes. La sospecha es relevante porque da forma a la respuesta a incidentes y la preservación de evidencia. No es una conclusión de propósito.

Las incógnitas incluyen quién inició el cambio, si esa persona estaba autorizada, el mecanismo interno exacto, la razón de los prefijos seleccionados, si se inspeccionaron paquetes, si se descifró algún contenido, si las transacciones se vieron afectadas, si los usuarios perdieron datos o dinero, la población afectada completa bajo un método de medición común y qué remediación duradera ocurrió.

CERT-EU y ENISA utilizaron posteriormente un marco más orientado a amenazas en sus discusiones institucionales. Esas evaluaciones merecen una atribución precisa porque los organismos públicos utilizan incidentes pasados para explicar el riesgo de enrutamiento. Su marco no crea acceso a los registros de cambios de AS12389 ni a los registros de paquetes de servicios afectados. Una etiqueta categórica posterior no debe tratarse como nueva evidencia primaria sobre la intención del operador en 2017. [4]-[6]

La revisión del año de seguridad de enrutamiento de Internet Society sitúa el episodio dentro de un patrón mucho más amplio de incidentes de enrutamiento y preocupaciones de prevención. Ese contexto ayuda a mostrar por qué el caso es importante más allá de un operador. No debe aplanar el evento en una estadística genérica ni responder a sus preguntas de atribución no resueltas. [3]

Una escalera de evidencia aclara qué justificaría un lenguaje más contundente. Las actualizaciones de rutas distribuidas pueden establecer una originación falsa. Los datos de propagación desde múltiples puntos de vista pueden establecer el alcance. Las mediciones de ruta activas pueden establecer el desvío desde puntos de vista particulares. Los registros de servicios pueden establecer conexiones recibidas, estado TLS y efectos de aplicación. Las capturas de paquetes pueden establecer el contenido del tráfico y la modificación dentro de su alcance. Los registros de cambios y autenticación del operador pueden identificar la acción interna.

Una investigación de causa raíz puede conectar esos registros con la responsabilidad y la intención.

El registro público de abril de 2017 alcanza los primeros tres niveles para partes del evento. No alcanza los niveles posteriores. Ese límite permite una responsabilidad operativa firme sin asignar un motivo no respaldado. Se puede exigir responsabilidad a Rostelecom por explicar las rutas originadas y exportadas por AS12389 incluso cuando la focalización deliberada no está probada. Se puede preguntar a los pares sobre la aceptación y propagación incluso si no crearon las rutas. Se puede preguntar a los titulares de prefijos sobre la autorización y el monitoreo sin implicar que causaron el incidente.

La evidencia de atribución también debe ser simétrica. La evidencia que respalda una hipótesis hostil debe preservarse, incluida la concentración de objetivos y los anuncios más específicos. La evidencia que respalda una hipótesis de falla accidental también debe preservarse, incluidos los anuncios que involucran sistemas autónomos relacionados. Un relato creíble explica por qué una hipótesis finalmente encaja mejor o afirma que el registro disponible no puede decidir entre ellas.

Esa disciplina no es indecisión. Asigna una responsabilidad clara por acciones observables mientras se niega a inventar el estado mental detrás de ellas. En incidentes de enrutamiento, esa es a menudo la diferencia entre un análisis responsable y una narración geopolítica.

AS12389 controló la evidencia interna más probatoria

Rostelecom, como operador de AS12389, controlaba el sistema que los observadores públicos vieron originando y exportando las rutas. Eso no prueba que la alta dirección dirigiera el evento o que un individuo actuara intencionalmente. Sí identifica a la organización más cercana al proceso de generación de rutas y a la evidencia más capaz de explicarlo.

Los controles relevantes comienzan antes de la exportación. Los permisos de generación de rutas determinan qué cuentas, sistemas y flujos de trabajo pueden introducir un prefijo en el proceso de enrutamiento. La revisión de cambios puede requerir una segunda verificación en modificaciones sensibles o inusualmente amplias. Las listas permitidas de prefijos pueden restringir los anuncios de clientes e infraestructura al espacio de direcciones esperado. La política de salida puede detener una ruta que no debería salir del sistema autónomo. El monitoreo puede detectar un origen inesperado o un conjunto repentino de anuncios más específicos.

Los procedimientos de retirada pueden acortar la exposición después de la detección.

Estas son categorías de control, no afirmaciones sobre la configuración exacta de AS12389 en abril de 2017. El registro público no revela qué controles existían, cuáles fallaron o cuáles fueron eludidos. Tampoco revela si el conjunto de rutas provino de un comando manual, automatización, una sesión de cliente, un error de redistribución interna, credenciales comprometidas u otro mecanismo.

La evidencia del operador debe conectar las categorías. El historial de configuración podría mostrar qué cambió. Los registros de autenticación podrían mostrar qué cuenta o sistema realizó el cambio. Los registros de aprobación podrían mostrar si estaba autorizado. Los registros de sesión BGP y exportación podrían mostrar qué rutas se enviaron a qué vecinos. Los registros de alertas podrían mostrar cuándo el personal se enteró por primera vez. Los registros de incidentes podrían mostrar quién ordenó la retirada y cómo se determinó el conjunto afectado.

La velocidad por sí sola no es suficiente. Los anuncios se retiraron después de una ventana corta, pero una duración de siete minutos no revela si el monitoreo funcionó, un par dio la alarma, un operador notó un error o la condición de originación terminó automáticamente. Un final rápido reduce la exposición; no explica la detección ni la efectividad del control.

La divulgación es el punto de control final del operador de origen. Un relato público de incidente útil distinguiría los hechos de ruta observados del hallazgo de causa raíz del operador. Declararía el alcance de exportación afectado, explicaría si los prefijos fueron introducidos por configuración, automatización, un cliente u otra fuente de ruta, identificaría el control que falló, describiría la contención y proporcionaría evidencia de remediación acotada. No necesita exponer credenciales, topología confidencial del cliente ni detalle explotable.

Sin ese relato, los observadores externos aún pueden asignar responsabilidad operativa por el origen y la exportación. No pueden asignar de manera confiable responsabilidad personal, intención o asignación de fallas internas. La asimetría de la evidencia es en sí misma un hecho de responsabilidad: la organización que controlaba el proceso de ruta también controlaba los registros necesarios para resolver la incertidumbre más consecuente.

Un operador no puede responder a esa brecha señalando que BGP está distribuido. La distribución significa que AS12389 no controlaba qué redes remotas aceptaban la ruta. No borra el control sobre lo que AS12389 originó y exportó. Por el contrario, localizar el origen falso en AS12389 no borra el papel de los vecinos que lo propagaron. La responsabilidad práctica sigue a cada punto de control en lugar de colapsar toda la cadena en un solo actor.

Los pares aceptantes controlaron el límite de propagación del evento

Un origen falso se vuelve ampliamente consecuente solo cuando otras redes lo aceptan y propagan. ThousandEyes observó a Cogent, Hurricane Electric y Tata entre los pares que transportaban anuncios de AS12389. Esa observación no muestra el proceso completo de política o decisión dentro de ninguna red nombrada. Sí muestra que la aceptación de pares fue parte del camino desde el origen hasta el desvío medido. [1]

La pregunta de responsabilidad del par difiere de la de Rostelecom. Una red aceptante no necesariamente sabía que una ruta era falsa cuando llegó, y no creó la afirmación original. Sin embargo, controlaba la política de importación local, los filtros de clientes y pares, el uso de información de autorización de rutas, la alerta de anomalías, la exportación posterior y la coordinación de emergencia.

Las responsabilidades de filtrado deben describirse con evidencia en lugar de asumirse a partir de una etiqueta comercial. Una red puede tratar a un vecino como cliente, par o proveedor de tránsito según su propia política. Las observaciones públicas no revelan esos contratos ni las reglas de importación de cada sesión. Tampoco muestran si una ruta pasó porque no existía ningún filtro, una lista permitida era demasiado amplia, los datos del registro estaban incompletos, una señal de validación no estaba disponible o la política local aceptaba una advertencia.

RFC 7454, NIST SP 800-189 y los materiales de operadores de MANRS proporcionan referencias de control para filtrado, coordinación e intercambio de rutas resiliente. Respaldan la expectativa de que las redes deben saber qué rutas puede anunciar un vecino, rechazar anuncios improbables cuando la información confiable lo permita, monitorear anomalías y mantener rutas de contacto para una corrección rápida. No establecen que un par en particular violara un deber específico en abril de 2017. Esa conclusión requeriría la política histórica del par, los registros de selección de rutas y alertas. [10][15]-[17]

La propagación crea un deber de evidencia proporcional. Un par que transportaba una ruta más específica inesperada debería poder mostrar lo que recibió, qué validación o filtros se ejecutaron, qué preferencia local la seleccionó, dónde exportó la ruta y cuándo la retiró. La evidencia retenida permite una distinción posterior entre una limitación inevitable en los datos de autorización disponibles y una falla de política controlable.

La misma evidencia puede prevenir una culpa injusta. Un par puede mostrar que no existía un ROA aplicable, que los datos del registro no definían un conjunto de clientes lo suficientemente estrecho, que aceptó la ruta bajo una política documentada o que cambió de rumbo rápidamente después de una alerta. Alternativamente, los registros pueden mostrar que una restricción conocida estaba ausente o fue ignorada. Las observaciones de rutas públicas identifican las redes a las que preguntar; no proporcionan la respuesta completa.

El enrutamiento distribuido produce, por lo tanto, una responsabilidad distribuida. AS12389 es responsable del origen falso y la exportación. Las redes aceptantes son responsables de los controles en su propio límite. Esas responsabilidades se superponen en efecto sin volverse idénticas en causa.

Los titulares de prefijos y los monitores independientes controlaron diferentes formas de preparación

Las organizaciones cuyo espacio de direcciones apareció en el conjunto afectado no crearon los anuncios de AS12389. Su responsabilidad se refiere a la preparación, detección, escalada y evidencia del lado del servicio, no a la culpa por el origen.

Los titulares de prefijos pueden mantener registros de enrutamiento y autorización precisos, organizar monitoreo de origen externo, definir contactos de escalada de proveedores y preservar evidencia de servicio cuando ocurre una alerta. Cuando sea operativamente adecuado, pueden considerar anunciar una ruta más específica mitigante a través de proveedores legítimos. Cualquier mitigación debe evaluarse cuidadosamente porque los cambios de ruta realizados durante un incidente pueden crear nuevos problemas de accesibilidad.

El contexto histórico es esencial. El evento ocurrió antes de la aplicación generalizada de la Validación de Origen de Ruta. El registro disponible no establece qué prefijos afectados tenían ROA válidos en abril de 2017, qué longitudes máximas autorizaban esos ROA, o qué redes receptoras utilizaban validación. Por lo tanto, sería incorrecto tratar la ausencia de rechazo universal como prueba de que cada titular de prefijo descuidó RPKI o de que cada par ignoró una señal inválida disponible.

Las organizaciones de monitoreo controlaban un punto de control diferente: la calidad de la evidencia externa. BGPMon proporcionó una ventana de evento acotada, un recuento de prefijos afectados, un denominador de 37 sistemas autónomos, un ejemplo más específico e hipótesis competidoras sobre la intención. ThousandEyes proporcionó su marco de observación de 137 prefijos, la clasificación que lleva a 36 prefijos de empresas externas, observaciones de propagación de pares, ejemplos de servicios afectados y rutas medidas. [1][2]

Esos registros son más sólidos cuando sus puntos de vista, límites de tiempo y métodos de clasificación siguen siendo reproducibles. El acceso a datos de BGPStream de CAIDA y la reconstrucción histórica de Moriano y coautores ilustran cómo el material archivado de Route Views y RIPE RIS puede respaldar análisis posteriores. Una reconstrucción posterior aún necesita declarar qué recolectores e intervalos de actualización se utilizaron y cómo se agruparon los prefijos. [7][8]

Los monitores independientes también tienen un deber de lenguaje. Pueden describir una selección sospechosa y explicar por qué las rutas más específicas generan preocupación. Deben declarar por separado si poseen evidencia de propósito, acceso interno o interceptación de contenido. Esta separación permite que un monitor advierta a los operadores rápidamente sin convertir una puntuación de anomalía en un veredicto de atribución.

Los operadores de servicios afectados poseen la evidencia necesaria para evaluar el daño posterior. Los registros de tráfico pueden mostrar cambios de conexión. Los registros TLS pueden mostrar si las sesiones se completaron de forma segura. Los registros de aplicaciones y transacciones pueden mostrar errores, fraude o ningún efecto material. Los informes de clientes pueden identificar geografía y duración. Ninguno de esos registros puede reconstruirse de manera confiable solo a partir de actualizaciones de ruta.

La división práctica es clara. Los titulares de prefijos controlan la preparación y la escalada. Los monitores independientes controlan la observación y el análisis externos. Los operadores de servicios controlan la evidencia de los efectos en las aplicaciones y los clientes. Cada uno puede cerrar una parte diferente del registro del incidente, y ninguno debe afirmar que la evidencia de otra parte es innecesaria.

RPKI puede restringir orígenes falsos pero no puede decidir el motivo

RPKI es central en la discusión de control porque el evento involucró un origen falso. Su papel debe enunciarse de manera estricta. La arquitectura RPKI respalda declaraciones criptográficamente verificables sobre los recursos numéricos de Internet. Una Autorización de Origen de Ruta identifica un sistema autónomo autorizado para originar prefijos específicos dentro del alcance del objeto. La Validación de Origen de Ruta permite que una red receptora compare un anuncio de origen BGP con los datos de autorización disponibles. [11]-[14][18]

Ese mecanismo puede dar a una red evidencia útil de que un origen observado no coincide con una autorización de cobertura. Si un prefijo afectado tenía un ROA adecuado en abril de 2017 y una red receptora realizaba validación, un origen de AS12389 podría haber producido una señal que la política podría rechazar o despriorizar. El resultado real dependería de la autorización histórica, la longitud del prefijo, los datos de validación y la política de enrutamiento local.

Varios límites se derivan de esto.

Primero, RPKI no prueba la intención. Una ruta puede fallar la validación de origen debido a un anuncio hostil, un error del operador, una autorización obsoleta, un ROA con alcance incorrecto u otro desajuste. La señal se refiere a la autorización del origen, no al estado mental o la identidad de la persona detrás de la actualización.

Segundo, la validación de origen no explica el desencadenante interno. Puede identificar un conflicto en un límite receptor mientras deja sin respuesta si la ruta provino de configuración manual, automatización, un cliente, acceso comprometido o una ruta de redistribución no prevista.

Tercero, RPKI no valida por sí mismo la ruta AS completa. Una declaración de origen autorizada no es una prueba criptográfica de que cada relación de tránsito o segmento de ruta sea legítimo. La clasificación de fugas de rutas de RFC 7908 y las pautas de filtrado de RFC 7454 abordan preocupaciones operativas y de política más amplias que no pueden reducirse a una verificación de origen. [9][10]

Cuarto, una afirmación retrospectiva requiere datos retrospectivos. La cobertura actual de RPKI, la práctica de validación o las pautas de registro no pueden proyectarse hacia atrás sin evidencia. Las preguntas relevantes son qué prefijos afectados tenían ROA adecuados el 26 de abril de 2017, qué longitudes de prefijo autorizaban, qué datos de validación recibió cada par y cómo cada par trató el estado resultante.

Quinto, un control es tan útil como su integración operativa. Los registros de autorización deben ser precisos y mantenidos. Los validadores y la distribución de datos deben ser monitoreados. La política de ruta debe definir qué sucede cuando una señal está presente o ausente. Los operadores necesitan procedimientos de excepción, reversión y contacto de emergencia. MANRS y las pautas de NIST sitúan el filtrado, la validación, la coordinación y la higiene de enrutamiento global dentro de una práctica operativa más amplia en lugar de presentar RPKI como una respuesta completa. [15]-[17]

Estas limitaciones no debilitan el caso de la seguridad del origen de ruta. Aclaran lo que el control puede probar. RPKI puede reducir la dependencia de una afirmación de origen no autenticada y puede ayudar a las redes receptoras a tomar una decisión más informada. No puede determinar por qué AS12389 anunció las rutas, si se inspeccionó el tráfico o quién debe asumir toda la responsabilidad.

El caso de abril de 2017 es, por lo tanto, un argumento a favor de controles en capas. La autorización de origen puede restringir la aceptación. Los filtros de prefijos pueden restringir lo que un vecino exporta. El monitoreo de cambios de origen y más específicos puede reducir el tiempo de detección. La coordinación entre pares puede acelerar la retirada. La medición activa puede mostrar el impacto en la ruta. Los registros de servicio pueden evaluar el daño. Los registros del operador pueden explicar la causa.

Ninguna capa proporciona el relato completo. El diseño institucional más sólido hace que las capas produzcan evidencia que pueda reconciliarse después de un evento.

Los estándares de seguridad de enrutamiento crean deberes de capacidad, no veredictos retroactivos

Los documentos de estándares y mejores prácticas son más útiles aquí como mapas de control. RFC 7908 proporciona un vocabulario para las fugas de rutas. RFC 7454 aborda la seguridad operativa de BGP y el filtrado. RFC 6811 y RFC 7115 describen la validación de origen y su uso operativo. RFC 6480 y RFC 6482 definen los fundamentos de RPKI y ROA. NIST SP 800-189 y MANRS conectan el filtrado, la validación, la coordinación y el monitoreo con operaciones interdominio resilientes. RIPE NCC explica la Validación de Origen BGP y sus límites. [9]-[18]

Juntos, respaldan deberes institucionales que son medibles sin afirmar una violación legal de 2017. Una red de origen debe restringir qué prefijos puede crear y exportar. Una red receptora debe mantener controles de importación proporcionados y utilizar datos de autorización confiables cuando estén disponibles. Un titular de prefijo debe mantener registros precisos y monitorear orígenes inesperados. Los operadores deben preservar registros y contactos que permitan una retirada rápida y una explicación posterior.

Los deberes son capacidades, no eslóganes. "Usamos RPKI" está incompleto sin el ROA histórico, el estado de validación y la respuesta local. "Filtramos clientes" está incompleto sin el conjunto de prefijos permitidos y la evidencia de que el filtro se ejecutó. "Monitoreamos BGP" está incompleto sin umbrales de alerta, marcas de tiempo y escalada. "La ruta fue retirada" está incompleto sin el registro de detección y decisión.

Los documentos no establecen que Rostelecom o cualquier par nombrado fallara un control específico durante el evento. Eso requeriría una comparación entre el requisito histórico, la arquitectura real del operador y la evidencia del incidente. Los estándares actuales aún pueden definir las preguntas que una institución responsable debería poder responder ahora.

Este enfoque evita dos errores. Uno es el fatalismo tecnológico, en el que el diseño distribuido de BGP se convierte en una razón por la que nadie puede ser responsable. El otro es la certeza tecnológica, en la que un control moderno se declara una prevención histórica garantizada. La evidencia no respalda ninguno de los dos.

La responsabilidad institucional, en cambio, pregunta si cada actor podría demostrar su control en el punto que poseía. Ese estándar sigue siendo válido incluso cuando el sistema global no tiene un operador central y el motivo original no está resuelto.

El daño debe medirse sin inventar una violación

El conjunto afectado incluía servicios financieros, de pago, comercio electrónico, seguridad web y relacionados con certificados. Los informes mencionaron a Mastercard, Visa, BNP Paribas, HSBC, Symantec y GeoTrust entre los ejemplos asociados con los prefijos afectados. Esos nombres explican por qué los observadores tomaron el patrón en serio. No prueban el compromiso de las organizaciones o sus clientes. [1][2]

El daño confirmado es un daño de enrutamiento. Parte del tráfico perdió su ruta prevista y cruzó una red de tránsito no autorizada. Eso cambió el límite de confianza para las conexiones afectadas y redujo el control de los titulares de prefijos sobre cómo los usuarios llegaban a sus servicios.

Los posibles daños secundarios requieren evidencia separada. El fraude en transacciones requeriría registros de transacciones. El robo de credenciales requeriría evidencia de autenticación, usuario o forense. El compromiso de TLS requeriría evidencia de sesión y certificado. La alteración de datos requeriría registros de paquetes, aplicaciones o integridad. Una interrupción requeriría mediciones de disponibilidad vinculadas a los usuarios afectados. El daño financiero requeriría registros de pérdidas y análisis causal.

Ninguna conclusión de ese tipo se deriva meramente de que una ruta pase por AS12389. La entrega posterior puede permitir que el servicio permanezca disponible, y el cifrado puede limitar el contenido legible. Ningún hecho elimina el riesgo. Ninguno prueba la seguridad de cada conexión.

La notificación de daños debe, por lo tanto, utilizar una escala en capas. La pérdida de control de ruta está establecida. La exposición a una ruta de tránsito no prevista está establecida para el tráfico medido. La visibilidad del contenido es posible pero no probada. La interceptación activa es disputada y no probada. El compromiso de datos, los efectos en las transacciones y las pérdidas son desconocidos.

Esta escala da a las organizaciones afectadas espacio para informar honestamente. Pueden reconocer un evento grave de control de red mientras continúan las investigaciones. Pueden agregar hallazgos del lado del servicio más tarde sin reescribir las observaciones de enrutamiento. Si no se encuentra ningún daño en la aplicación, ese resultado debe informarse como evidencia dentro del alcance examinado, no como prueba de que el origen falso fue inofensivo.

La misma disciplina se aplica a las agencias públicas y los investigadores. Un marco de amenaza sólido puede motivar mejores controles, pero no debe convertir categorías de posible daño en hechos del incidente. La credibilidad de la defensa de la seguridad del enrutamiento depende de mantener esa línea.

La divulgación debe responder preguntas de control incluso cuando la atribución sigue sin resolverse

Un informe de incidente no necesita identificar a un actor hostil para ser útil. Puede declarar lo que el operador sabe sobre la creación, exportación, propagación, detección y retirada de la ruta, mientras marca el motivo como no resuelto.

Para AS12389, el relato útil mínimo identificaría la clase de origen de los anuncios, el conjunto de rutas y el alcance de exportación, el canal de detección, la decisión de retirada, el período afectado y los cambios de control realizados posteriormente. Podría explicar si el evento involucró configuración, automatización, entrada del cliente u otro mecanismo interno sin exponer comandos o credenciales sensibles.

Las redes aceptantes podrían revelar si las rutas fueron tratadas como anuncios de cliente, par o tránsito; si se aplicaron verificaciones de prefijo, origen o ruta; si los datos históricos de RPKI produjeron una señal utilizable; y cómo se eliminaron las rutas. Los titulares de prefijos podrían revelar cuándo fueron alertados, a qué proveedores contactaron y si la evidencia del servicio mostró efectos medibles en los clientes.

El registro público proporcionado por los monitores ya separa algunos hechos de las interpretaciones. BGPMon y ThousandEyes documentaron la sincronización, los conjuntos de rutas, las rutas más específicas, la propagación y los efectos de ruta, luego discutieron por qué el patrón de objetivos parecía sospechoso. BGPMon también conservó evidencia que respalda una hipótesis de falla accidental. [1][2]

Ese es el modelo para la incertidumbre responsable. Un informe no debe ocultar evidencia sospechosa para evitar el riesgo reputacional. No debe presentar la sospecha como intención. Debe nombrar los registros que decidirían el asunto y declarar si esos registros fueron examinados.

La divulgación también necesita una prueba de remediación duradera. Una declaración de que las rutas fueron retiradas describe la contención. No demuestra que los permisos cambiaron, los filtros se estrecharon, las alertas mejoraron, los registros se conservaron o la coordinación entre pares se probó. La evidencia de remediación debe identificar el control que falló, el cambio, la prueba y el resultado del monitoreo.

Las instituciones tienen diferentes restricciones de divulgación. Los operadores pueden proteger información sensible de seguridad y confidencial del cliente. Los proveedores de servicios financieros y de seguridad pueden evitar exponer patrones de tráfico. Los pares pueden tratar las políticas como comercialmente sensibles. Esas restricciones justifican la agregación y la redacción, no una conclusión sin evidencia.

El interés público es más fuerte en el límite entre la operación confirmada y el propósito alegado. Un relato claro puede decir que AS12389 originó rutas falsas, los pares propagaron algunas y el tráfico medido cambió de ruta. También puede decir que la focalización deliberada, la interceptación y el espionaje no están establecidos. Esa combinación es más responsable que la negación a través de la vaguedad o la acusación a través de la inferencia.

Evidencia que podría cambiar la evaluación

Varios registros podrían fortalecer, estrechar o revertir materialmente partes de la evaluación actual.

El historial de configuración de AS12389 podría identificar la fuente exacta de la ruta y el cambio. Los registros de autenticación y autorización podrían identificar la cuenta o el sistema involucrado y si la acción siguió un flujo de trabajo aprobado. Los registros de exportación y sesión BGP podrían establecer qué vecinos recibieron qué anuncios. Los registros de alertas y respuesta a incidentes podrían mostrar cómo se detectó el evento y por qué se produjo la retirada.

Un informe de causa raíz de Rostelecom podría conectar esos registros, distinguir el error de la acción no autorizada y documentar la remediación. Su credibilidad dependería del método, la conservación de la evidencia y si se examinaron las hipótesis competidoras. Una mera afirmación de accidente o ataque no resolvería la cuestión de atribución.

Los registros de filtrado, validación y selección de pares aceptantes podrían mostrar por qué pasaron rutas específicas. Las instantáneas históricas de políticas podrían distinguir un control faltante de datos de autorización faltantes. Los registros de exportación podrían mostrar el límite de propagación, mientras que los registros de contacto y tickets podrían mostrar cuándo los pares coordinaron la retirada.

Un reanálisis reproducible de las actualizaciones archivadas de RIPE RIS y Route Views podría reconciliar los marcos de recuento de BGPMon y ThousandEyes o explicar por qué difieren. También podría mapear la propagación a través del tiempo y los puntos de vista. El análisis necesitaría recolectores declarados, marcas de tiempo, deduplicación y métodos de clasificación de prefijos. [7][8]

Los registros históricos de ROA para cada prefijo afectado podrían mostrar si la validación de origen habría producido un resultado útil en ese momento. El análisis necesitaría el origen autorizado relevante, el prefijo y el alcance de longitud máxima, además de evidencia de qué datos de validación tenía cada red receptora y cómo respondió su política local.

Los registros de tráfico, TLS, autenticación, aplicación y transacciones de los servicios afectados podrían establecer si las conexiones desviadas se completaron, fallaron o mostraron efectos sospechosos. Las capturas de paquetes podrían proporcionar evidencia más directa dentro de su punto de vista y período de retención limitados. Los registros de incidentes y pérdidas de clientes podrían conectar los efectos técnicos con personas u organizaciones.

La evidencia de que la ruta medida no transportaba tráfico de producción estrecharía la conclusión de daño. La evidencia de inspección de paquetes, modificación o uso de credenciales la expandiría. La evidencia de un cambio de ruta deliberado y autenticado vinculado a un actor responsable cambiaría materialmente la evaluación de atribución. La evidencia de un error interno y un control correctivo probado fortalecería la explicación de falla accidental.

Hasta que tales registros estén disponibles, la conclusión debe permanecer acotada. Los anuncios de AS12389 y el desvío de ruta están confirmados. Un fallo de enrutamiento o configuración es plausible. La focalización deliberada, la interceptación y la identidad del actor no están resueltas. El compromiso de datos y las pérdidas no están probados.

La responsabilidad comienza donde se controla la evidencia

El evento de abril de 2017 no es principalmente una historia sobre si una etiqueta alarmante vence a otra. Es una prueba de cómo se asigna la responsabilidad en una infraestructura que está distribuida por diseño.

Rostelecom controlaba la creación de rutas, la política de exportación y los registros internos más cercanos a la causa. Los pares aceptantes controlaban los filtros, la validación, la propagación y su propia evidencia. Los titulares de prefijos controlaban los datos de autorización, el monitoreo y la escalada. Los monitores independientes controlaban la observación externa y la transparencia analítica. Los servicios afectados controlaban la evidencia del impacto en el cliente y la aplicación.

Ningún actor controlaba toda la ruta. Cada uno controlaba un punto de control donde era posible la prevención, limitación, detección o explicación. Eso es suficiente para la responsabilidad operativa incluso cuando el motivo sigue siendo desconocido.

El evento también muestra por qué RPKI debe tratarse como un control acotado. La autorización de origen puede ayudar a las redes receptoras a rechazar o reducir la confianza en un origen falso cuando los datos históricos y la política respaldan ese resultado. No puede identificar a la persona detrás de la actualización, probar la interceptación ni reemplazar el filtrado de exportación, la coordinación entre pares, la medición de ruta y la investigación del lado del servicio.

La conclusión más sólida es, por lo tanto, firme y limitada. Las observaciones públicas prueban que AS12389 originó rutas falsas, que múltiples pares propagaron algunos anuncios y que el tráfico medido cambió de ruta. No prueban que Rusia o Rostelecom tuvieran la intención de espiar, que se inspeccionara el tráfico o que se perdieran datos financieros o dinero.

La responsabilidad no requiere inventar esos hechos. Requiere que los operadores que controlaban la evidencia decisiva la preserven, la prueben y expliquen lo que muestra.

Fuentes

Acceso verificado: 2026-07-25

1. ThousandEyes, mecanismo del evento, evidencia de ruta y superficie de servicio afectada:https://www.thousandeyes.com/blog/rostelecom-route-leak-targets-ecommerce-services
2. BGPMon, sincronización del evento, recuentos, ejemplo más específico e hipótesis competidoras:https://www.bgpmon.net/bgpstream-and-the-curious-case-of-as12389/
3. Internet Society, contexto anual de seguridad de enrutamiento independiente:https://www.internetsociety.org/blog/2018/01/14000-incidents-2017-routing-security-year-review/
4. CERT-EU, resumen institucional posterior del incidente y daño:https://cert.europa.eu/publications/threat-intelligence/threat-memo-190611-1/pdf
5. ENISA, análisis de seguridad BGP y recomendaciones de control:https://www.enisa.europa.eu/sites/default/files/publications/WP%202019%20-%20O.1.2.3.P%20-%20Short%20position%20paper%20%E2%80%94%20analysis%20of%20a%20technical%20topic%20%28BGP%20security%29.pdf
6. CERT-EU, evaluación de amenazas atribuida posterior:https://cert.europa.eu/publications/threat-intelligence/threat-memo-bgp-hijacking-russia/pdf
7. Moriano y coautores, reconstrucción histórica revisada por pares:https://pmoriano.com/docs/COMNET21.pdf
8. CAIDA BGPStream, acceso a datos históricos de Route Views y RIPE RIS:https://bgpstream.caida.org/data
9. IETF RFC 7908, definiciones y clasificación de fugas de rutas:https://datatracker.ietf.org/doc/html/rfc7908
10. IETF RFC 7454, seguridad operativa de BGP y guía de filtrado:https://datatracker.ietf.org/doc/html/rfc7454
11. IETF RFC 6811, estados de validación de origen BGP:https://datatracker.ietf.org/doc/html/rfc6811
12. IETF RFC 7115, uso operativo de la validación de origen RPKI:https://datatracker.ietf.org/doc/html/rfc7115
13. IETF RFC 6480, arquitectura RPKI:https://datatracker.ietf.org/doc/html/rfc6480
14. IETF RFC 6482, perfil de Autorización de Origen de Ruta:https://datatracker.ietf.org/doc/html/rfc6482
15. NIST SP 800-189, seguridad BGP y guía de intercambio resiliente:https://csrc.nist.gov/pubs/sp/800/189/final
16. MANRS, acciones de operadores de red:https://manrs.org/netops/
17. MANRS, guía de implementación para operadores de red:https://manrs.org/netops/bcop/
18. RIPE NCC, explicación y límites de la Validación de Origen BGP:https://www.ripe.net/manage-ips-and-asns/resource-management/rpki/bgp-origin-validation/