En síntesis

  • ARTEMIS es un sistema de código abierto desplegado por el propio operador. Compara las observaciones actuales de BGP con una intención de enrutamiento definida localmente y aporta un contexto que los recolectores públicos no pueden proporcionar por sí solos.
  • El estudio de FORTH y CAIDA de 2018 informó de detección en segundos y neutralización en menos de un minuto bajo las condiciones evaluadas; no constituye una garantía universal para entornos de producción.
  • Para mitigar un incidente, ARTEMIS puede anunciar rutas más específicas o activar procedimientos propios. Sin embargo, los filtros, las políticas obsoletas, la visibilidad incompleta y unos permisos demasiado amplios pueden convertir una respuesta rápida en un segundo incidente.
  • La viabilidad actual del proyecto depende de la disciplina de versiones, de pruebas convincentes sobre su adopción y de una frontera transparente con Code BGP: el mantenimiento comercial puede sostener el código abierto sin reemplazar la historia del proyecto de investigación.

Un cambio real de ruta mostró por qué los segundos son solo el principio

El informe anual de CAIDA de 2019 señala que ARTEMIS detectó en pocos segundos un secuestro real de ruta que afectó a un prefijo /30 de Internet2. El caso lleva las pruebas más allá de los anuncios sintéticos preparados por los investigadores: una ruta cambió realmente en una red participante y el sistema reconoció la desviación con rapidez suficiente para apoyar la investigación.

El informe no establece una distribución universal del tiempo de detección. Se trató de un prefijo concreto, dentro de un contexto de enrutamiento específico y observado mediante las fuentes disponibles para aquel despliegue. Otro incidente podría propagarse de forma diferente, durar menos o no llegar a los recolectores conectados. El informe tampoco demuestra por sí solo una intención maliciosa ni describe todas las consecuencias en el plano de datos. La conclusión correcta es más limitada: dentro del programa de despliegue de CAIDA, ARTEMIS detectó en segundos un incidente real documentado.

Los casos prácticos son valiosos cuando se conservan sus límites. Muestran cómo se comporta el programa ante un cambio real, cómo recibe el operador la alerta y qué pruebas quedan después. Para evaluar la madurez de producción serían más útiles nuevos registros de incidentes —incluidos falsos positivos, eventos omitidos y resultados de mitigación— que otra cifra llamativa sobre velocidad.

Una alerta BGP puede llegar en segundos y dejar sin respuesta las preguntas decisivas. Un recolector puede mostrar que un sistema autónomo desconocido anunció un prefijo o que apareció y empezó a propagarse una ruta más específica. Esto demuestra una discrepancia con el estado esperado del plano de control, pero no identifica necesariamente quién hizo el cambio, si fue un error, si el tráfico siguió la nueva ruta, si hubo usuarios afectados ni qué acción restaurará el servicio sin crear otro problema.

ARTEMIS fue diseñado para el intervalo entre la detección y la acción. Su nombre significa Automatic and Real-Time dEtection and MItigation System. No es un servicio central que vea toda Internet y repare a distancia redes ajenas. Cada organización lo despliega en infraestructura bajo su control, define qué estado de enrutamiento considera legítimo, conecta observaciones públicas y privadas y decide hasta dónde puede actuar el sistema cuando los datos se apartan de la política. Su promesa es velocidad con contexto; su límite es que tanto el contexto como las facultades siguen siendo locales.

ARTEMIS se parece más a un instrumento de la sala de control del operador que a una «policía de Internet». Puede ordenar las pruebas, reducir el tiempo dedicado a buscar entre actualizaciones de rutas y preparar una respuesta acordada previamente. No elimina la necesidad de criterio humano. Una decisión puede afectar al enrutamiento global, a las relaciones con proveedores ascendentes y al tráfico de clientes, por lo que la calidad de la respuesta depende tanto de las personas, la configuración y los permisos ensayados como del detector.

BGP comunica la alcanzabilidad antes de poder demostrar la autorización

Border Gateway Protocol permite que redes administradas de forma independiente intercambien información de alcanzabilidad y apliquen sus propias políticas. Un sistema autónomo anuncia que puede entregar tráfico a determinados prefijos IP, y las redes vecinas deciden si aceptan, prefieren y propagan esas rutas. Este modelo permitió escalar Internet sin un controlador único, pero el protocolo original no adjunta una prueba criptográfica a cada afirmación sobre el origen o el camino. Por ello, una exportación errónea, una configuración obsoleta o un anuncio deliberado pueden introducir una ruta que no debería existir.

El proceso de selección puede hacer atractivo un anuncio incorrecto. Si dos rutas cubren prefijos de igual longitud, cada red aplica su política y sus reglas de selección. Si una red atacante o equivocada anuncia un subprefijo más específico, la regla habitual de coincidencia con el prefijo más largo suele dirigir el tráfico hacia esa ruta más estrecha allí donde se acepte. No es una función especial de ataque, sino la regla normal para elegir el destino más preciso.

La palabra «secuestro» es útil como abreviatura, pero puede atribuir una intención que los mensajes de enrutamiento no revelan. Un origen no autorizado puede ser malicioso, accidental o consecuencia de un cambio comercial legítimo que todavía no figura en la política de supervisión. ARTEMIS resulta más útil cuando trata la alerta como una discrepancia entre el enrutamiento observado y el previsto, dejando la atribución y la evaluación del impacto al proceso general de respuesta.

