Resumen

  • Los datos públicos vinculan a DFINFRA con AS210860 en distintas capas de registro, autorización y visibilidad de enrutamiento, pero no establecen por sí solos propiedad, operación efectiva, servicio a clientes ni responsabilidad ante fallos.
  • La prueba decisiva sería una cadena temporal que uniera autoridad identificable, cambio observable de rutas, impacto independiente sobre la alcanzabilidad y una acción atribuible de recuperación o desvío.

La asociación administrativa no es todavía control

El punto de partida es verificable. La base de datos de RIPE mantiene objetos asociados con AS210860 y permite consultar su información de registro mediante RIPE RDAP y el objeto aut-num de RIPE. Esos registros son evidencia de cómo se describe y administra un recurso dentro del sistema de numeración de Internet. No son, por sí mismos, un contrato de operación, un inventario de equipos ni una prueba de que una entidad concreta controle cada decisión de encaminamiento.

Esta distinción importa porque “estar asociado” puede significar varias cosas: ser titular registral, contacto administrativo, mantenedor de objetos, autorizado para anunciar determinados prefijos o parte de una cadena de delegación. La relación puede ser significativa para investigar autoridad técnica, pero no debe convertirse automáticamente en una afirmación de propiedad corporativa, presencia física, capacidad de tránsito o valor comercial.

La investigación anterior sobre DFINFRA ya había situado el problema en la visibilidad del recurso y en la continuidad potencial de AS210860. El avance de este análisis es tratar la evidencia como una cadena, no como una colección de señales. La pregunta no es únicamente si el nombre aparece junto al ASN. Es qué capacidad concreta puede inferirse de cada registro y qué enlace falta antes de hablar de control operativo.

Qué añade el enrutamiento observado

