Resumen

  • La relación pública entre DFINFRA y AS210860 identifica un punto de partida registral, pero no demuestra por sí sola propiedad legal, operación física, capacidad para modificar rutas ni dependencia de clientes.
  • Para convertir esa señal en una conclusión defendible hay que conectar, con marcas temporales compatibles, identidad registral, derechos de mantenimiento, objetos IRR, anuncios BGP, autorización RPKI y evidencia independiente de servicio o actividad empresarial.

La primera diferencia que debe preservar cualquier investigación sobre AS210860 es la diferencia entre aparecer en un registro y poder cambiar el estado de una red. El registro puede indicar qué nombre, organización, contacto o mantenedor aparece asociado con un número de sistema autónomo. No responde necesariamente quién administra los routers, quién contrata el tránsito, quién decide qué prefijos anunciar o quién recibe el valor económico de la conectividad.

La evidencia pública reunida para esta investigación cubre precisamente esas capas, pero no aporta sus valores actuales. El paquete de investigación identificó el objeto aut-num de AS210860 en la base de datos de RIPE, junto con sus vistas WHOIS y RDAP (objeto aut-num de RIPE; WHOIS de RIPEstat; registro RDAP). La documentación de RIPE Database describe el alcance y el funcionamiento de esos registros (documentación de RIPE Database). Sin embargo, las respuestas vivas no pudieron recuperarse durante esta revisión. Por tanto, no es posible afirmar aquí cuál es el as-name vigente, qué identificador de organización aparece, qué mantenedores figuran, cuándo se modificó el objeto o qué contactos están asociados.

Esa limitación no vuelve irrelevantes los registros. Define qué pueden probar cuando se obtengan y qué no debe inferirse antes. Un registro de RIPE puede establecer una asociación administrativa contemporánea. Puede mostrar que una identidad aparece en un objeto protegido, que existen referencias a una organización o que determinados mantenedores están autorizados a actualizar atributos. Pero la autorización para modificar una base de datos no equivale automáticamente a la propiedad beneficiaria del recurso, al control cotidiano de una red o a la existencia de un contrato comercial.

La identidad registral es el comienzo de la prueba, no su resultado

El siguiente nivel son los objetos de enrutamiento. Las búsquedas inversas de RIPE para objetos route y route6 cuyo origen declarado es AS210860 podrían mostrar los prefijos, los orígenes, los mantenedores y las fechas de creación o modificación (búsqueda de objetos route y route6). Una búsqueda de conjuntos AS podría revelar si el ASN aparece directamente dentro de un as-set utilizado para expresar una política de encaminamiento (búsqueda de as-set).

Esos datos son importantes porque describen una autorización o una declaración técnica más específica que el simple nombre del ASN. También tienen límites claros. Un objeto IRR puede permanecer en una base de datos después de que un anuncio BGP haya desaparecido. Puede ser mantenido por una entidad distinta de la que opera los routers. Un as-set puede reflejar una agrupación declarada, estar desactualizado o incluir relaciones de política que no equivalen a propiedad común ni a un contrato de cliente.

La prueba debe avanzar entonces hacia la observación del comportamiento de la red. RIPEstat puede proporcionar prefijos anunciados, estado de enrutamiento, historial de visibilidad y sistemas autónomos vecinos para una ventana temporal concreta (prefijos anunciados; estado de enrutamiento; historial de rutas; vecinos de AS210860). BGP.Tools y el BGP Toolkit de Hurricane Electric pueden servir como comprobaciones independientes de etiquetas, prefijos y relaciones observadas (BGP.Tools; Hurricane Electric).

Un anuncio observado con AS210860 como origen demostraría algo concreto: que una vista de medición vio a ese ASN originar un prefijo en un momento determinado. No demostraría por sí solo quién pagó la conectividad, quién posee el espacio de direcciones, quién tiene autoridad para apagar o restaurar la ruta, ni quién presta un servicio a usuarios finales. La ausencia de un anuncio tampoco sería concluyente: los colectores tienen cobertura incompleta y una retirada temporal puede coexistir con registros administrativos todavía activos.

RPKI estrecha la pregunta, pero tampoco identifica al operador

La autorización criptográfica añade otra prueba distinta. Un ROA puede autorizar a AS210860 a originar un prefijo concreto hasta una longitud máxima determinada. Los validadores RPKI, incluida la exportación pública de Cloudflare, permiten comprobar si existe una autorización válida para una combinación de prefijo, origen y longitud (datos validados de RPKI). La especificación de ROA de la IETF explica el papel de esa autorización dentro de la validación del origen de rutas (RFC 6482).