Un evento de prefijo exacto compite con la ruta legítima de igual longitud. Su propagación depende de las políticas y de la selección de caminos en las redes que recibieron ambos anuncios. Algunas partes de Internet pueden preferir la ruta inesperada mientras otras siguen utilizando el origen legítimo, lo que puede producir alcanzabilidad parcial, diferencias regionales y una mezcla confusa de éxitos y fallos.

Un evento de subprefijo suele atraer más tráfico porque se da prioridad a la ruta más específica. Si una red anuncia normalmente un /20 y otro origen anuncia un /24 contenido en él, los enrutadores que acepten el /24 normalmente dirigirán allí el tráfico correspondiente. La desagregación también puede utilizarse como defensa, pero tiene límites estrictos: muchas redes filtran rutas IPv4 más largas que /24 y rutas IPv6 más largas que /48. Un operador que ya anuncie prefijos de esas longitudes puede no disponer de una ruta más específica aceptable globalmente.

ARTEMIS también contempla la ocupación de espacio de direcciones y determinadas infracciones de política, como escenarios relacionados con no-export. Un incidente no siempre consiste en que una red externa anuncie el prefijo de la víctima. Una ruta puede tener un origen permitido y propagarse mediante una relación inesperada. El sistema necesita suficiente contexto de política para distinguir estos casos sin fingir que los datos BGP revelan todos los acuerdos privados entre redes.

ARTEMIS incorpora al detector la intención de enrutamiento del operador

Los servicios externos de supervisión recopilan información desde muchas partes de Internet sin exigir que cada red despliegue una plataforma completa. Su desventaja es que pueden ver prefijos y caminos anunciados sin saber qué cambios de origen, proveedores de respaldo, técnicas de ingeniería de tráfico o anuncios de emergencia considera aceptables cada operador. Las reglas genéricas pueden omitir infracciones sutiles o generar alertas por cambios planificados.

ARTEMIS cambia el punto de observación. El detector lo ejecuta la organización cuyo espacio de direcciones está en riesgo y esa organización define la referencia. Los recolectores públicos aportan una visión externa amplia, pero sus observaciones se interpretan con conocimiento privado sobre los prefijos protegidos, los AS de origen permitidos, los vecinos aceptables y las relaciones de camino seleccionadas. Los flujos locales procedentes de los enrutadores añaden eventos que los recolectores públicos no ven.

Situar el detector dentro de la red protegida también traslada allí la responsabilidad. La organización debe decidir quién controla la política, cómo se revisan los cambios, qué alertas llegan al centro de operaciones de red, qué conclusiones puede extraer el equipo de seguridad y quién puede autorizar una nueva ruta. El programa hace visible esta responsabilidad, pero no obliga a la institución a ejercerla correctamente.

ARTEMIS pide al operador que defina prefijos protegidos, sistemas autónomos de origen legítimos, relaciones aceptables con vecinos y reglas de enrutamiento. Así puede preguntar si una ruta infringe la intención declarada de una red concreta, en vez de limitarse a decidir si parece extraña respecto de la historia mundial.

La ventaja solo es tan fiable como la declaración de política. Las redes cambian de proveedor, añaden ubicaciones anycast, trasladan AS de origen, crean caminos temporales de respaldo y emiten anuncios de emergencia. Una política exacta en enero puede estar obsoleta en junio. Si el cambio llega a los enrutadores pero no a ARTEMIS, puede producir una alerta grave falsa; si las reglas se amplían demasiado para suprimir ruido, una infracción real puede aparecer como permitida.

La configuración se convierte así en un acuerdo institucional. Los equipos de enrutamiento, seguridad y gestión de cambios deben acordar qué significa el archivo, quién puede modificarlo y con qué rapidez debe seguir a la red de producción. El contexto local no elimina los falsos positivos ni los falsos negativos, pero desplaza su principal origen a un ámbito que el operador puede gobernar.

Una regla de seguridad de enrutamiento merece la misma disciplina que el código capaz de afectar al tráfico de clientes: propietarios asignados, revisión, historial de versiones, pruebas y una justificación vinculada a un cambio aprobado. El operador debe poder determinar cuándo se añadió un prefijo, origen o vecino, quién lo autorizó y qué incidente o proyecto justificó la decisión.

Las pruebas deben incluir escenarios positivos y negativos. Una ruta legítima planificada debe pasar sin alerta; un origen no autorizado para un prefijo exacto debe recibir la clasificación prevista; un subprefijo debe activar la gravedad correcta, y una infracción de no-export no debe confundirse con un secuestro de origen. La reproducción histórica y los entornos de prueba permiten verificar tanto la detección como los procedimientos de mitigación.

Esta disciplina también limita la deriva organizativa. Cuando se marcha la persona que desplegó ARTEMIS, la política debe seguir siendo comprensible para quien la sustituya. Un detector cuya lógica depende de recuerdos no documentados no es infraestructura fiable, aunque su código sea abierto y sus fuentes tengan baja latencia.

FORTH y CAIDA convirtieron una pregunta de investigación en un proceso operativo