Las fuentes de RIPEstat permiten examinar el estado de enrutamiento, los prefijos anunciados, los vecinos y la historia temporal de un ASN. En este paquete se consultan el estado de routing de RIPEstat, los prefijos anunciados, los vecinos del ASN, la historia de visibilidad y los datos de primera y última observación en RIS ( https://stat.ripe.net/data/routing-history/data.json?resource=AS210860 ). También se revisan las búsquedas de rutas IPv4 e IPv6 en la base de datos de RIPE y en su búsqueda de route6.

Estas fuentes pueden demostrar que ciertos anuncios fueron visibles desde colectores o momentos determinados. Pueden ayudar a identificar prefijos, cambios de camino, vecinos y persistencia de anuncios. También pueden mostrar que la visibilidad de un prefijo cambió o desapareció. Pero la visibilidad BGP no equivale a disponibilidad de un servicio final.

Un anuncio puede permanecer visible mientras una aplicación está caída; un anuncio puede desaparecer por una decisión de ingeniería sin que exista una interrupción comercial; y un camino observado desde un colector no revela necesariamente quién tomó la decisión ni quién tenía capacidad de revertirla.

La diferencia entre anuncio y control es especialmente importante en sistemas con tránsito, mitigación, proveedores ascendentes o acuerdos de interconexión. Un ASN puede aparecer en un camino sin ser el operador físico de todos los enlaces que lo conectan. Del mismo modo, un objeto de ruta puede expresar una autorización o intención que no coincide con el estado dinámico de la red en cada instante.

La autorización RPKI no identifica al operador de servicio

La consulta del repositorio público de RPKI de Cloudflare aporta otra capa. Una autorización RPKI puede indicar qué ASN está autorizado a originar un prefijo concreto y con qué longitud máxima. Es una señal importante para la seguridad del enrutamiento, porque permite comparar anuncios con autorizaciones criptográficas publicadas.

Pero RPKI responde a una pregunta estrecha: qué origen está autorizado para un prefijo bajo una determinada ROA. No responde quién instala los routers, quién compra capacidad de tránsito, quién atiende a clientes ni quién decide cómo recuperarse de un fallo. Una ROA válida puede coexistir con múltiples modelos operativos, y una ROA ausente o cambiante no prueba por sí sola una toma de control, una interrupción o una disputa comercial.

La inferencia correcta es acumulativa. Si una autorización, un objeto de ruta y un anuncio observado coinciden, aumenta la confianza en la coherencia técnica de esa porción del sistema. No se obtiene automáticamente una prueba de que DFINFRA controle toda la cadena de operación ni de que AS210860 constituya un servicio utilizado por terceros.

Topología, presencia y dependencia

Las bases de datos de interconexión ofrecen señales diferentes. PeeringDB puede registrar información declarada sobre redes, puntos de presencia, políticas de peering y relaciones de interconexión. BGP.Tools, Hurricane Electric, NLNOG IRR Explorer y Potaroo permiten contrastar anuncios, rutas, vecinos o historial desde perspectivas distintas.

La concordancia entre varias fuentes reduce el riesgo de interpretar una observación aislada. Sin embargo, estas bases tampoco deben leerse como un inventario auditado de capacidad. Algunas contienen información declarada por participantes; otras derivan sus resultados de observaciones de routing; otras agregan datos con diferentes frecuencias, filtros y ventanas temporales. La presencia de una red en una base puede probar que existe una representación pública o una observación técnica, pero no necesariamente que un servicio esté disponible, contratado o respaldado por una organización concreta.

La dependencia operacional requiere una prueba más exigente. Para afirmar que un cliente, una plataforma o una región depende de AS210860 habría que identificar el recurso dependiente, establecer que el ASN es indispensable o material para su funcionamiento y observar qué ocurre cuando cambia la ruta, el origen o la alcanzabilidad. La mera proximidad topológica no cuantifica tráfico, ingresos, usuarios afectados ni tiempo de recuperación.

Las sondas miden alcanzabilidad, no responsabilidad

Las consultas de RIPE Atlas para IPv4 y IPv6 pueden contribuir a un test independiente de alcanzabilidad. Una sonda que llega a un destino desde una ubicación concreta aporta evidencia sobre ese camino, protocolo, momento y configuración. Una colección de sondas puede revelar diferencias geográficas o temporales que no aparecen en un único colector BGP.

Aun así, una medición negativa no identifica automáticamente la causa. Puede deberse a filtrado, fallo del destino, una política de acceso, una ruta asimétrica o una condición local de la sonda. Una medición positiva tampoco demuestra que la organización asociada al registro opere el servicio final. Para construir una atribución más fuerte habría que combinar la medición con el prefijo exacto, la evolución del anuncio, la ruta de retorno, el momento del cambio y una acción atribuible.

La ausencia de una secuencia de este tipo es un resultado, no un vacío que deba rellenarse con lenguaje más contundente. En la ronda actual no queda demostrada una cadena completa de retirada de rutas, pérdida independiente de alcanzabilidad, recuperación, failover y efecto sobre un servicio identificable.

Qué mostraría continuidad operativa

Una prueba de continuidad para AS210860 debería tener al menos cuatro capas sincronizadas.

Primero, una capa de autoridad: un registro, objeto mantenido, autorización o declaración verificable que identifique quién podía modificar la configuración relevante. Segundo, una capa de estado: observaciones fechadas de anuncios, prefijos, caminos o cambios de vecinos. Tercero, una capa de impacto: mediciones independientes de alcanzabilidad, latencia, pérdida o disponibilidad hacia un recurso definido. Cuarto, una capa de respuesta: evidencia de una acción de recuperación, cambio de tránsito, reanuncio, desvío o comunicación atribuible a un operador identificado.

Sin la primera capa, un cambio de ruta puede observarse pero no atribuirse. Sin la segunda, una afirmación sobre continuidad carece de línea temporal. Sin la tercera, no se sabe si la modificación afectó a un servicio. Sin la cuarta, no se puede distinguir una coincidencia técnica de una respuesta operativa.

La cadena también necesita una ventana temporal clara. No basta con comparar capturas tomadas en días distintos y describirlas como un incidente. Habría que establecer cuándo comenzó el cambio, cuánto duró, desde qué puntos fue visible, qué prefijos o destinos afectó y qué evidencia muestra su recuperación. La precisión temporal es lo que separa una observación de una narrativa causal.

Lo que los datos permiten decir ahora

El paquete público permite afirmar que AS210860 puede investigarse mediante registros administrativos, objetos de enrutamiento, autorizaciones RPKI, anuncios observados, relaciones de vecinos, mediciones y bases de interconexión. También permite afirmar que esas capas no son equivalentes y que su combinación actual no demuestra por sí sola propiedad, control integral, despliegue físico, uso por clientes, ingresos, disponibilidad de servicio ni consecuencias comerciales.

No se ha establecido en esta ronda una interrupción concreta. Tampoco se ha demostrado una retirada y reanuncio atribuible, un camino de failover, una duración de recuperación, una pérdida de servicio o una organización que haya declarado que dependía de AS210860. Por eso el resultado principal no es una acusación ni una absolución operacional. Es un límite de evidencia: la relación registral y la visibilidad técnica justifican investigación adicional, pero todavía no cierran el circuito de control.

Ese límite también tiene valor práctico. Evita tratar un ASN como si fuera una empresa, un registro como si fuera un contrato de servicio o una tabla de routing como si fuera una medición de ingresos. Para un comprador, regulador, investigador de incidentes o responsable de resiliencia, la pregunta siguiente debe ser específica: ¿qué configuración podía cambiar quién, qué recurso habría quedado afectado, qué medición independiente lo demostraría y qué registro de operación vincularía la recuperación con una entidad concreta?

Qué debe observarse a continuación

Un seguimiento útil debería conservar capturas fechadas de los objetos de RIPE y de las ROA, recoger series de anuncios IPv4 e IPv6 desde varios colectores, repetir mediciones de RIPE Atlas hacia destinos definidos y comparar cambios de camino con una fuente independiente de disponibilidad. También debería documentar cualquier declaración del mantenedor, del proveedor de tránsito o de una organización afectada.

La observación debe distinguir entre cambio administrativo, cambio de autorización, cambio de anuncio y cambio de servicio. Son eventos relacionados, pero no intercambiables. Una modificación registral puede preceder o seguir a una operación técnica; una alteración de routing puede ser deliberada y no causar indisponibilidad; una caída de servicio puede producirse sin que el ASN desaparezca de las tablas globales.

Hasta que esas capas estén unidas en una cronología atribuible, la formulación más rigurosa sigue siendo limitada: los registros y las rutas muestran una relación técnica investigable; no demuestran por sí solos quién controla la operación ni qué consecuencias tendría su interrupción.

Fuentes

Directorio de DFINFRA