La coincidencia entre un anuncio BGP y un ROA válido sería una señal técnica más fuerte que un objeto IRR aislado. Aun así, no probaría que DFINFRA opere físicamente la red. Un ROA puede autorizar un origen sin que el prefijo esté anunciado en ese instante. Puede existir una autorización válida aunque el titular del espacio de direcciones haya delegado la operación a un tercero. Y una ruta puede ser inválida porque excede la longitud máxima, aunque exista un ROA que cubra una parte del prefijo. Por eso la comparación debe hacerse con el prefijo exacto y la longitud exacta observada.

La secuencia probatoria tendría que responder, en orden, a varias preguntas: ¿coincide la identidad de DFINFRA con el objeto aut-num vigente? ¿Los mantenedores que pueden cambiar los registros son atribuibles al mismo actor? ¿Los objetos route o route6 corresponden a los prefijos que realmente aparecen en BGP? ¿El origen observado está autorizado por RPKI para esa longitud? ¿La conectividad observada corresponde a un operador identificable? ¿Existe finalmente una empresa, un servicio, un contrato o una comunicación de cliente que conecte esa capacidad técnica con una consecuencia económica?

En el estado actual de la evidencia, ninguna de esas preguntas puede contestarse con valores vivos y completos. La investigación sí puede definir el estándar de prueba. No puede llenar los huecos con etiquetas agregadas, resultados antiguos o inferencias basadas en la repetición de un mismo nombre.

La interconexión describe visibilidad, no necesariamente una relación comercial

La información de PeeringDB podría aportar una descripción declarada por la propia red: nombre, organización, sitio web, tipo de red, alcance geográfico, política de enrutamiento, instalaciones e intercambios donde afirma participar (API de PeeringDB para AS210860). Esa información puede orientar la investigación hacia una identidad legal o un operador material. También puede ayudar a contrastar el nombre utilizado en RIPE con el nombre que se presenta ante la comunidad de interconexión.

Pero un perfil de PeeringDB es metadato operativo autoafirmado. La presencia de una instalación o de un punto de intercambio no demuestra que exista un puerto activo, una sesión bilateral vigente o un contrato de tránsito. Del mismo modo, una lista de vecinos inferida a partir de rutas puede sugerir conectividad, pero no distingue siempre entre proveedor, cliente, pares, servidores de rutas o relaciones indirectas. Las diferencias entre PeeringDB, RIPEstat y las fuentes BGP deben conservarse como discrepancias hasta que una fuente primaria las resuelva.

Ese punto es central para la economía del caso. La capacidad de originar una ruta puede ser operativamente relevante sin convertirse todavía en poder de mercado. Para demostrar dependencia de clientes, continuidad de servicio, capacidad de fijación de precios o exposición de flujo de caja harían falta evidencias adicionales: material de primera parte, contratos, condiciones de servicio, anuncios de clientes, facturación, registros corporativos o documentación operacional que identifique al actor y el mecanismo de valor. Ninguna de esas pruebas independientes fue recuperada en esta ejecución.

Lo que cambiaría la conclusión

La conclusión no depende de descubrir una narrativa más contundente, sino de obtener una cadena de observaciones compatibles. El próximo conjunto de evidencia decisivo sería una captura fechada que conecte a un operador identificable con el registro de AS210860, sus derechos de mantenimiento, los objetos de rutas correspondientes, un anuncio BGP observado y una autorización RPKI válida cuando resulte aplicable. A esa secuencia habría que añadir una fuente operacional o comercial independiente que demuestre quién presta el servicio, quién asume la continuidad o quién recibe el beneficio económico.

Un resultado contrario también sería informativo. Si la identidad del objeto aut-num no coincide con DFINFRA, si los mantenedores pertenecen a otra organización, si los objetos IRR no corresponden a los anuncios, si el origen BGP carece de autorización o si la información de interconexión no puede conectarse con un operador legal identificable, la hipótesis de control atribuible se debilitaría. Ninguna discrepancia aislada probaría una conducta indebida; sí impediría presentar la relación registral como control demostrado.

El estado actual es, por tanto, más estrecho que una acusación y más útil que una simple repetición del registro. DFINFRA y AS210860 forman una relación pública investigable. La evidencia disponible permite separar identidad administrativa, autorización declarada, observación de rutas y validación criptográfica. No permite todavía identificar al actor capaz de cambiar el estado de la red ni conectar esa capacidad con clientes, precios, continuidad o flujo de caja. La diferencia entre esas dos conclusiones es precisamente la diferencia entre una pista y una atribución defendible.