El proyecto surgió de la colaboración entre investigadores de Foundation for Research and Technology-Hellas, dentro del ecosistema de la Universidad de Creta, y CAIDA, en la Universidad de California en San Diego. FORTH aportó conocimientos de protección del enrutamiento e ingeniería de sistemas. CAIDA añadió infraestructura de medición de Internet, experiencia con BGPStream y relaciones que ayudaron a llevar el desarrollo a redes de investigación y educación.

La financiación siguió un modelo institucional mixto. En la historia del proyecto figuran programas europeos y estadounidenses, el Community Projects Fund de RIPE NCC, un proyecto de despliegue NSF EAGER, el Departamento de Seguridad Nacional de Estados Unidos y Comcast Innovation Fund. El apoyo de RIPE en 2017 ayudó a transformar el prototipo en una herramienta para operadores, y una subvención de 50.000 euros en 2019 financió la verificación del plano de datos con RIPE Atlas.

Estas ayudas muestran cómo una investigación de interés público se convirtió en software desplegable, pero no revelan el coste actual de mantener instalaciones de producción.

ARTEMIS no es una fundación independiente, un servicio de CAIDA ni un detector global propiedad de FORTH. Es software abierto bajo licencia BSD 3-Clause, con una genealogía de investigación y un mantenedor comercial actual. Su evolución se describe mejor como una sucesión de colaboraciones que como propiedad exclusiva de una organización.

El primer hito público fue una demostración en ACM SIGCOMM en 2016. El avance principal consistió en unir supervisión y mitigación en un solo ciclo. ARTEMIS planteó si un operador podía ver el evento con suficiente rapidez y disponer ya de una respuesta práctica preparada, evitando que el incidente pasara durante horas entre paneles, correos electrónicos y sesiones manuales en los enrutadores.

Una demostración no equivale a un despliegue industrial maduro. Prueba que los componentes pueden funcionar juntos en una configuración concreta. Sin embargo, el trabajo de 2016 estableció la dirección posterior: observaciones en directo, una representación interna del enrutamiento legítimo, clasificación y un anuncio preparado.

El proyecto respondió a testimonios de operadores según los cuales reaccionar a un secuestro podía llevar horas. La demora no procedía solo de los recolectores: los equipos debían confirmar la titularidad del prefijo, estudiar la propagación, comprobar si el cambio estaba previsto, encontrar contactos del proveedor y preparar un contraanuncio seguro. ARTEMIS reduce varios de esos pasos, aunque las relaciones humanas y comerciales siguen fuera del código.

El artículo de 2018 en IEEE/ACM Transactions on Networking formuló la afirmación más recordada: neutralizar un secuestro BGP en menos de un minuto. Los investigadores comunicaron detección en segundos y mitigación antes de un minuto bajo las condiciones probadas. El resultado mostró que una red víctima no tenía necesariamente que esperar a un servicio externo, una cadena de llamadas y un contraanuncio construido manualmente.

La frase resulta engañosa si se separa del experimento. La detección depende de que el evento llegue a un observador conectado, de la latencia de la fuente, de las reglas del detector y del estado del sistema. La mitigación depende de la longitud del prefijo, de las facultades del operador, de los filtros de los proveedores, de la propagación y del procedimiento de aprobación. La confirmación humana puede ser más segura y más lenta; la automatización inmediata, más rápida y más arriesgada.

La conclusión responsable es limitada: ARTEMIS demostró que un sistema estrechamente integrado en el lado del operador puede comprimir un proceso que antes solía durar mucho más. No demostró que todos los secuestros sean visibles, que todos los contraanuncios sean aceptados ni que todos los equipos deban permitir la desagregación autónoma.

Varias visiones incompletas forman una imagen útil del incidente

ARTEMIS puede utilizar varias fuentes públicas porque ningún recolector ve todas las rutas. RIPE RIS y RouteViews de la Universidad de Oregón reciben actualizaciones BGP de socios seleccionados en puntos distribuidos. CAIDA BGPStream ofrece un mecanismo común para acceder y normalizar datos procedentes de varias fuentes. Cada servicio amplía la visión del operador, pero solo refleja las redes conectadas a sus recolectores, la geografía de las sesiones y las propiedades temporales de los flujos.

Un evento puede propagarse en una región sin llegar a ningún recolector conectado al despliegue. Un anuncio muy breve puede retirarse antes de ser entregado por el flujo. Una ruta puede afectar a clientes mediante una relación privada ausente de los datos abiertos. Combinar recolectores reduce algunos puntos ciegos, pero sigue ofreciendo una muestra, no una copia omnisciente del plano de control global.

La pregunta operativa correcta no es si ARTEMIS «vio Internet», sino qué observadores vieron el anuncio, con qué rapidez y qué parte del evento pudo quedar fuera de la muestra. Esto obliga a conservar la procedencia de cada alerta y evita interpretar la ausencia en un flujo como prueba de que la ruta nunca existió.

RIPE NCC presentó el prototipo público de RIS Live en febrero de 2019 para transmitir mensajes BGP con mucha menos latencia que el procesamiento periódico de archivos. ARTEMIS fue un ejemplo de por qué hacía falta este tipo de flujo: un sistema no puede reaccionar en segundos si la observación principal llega muchos minutos después.

La menor latencia no elimina los límites de observación. RIS Live sigue reflejando los socios de RIPE Routing Information Service y las rutas que exportan. Un secuestro local, filtrado antes del recolector o oculto por otra relación puede no aparecer. También importa la fiabilidad: una interrupción del flujo o un cambio de formato pueden parecer silencio si la supervisión no distingue entre «no hay rutas sospechosas» y «no hay datos».

El estado de cada fuente forma parte del modelo de seguridad. El operador debe saber si cada monitor funciona a tiempo, está retrasado, desconectado o produce un volumen inusual. Un detector que muestre normalidad con datos de entrada degradados puede crear una ignorancia más peligrosa que un fallo explícito.

La supervisión en tiempo real muestra qué aparece ahora; las bases de información de enrutamiento y los archivos de actualizaciones aportan contexto. La historia de RIPE RIS y RouteViews permite observar orígenes y caminos anteriores al incidente, el inicio del cambio y su duración. BGPStream facilita el procesamiento común y permite reproducir eventos y probar reglas frente al comportamiento histórico.

La reproducción sirve para verificar reglas, reconstruir la secuencia que generó una alerta y formar al personal sin modificar rutas de producción. También revela anuncios recurrentes que parecen anómalos por separado, pero pertenecen a un esquema de respaldo establecido. El límite permanece: el archivo conserva la visión de los recolectores, no el evento completo.

Un despliegue maduro puede integrar esta reproducción en la gestión de cambios. Antes de introducir un nuevo origen, proveedor o criterio de exportación, el operador prueba la referencia actualizada sobre una historia representativa para comprobar que el enrutamiento normal no se convierta en una alerta permanente.

ARTEMIS también puede recibir actualizaciones locales mediante ExaBGP o sesiones privadas de BGP Monitoring Protocol. ExaBGP actúa como hablante BGP programable y transmite eventos a otras aplicaciones. BMP permite exportar información de enrutamiento a un sistema de supervisión sin incorporarlo a la decisión de reenvío. Estas fuentes muestran las relaciones y rutas de la propia red antes de que lleguen a un recolector público.

Los flujos locales mejoran la puntualidad y el contexto, pero introducen información sensible. BMP puede ser voluminoso y revelar relaciones internas. La integración de ExaBGP exige controles estrictos porque la misma interfaz puede observar y anunciar rutas. Las credenciales, el acceso de red, la validación de mensajes y la separación entre supervisión y mitigación se convierten en fronteras de seguridad.

Un buen despliegue asigna tareas distintas a los flujos públicos y privados. Los recolectores públicos muestran la propagación fuera del entorno inmediato; las fuentes locales muestran lo que vio la propia red. La discrepancia entre ambos puede ser una prueba de dónde se detuvo la propagación o dónde actuó una política.

La aplicación separa observación, detección y pruebas

La plataforma moderna es una aplicación de microservicios con varios contenedores, no un único script que lee un flujo. Los servicios de supervisión conectan fuentes públicas y privadas, normalizan información BGP y publican eventos. Los servicios de detección aplican las reglas del operador. Alrededor del núcleo se encuentran el almacenamiento, la API, la interfaz web, las notificaciones y la supervisión operativa.

La modularidad también multiplica las dependencias. Un monitor puede seguir activo mientras el detector está detenido; la mensajería puede recibir eventos cuando la base de datos no está disponible; la interfaz puede mostrar un incidente antiguo mientras el flujo en directo está roto. Las comprobaciones deben cubrir el camino completo desde la fuente hasta la alerta, no limitarse a indicar que los contenedores están ejecutándose.

Docker Compose reduce la barrera para un despliegue controlado y Kubernetes se adapta a organizaciones que ya operan plataformas de contenedores. Ninguna opción convierte ARTEMIS en un servicio global gestionado. La red sigue siendo responsable de capacidad, actualizaciones, secretos, almacenamiento, copias de seguridad y acceso de emergencia.

La mensajería desacopla los servicios y puede absorber ráfagas de actualizaciones, pero plantea problemas de orden, duplicados y contrapresión. Un incidente puede generar miles de actualizaciones, retiradas y cambios de camino. El sistema debe conservar suficiente secuencia y procedencia para reconstruir el desarrollo del evento.

El almacenamiento persistente conserva actualizaciones, alertas, configuración y decisiones. La arquitectura ha utilizado PostgreSQL, almacenamiento de estilo Timescale y el ecosistema de API de Hasura. Estas herramientas facilitan consultas e integraciones, pero crean un archivo sensible de pruebas operativas que necesita políticas de conservación, control de acceso y copias de seguridad fiables.

La trazabilidad no equivale a certeza. Un registro completo puede demostrar cómo llegó ARTEMIS a una alerta, pero no que vio todas las rutas relevantes ni que la política era correcta. La base debe conservar la fuente y el grado de confianza, no solo la etiqueta final.

La interfaz web presenta incidentes, estado del sistema y observaciones para centros de red o seguridad. Las notificaciones envían alertas por correo electrónico, canales móviles o integraciones propias, mientras Grafana muestra la salud del servicio y las tendencias. Estas funciones convierten un mecanismo de investigación en un producto operativo.

La interfaz también puede generar una confianza falsa. Una tarjeta roja es una clasificación basada en reglas y observaciones, no una prueba independiente de intención maliciosa. Los mapas pueden parecer completos aunque solo representen recolectores seleccionados. Una política desactualizada genera ruido y fatiga de alertas.

La buena práctica conecta el panel con la verificación. El personal debe poder abrir las actualizaciones originales, comparar flujos públicos y locales, revisar RPKI, ejecutar pruebas del plano de datos y documentar por qué el incidente se escaló, ignoró o cerró.

Un patrón de rutas no demuestra ni el motivo ni las consecuencias

La investigación de ARTEMIS desarrolló una clasificación basada en relaciones de prefijos, manipulaciones del camino AS, política y posibles efectos en el plano de datos. La implementación admite un subconjunto de patrones observables en el plano de control, como orígenes incorrectos para prefijos exactos o subprefijos, ocupación de direcciones y determinadas infracciones de exportación.

Las categorías deben mantenerse vinculadas a lo que muestran realmente los datos. Un camino que comienza por un vecino inesperado puede indicar falsificación, fuga de rutas o un cambio autorizado aún no reflejado en la política. Un origen no autorizado puede ser un error y no un ataque. Las actualizaciones BGP por sí solas tampoco distinguen entre interceptar tráfico, anularlo o sustituir un servicio.

En la fase de alerta, expresiones como «posible secuestro» o «infracción de política» suelen ser más precisas que «ataque». Las formulaciones más fuertes deberían esperar a la verificación de la titularidad, los contactos con el operador y las pruebas del plano de datos.

Los mensajes BGP describen afirmaciones de alcanzabilidad y caminos, no todos los paquetes que siguieron una ruta. Tras un anuncio sospechoso, el tráfico puede caer en un agujero negro, ser interceptado y reenviado, recibir una respuesta de un servicio sustituido o no cambiar en absoluto. Diferentes partes de Internet pueden experimentar consecuencias distintas.

ARTEMIS puede mostrar que una ruta infringió la política y apareció en determinados puntos de observación. No deduce el motivo a partir del camino AS ni garantiza que traceroute represente el trayecto del tráfico de aplicación. El cifrado, DNS, las cachés, anycast y la conmutación de aplicaciones también modifican la experiencia del usuario.

Una respuesta útil combina registros. BGP establece el anuncio y su propagación; las pruebas del plano de datos comprueban alcanzabilidad y caminos desde ubicaciones elegidas; la telemetría del servicio muestra errores, latencia e impacto; y los contactos con proveedores aclaran si el anuncio estaba autorizado o fue accidental.

La ayuda del RIPE Community Projects Fund de 2019 apoyó la incorporación de mediciones traceroute de RIPE Atlas para evaluar el efecto de los eventos detectados. La iniciativa reconocía que una ruta puede parecer peligrosa en BGP y afectar poco a los usuarios, mientras una propagación reducida puede perjudicar a un grupo valioso de clientes.

RIPE Atlas dispone de sondas distribuidas, pero su ubicación es desigual. Traceroute se ve afectado por filtrado, balanceo, túneles y enrutamiento asimétrico. El camino desde una sonda al objetivo no tiene por qué coincidir con el recorrido inverso del tráfico de clientes, y una medición fallida puede reflejar tanto una interrupción como una limitación de la prueba.

La ventaja práctica es una mejor priorización, no una certeza completa. Si varios recolectores muestran un subprefijo no autorizado y sondas de distintas regiones pierden alcanzabilidad o cambian hacia un origen inesperado, hay más motivos para escalar. Si solo lo ve un recolector y las pruebas permanecen estables, el equipo puede investigar antes de modificar anuncios globales.

La desagregación solo recupera tráfico cuando el sistema de enrutamiento lo permite

La respuesta más conocida de ARTEMIS es la desagregación. Una víctima que anuncia un prefijo amplio puede emitir rutas más específicas para que la selección por prefijo más largo devuelva tráfico a la red legítima. El método utiliza el comportamiento normal de BGP, puede propagarse rápidamente y permite actuar sin cooperación inicial del origen inesperado.

Sus límites son estrictos. Muchas redes filtran rutas IPv4 más largas que /24 e IPv6 más largas que /48. Una víctima que ya anuncia un /24 o /48 puede no disponer de una ruta más específica aceptada ampliamente. Los proveedores también restringen los anuncios de sus clientes, y los objetos de ruta, filtros de prefijos y datos RPKI deben permitir el estado de emergencia. La propagación tampoco es inmediata ni uniforme.

El operador debe conocer de antemano qué prefijos puede desagregar, qué proveedores los aceptarán, si los filtros y las Route Origin Authorisations cubren el estado de emergencia y cómo se retirarán las rutas después. ARTEMIS puede activar un procedimiento externo, pero su éxito depende de acuerdos ajenos a la aplicación.

Los materiales del proyecto hablan de mitigación automática, mientras las descripciones operativas incluyen confirmación manual. Ambas cosas son compatibles porque cada despliegue elige un grado distinto de autonomía. ARTEMIS admite mitigación automatizada o aprobada por el operador mediante flujos configurables.

El riesgo es asimétrico. Retrasar la respuesta puede prolongar la interrupción; una automatización errónea puede anunciar rutas innecesarias, infringir políticas del proveedor, revelar supuestos internos o causar inestabilidad. Si el procedimiento externo dispone de amplios permisos sobre los enrutadores, comprometer ARTEMIS se convierte en un ataque contra el enrutamiento.

Una automatización más segura trabaja por etapas: enriquece la alerta, comprueba varios flujos, RPKI y el plano de datos, y prepara un cambio preciso. Una persona aprueba las acciones de alto impacto, mientras los casos de menor riesgo pueden seguir políticas automáticas. Los límites de frecuencia, permisos estrechos, simulación, registro y reversión probada son más importantes que la etiqueta «automático».

RPKI refuerza solo un eslabón de la cadena de pruebas

Resource Public Key Infrastructure permite que los titulares de direcciones creen Route Origin Authorisations que especifican qué sistemas autónomos pueden anunciar determinados prefijos y longitudes máximas. Route Origin Validation clasifica una ruta como válida, inválida o no encontrada. Esto añade una prueba criptográfica a la autorización de origen y permite que otras redes rechacen o reduzcan la prioridad de un origen no autorizado.

ARTEMIS opera en otra capa. Puede utilizar el estado de RPKI como prueba, pero también compara rutas con reglas privadas, registra eventos, combina flujos públicos y locales y vincula la detección con la respuesta. RPKI no valida todo el camino AS y su aplicación no es universal. Una ruta válida puede infringir una relación esperada, y un cambio legítimo puede ser inválido si la ROA no se actualizó.

Los mecanismos se complementan. RPKI reduce los orígenes no autorizados aceptados por Internet; ARTEMIS muestra observaciones reales a la víctima, detecta patrones que van más allá del origen y organiza la respuesta. Futuros mecanismos como ASPA pueden reforzar las pruebas sobre relaciones, pero no eliminan la necesidad de observar los anuncios reales y sus efectos.

Los pilotos sacaron ARTEMIS del laboratorio, pero no demostraron la escala del mercado

CAIDA informó de despliegues experimentales apoyados por NSF con Internet2, Great Plains Network y Merit durante 2018 y 2019. Estos pilotos importan porque las redes académicas tienen prefijos, proveedores, procesos de cambio y compromisos de servicio reales. Permitieron comprobar si el programa encajaba con la supervisión existente y si las reglas reflejaban la intención de enrutamiento.

Las pruebas son convincentes pero limitadas. Un piloto confirma instalación, comentarios de ingeniería y cierto uso operativo; no demuestra cobertura continua, actualidad de la versión ni eficacia uniforme en todos los tipos de red. Los testimonios asociados con AMS-IX, Internet2 y ESnet y los logotipos publicados indican pruebas o uso, pero no permiten clasificar a cada organización como cliente de pago actual ni calcular una cuota mundial.

La distinción importa porque los despliegues de protección del enrutamiento suelen ser invisibles. Un operador puede usar una bifurcación interna, limitarse a la supervisión o detenerse tras una prueba. La ausencia de un registro completo no vuelve insignificante al proyecto, pero impide medir con precisión su adopción.

El control del operador implica integración y protección de la cadena de suministro

ARTEMIS se distribuye bajo licencia BSD 3-Clause. El operador puede examinar el código, ejecutarlo en infraestructura controlada, modificar integraciones y conservar la política sensible dentro de la red. La licencia también permite uso comercial y bifurcaciones, por lo que Code BGP y otros participantes pueden crear servicios sobre la base abierta.

El control exige trabajo. La plataforma reúne contenedores, mensajería, bases de datos, API, una aplicación web, notificaciones y conexiones a flujos. Cada componente requiere actualizaciones, credenciales, segmentación, copias de seguridad y supervisión. Como almacena política sensible y puede tener facultades para modificar anuncios, la superficie de ataque es mayor que la del algoritmo original.

La licencia abierta ofrece una vía para abandonar a un mantenedor, pero no crea soporte automáticamente. Alguien debe evaluar actualizaciones, dependencias y cambios en las fuentes o interfaces. Para una red pequeña, una herramienta de alertas más sencilla o un servicio gestionado puede ser más práctico, aunque ofrezca menos control local.

El servicio debe seguir funcionando durante la inestabilidad que motivó su despliegue. Los flujos, la mensajería, la base de datos, la API, la interfaz, las notificaciones y la autenticación forman una cadena. La redundancia de contenedores solo ayuda si el estado, el almacenamiento y las dependencias externas también toleran fallos.

La arquitectura debe definir modos de degradación. Si desaparece un flujo público, debe indicar que la cobertura se ha reducido. Si la base de datos no está disponible, quizá sea necesario almacenar eventos localmente o detener la mitigación porque no pueden registrarse pruebas de auditoría. El acceso de emergencia debe sobrevivir a una interrupción del proveedor de identidad sin convertirse en una cuenta permanente sin control.

La plataforma también necesita un presupuesto de rendimiento. Una ráfaga legítima durante un gran cambio puede cargar los monitores y el almacenamiento más que un secuestro. Las colas no deben convertir silenciosamente un flujo casi en tiempo real en un informe tardío. Las pruebas de capacidad, la conservación de datos y la contrapresión limitan la velocidad que el sistema puede prometer honestamente.

Cada componente y dependencia puede convertirse en una vulnerabilidad o punto de fallo. Un error de interfaz puede revelar política; una imagen comprometida puede alterar alertas; un token de API demasiado amplio puede exponer incidentes; y las credenciales de mitigación pueden permitir cambios de rutas.

El código abierto permite revisar componentes, fijar versiones y construir imágenes propias, pero no garantiza auditorías completas ni correcciones a tiempo. Los equipos necesitan inventarios, procesos de reconstrucción, separación entre supervisión de lectura y mitigación con escritura y una forma de aplicar actualizaciones sin perder el historial de incidentes.

Esto cambia los criterios de mantenimiento. Una nueva función de detección es más visible que una actualización de base de datos o una corrección de autenticación, aunque estas últimas puedan ser más importantes. Los boletines de seguridad, las compilaciones reproducibles, las dependencias actualizadas y una rama de versiones mantenida son señales de madurez.

Las versiones y Code BGP definen la prueba actual de mantenimiento

La última versión formal señalada en el material de investigación es la 2.3.0 Cadmus, del 24 de noviembre de 2022. En la fecha de corte del 5 de agosto de 2026, la demostración en directo mostraba una compilación posterior basada en un commit y el sitio seguía activo. Esto confirma actividad posterior, pero plantea una pregunta legítima: qué versión está probada, mantenida y preparada para actualizarse.

Los commits y una demostración operativa muestran desarrollo. Una versión semántica aporta otra clase de confianza: una base identificable, notas, dependencias previstas y un punto frente al cual realizar pruebas. Un proyecto puede seguir activo con un proceso de versiones retrasado, y una demostración puede utilizar código que una red de producción no debería aceptar sin validación propia.

En infraestructura de protección del enrutamiento, la disciplina de versiones forma parte del modelo de seguridad. Los operadores deben saber qué ramas reciben correcciones, cómo se realizan las migraciones y si quedan dependencias vulnerables. Una política pública de soporte y seguridad reduciría más incertidumbre que un sitio activo por sí solo.

El sitio identifica a Code BGP como mantenedor actual de ARTEMIS y describe la empresa como una startup surgida del proyecto. La comercialización puede resolver un problema real: estas herramientas necesitan personas que mantengan integraciones, respondan a vulnerabilidades, ayuden con despliegues y conviertan funciones de investigación en operaciones sostenibles.

Code BGP es, no obstante, una empresa comercial independiente con un contexto más amplio de productos y clientes. No es otro nombre para FORTH, CAIDA ni los despliegues abiertos. Los materiales públicos no revelan ingresos, valoración, una lista de clientes ni la frontera exacta entre funciones públicas y comerciales. Es un límite de la evidencia disponible.

La relación crea incentivos que pueden coincidir o divergir. El proyecto abierto se beneficia cuando el personal comercial aporta código y documentación; la empresa se beneficia cuando el proyecto genera confianza y una base para servicios de pago. La prueba a largo plazo será si las versiones, las correcciones y las decisiones de hoja de ruta siguen siendo visibles para operadores que no sean clientes.

La licencia permisiva garantiza la posibilidad jurídica de copiar, modificar y comercializar el código, pero no que otro equipo entienda la arquitectura o pueda asumir el mantenimiento. La continuidad depende de documentación, pruebas, historial de incidencias, conocimiento de dependencias y una vía para nuevos colaboradores.

El mantenimiento de Code BGP puede reforzar esa continuidad al conservar ingenieros experimentados cerca de la plataforma. También puede concentrar el conocimiento práctico dentro de una organización comercial aunque el repositorio siga siendo público. Las notas de versiones, las discusiones abiertas y la respuesta a la comunidad permiten evaluar la diferencia.

El problema no es la existencia de valor comercial. Un modelo saludable de núcleo abierto puede vincular el soporte de pago con el mantenimiento público. El riesgo aparece si el proyecto abierto queda como demostración histórica y la vía operativa migra a componentes privados sin documentar. La portabilidad debe comprobarse preguntando si un operador independiente puede instalar, actualizar, verificar y recuperar el sistema con el material público disponible.

ARTEMIS ocupa una posición intermedia y exigente en la protección del enrutamiento

El campo incluye recolectores públicos, sistemas de investigación, herramientas abiertas de alerta, validadores RPKI y plataformas comerciales. RIPE RIS, RouteViews y BGPStream proporcionan datos, no un proceso de incidentes adaptado a un operador. BGPalerter ofrece otro modelo abierto; MANRS establece normas operativas, pero no detecta eventos en tiempo real. Los servicios comerciales pueden ofrecer observación amplia y apoyo analítico, aunque a menudo carecen de contexto privado sin integración con el cliente.

La posición distintiva de ARTEMIS combina control del operador, una referencia explícita, varios flujos públicos y locales, código abierto y mitigación opcional. También exige especialistas en enrutamiento, política mantenida y capacidad para operar una plataforma compleja. Probablemente encaje mejor en organizaciones donde la protección del enrutamiento es una competencia interna.

La comparación no puede reducirse a funciones. Cada modelo distribuye de forma distinta la confianza y el trabajo. Un servicio gestionado centraliza conocimientos y observación; un sistema local mantiene política y acción cerca de la red. La cuestión es qué parte ve lo suficiente, actúa con seguridad y rinde cuentas cuando las pruebas son incompletas.

ARTEMIS Lite apareció en materiales de la comunidad RIPE en 2023 como un enfoque relacionado y más ligero. Su existencia muestra que la plataforma completa puede resultar pesada para equipos pequeños. Un conjunto con múltiples contenedores, almacenamiento persistente, varios flujos y mitigación propia puede ser apropiado para un gran operador y excesivo para una red que primero necesita visibilidad clara y alertas fiables.

El sistema ligero no debe considerarse equivalente solo por compartir nombre y finalidad. Los materiales lo describen como una variante de funcionalidad reducida, y las afirmaciones de presentaciones requieren confirmación independiente. El intercambio es entre menor coste operativo y posible pérdida de contexto, integraciones, historial o mecanismos de respuesta.

La adopción depende de la maquinaria institucional necesaria. Un proyecto puede ser técnicamente abierto y seguir fuera del alcance de operadores sin especialistas en contenedores, bases de datos y seguridad de enrutamiento. El empaquetado, los valores predeterminados y un camino gradual desde la supervisión hasta la detección y mitigación pueden decidir si la arquitectura se extiende más allá de su entorno de investigación.

El verdadero producto es un ciclo de retroalimentación gobernado

ARTEMIS no vuelve confiable a BGP con una sola acción. Construye un ciclo alrededor de un protocolo sin autorización completa. El operador describe el enrutamiento deseado; los flujos públicos y locales muestran una parte de la realidad; el detector identifica la discrepancia; el almacenamiento y las interfaces ordenan las pruebas; y las personas o una automatización autorizada eligen una respuesta. Después, los flujos muestran si cambió la propagación.

Este ciclo es la aportación más duradera del proyecto. Reconoce que proteger el enrutamiento no consiste en un certificado aislado ni en una alerta distante, sino en una práctica donde la política debe ser explícita, las observaciones deben conservar su procedencia y la autoridad de respuesta debe prepararse antes de la emergencia. El valor radica en reducir la incertidumbre con suficiente rapidez para actuar, no en fingir que ha desaparecido.

Los límites son igualmente importantes. Los recolectores solo ven parte del mundo; la referencia puede quedar obsoleta; el plano de control no demuestra motivos ni todos los efectos sobre el tráfico; una mitigación técnicamente válida puede ser filtrada o causar daños; y el código abierto necesita mantenimiento continuo. ARTEMIS es más fuerte cuando estos límites se integran en el proceso.

Una anomalía puede llegar al centro de operaciones de red, al centro de seguridad o a ambos. El equipo de enrutamiento entiende los prefijos, las políticas de proveedores y el riesgo de modificar anuncios. El equipo de seguridad puede correlacionar identidades, telemetría de servicio y actividad potencialmente maliciosa. La alerta debe aportar suficientes pruebas para que ambos trabajen sobre el mismo evento.

La transferencia del incidente debe separar observación, política e impacto: qué flujos vieron la ruta, qué regla se infringió y qué efecto mostraron las pruebas, o si todavía no se ha establecido. También debe registrar los contactos con proveedores y las respuestas pendientes. Esto evita tanto descartar una amenaza como llamar ataque a un anuncio antes de comprobar los hechos.

Un lenguaje común mejora la revisión posterior. El caso puede cerrarse como cambio planificado no reflejado en la política, fuga accidental, posible secuestro, evento malicioso confirmado o anomalía no resuelta. Los resultados deben volver a las reglas, los procedimientos y los acuerdos con proveedores. Sin este ciclo, el detector corre el riesgo de convertirse en una máquina de generar tickets.

La alerta más rápida no siempre es la más útil. Actuar ante la primera actualización inesperada puede ser prematuro; esperar a todos los recolectores y pruebas destruye la ventaja de una respuesta temprana. La medida relevante es cuánto tarda el sistema en reunir pruebas suficientemente fiables para que un operador autorizado adopte una decisión defendible.

Esta medida puede dividirse: cuándo llegó la primera observación, cuántos flujos independientes la confirmaron, si la política estaba actualizada, qué aportaron RPKI o BMP, cuánto duraron las pruebas del servicio, cuándo recibió la alerta la persona responsable, cuándo se aprobó la respuesta, si la mitigación se propagó como se esperaba y si se retiró correctamente.

La métrica de la decisión defendible también evita una optimización peligrosa. No debe premiarse al sistema por actuar antes si utiliza menos pruebas o crea cambios innecesarios. El mejor despliegue reduce al mismo tiempo la incertidumbre y el tiempo de respuesta, conservando un registro verificable.

Fuentes

  • Sitio del proyecto ARTEMIS
  • Arquitectura de código abierto de ARTEMIS en RIPE Labs
  • Repositorio de código y documentación de ARTEMIS
  • «ARTEMIS: Neutralizing BGP Hijacking within a Minute»
  • Explicación operativa de ARTEMIS en RIPE Labs
  • Artículo de demostración de ARTEMIS en ACM SIGCOMM 2016
  • Versiones de ARTEMIS
  • Informe anual de CAIDA de 2019
  • Flujo de mensajes BGP RIPE RIS Live
  • RouteViews de la Universidad de Oregón
  • CAIDA BGPStream
  • Repositorio ExaBGP
  • Route Origin Validation, RFC 6811
  • Beneficiarios del RIPE Community Projects Fund de 2019
  • Code BGP
  • Despliegue experimental de ARTEMIS en CAIDA
  • Demostración en directo de ARTEMIS
  • BGP Monitoring Protocol, RFC 7854
  • RIPE Atlas