Resumen

  • La evidencia pública disponible permite diseñar una prueba de cinco capas para AS210860, pero no demuestra que DFINFRA sea su propietario, operador o controlador.
  • La condición decisiva sería una modificación observable de rutas o autorizaciones vinculada a evidencia independiente de que DFINFRA inició, aprobó o pudo revertir ese cambio.

La pregunta importante sobre DFINFRA no es simplemente qué nombre aparece junto a AS210860 en un registro. Es si puede construirse una cadena de evidencia que conecte esa identidad con una operación de red observable y, finalmente, con una capacidad atribuible de cambiarla.

La diferencia parece técnica, pero tiene consecuencias prácticas. Un número autónomo puede estar correctamente registrado sin que el registro revele quién administra los routers. Un objeto de rutas puede declarar una intención de originar un prefijo sin demostrar que ese prefijo esté anunciado. Una autorización RPKI puede validar un origen permitido sin probar que el anuncio esté activo ni identificar a quien opera la infraestructura. Y una observación BGP puede mostrar que una red aparece en los caminos de Internet sin establecer su propiedad legal o su capacidad de decisión.

La investigación previa sobre DFINFRA ya estableció esa separación básica: la asociación pública con AS210860 es una señal registral, no una prueba de propiedad legal, autoridad de mantenimiento, operación activa o control de enrutamiento. El paso adicional consiste en definir qué evidencia podría superar esa ambigüedad y qué conclusiones deben permanecer fuera de alcance.

Cinco capas que no deben confundirse

La primera capa es la identidad registral. El objeto aut-num de RIPE Database y el registro RDAP pueden aportar el nombre registrado, referencias organizativas, estado, contactos, fechas de eventos y cuentas mantenedoras. El registro de un mantenedor es evidencia de autoridad administrativa sobre determinados objetos de la base de datos. No equivale, por sí solo, a una prueba de control sobre el equipo que origina rutas.

El objeto aut-num de AS210860 debe leerse como una declaración administrativa situada en un sistema de registro. La búsqueda inversa de objetos route y route6 puede mostrar qué prefijos tienen a AS210860 en el atributo origin. Pero un objeto IRR es una declaración de intención o autorización dentro de un registro de enrutamiento. Puede estar desactualizado, faltar aunque exista un anuncio real o persistir después de que una ruta deje de utilizarse. Por eso, la evidencia registral y la evidencia de operación deben compararse, no sustituirse.

La segunda capa es la autorización de rutas. RPKI permite comprobar si existe una ROA que autoriza a un ASN a originar un prefijo hasta una longitud máxima determinada. Si una respuesta de validación coincide con una ruta observada, esa coincidencia aporta una señal criptográfica de autorización del origen. No demuestra quién solicitó la ROA, quién administra los routers, quién posee el ASN ni quién puede retirar el anuncio.

También es importante la dimensión temporal. Una ROA válida en un momento determinado no prueba que la misma autorización exista hoy. Los validadores pueden presentar estados distintos durante procesos de sincronización, actualización de repositorios o renovación de cachés. La clasificación RPKI debe atribuirse al momento observado y al prefijo concreto; no debe convertirse en una afirmación general sobre la empresa asociada al ASN.

La tercera capa es el comportamiento BGP. RIPEstat puede servir para observar prefijos anunciados, estado de enrutamiento, historia, actualizaciones, caminos visibles y vecinos observados para AS210860. Esas mediciones pueden demostrar que el ASN fue visible como origen durante una ventana temporal. Varias fuentes independientes —por ejemplo, RIPE RIS, bgp.tools y el BGP Toolkit de Hurricane Electric— pueden reforzar la confianza en que la visibilidad no procede de una sola vista o de un registro administrativo.

Pero BGP tampoco resuelve la atribución. La visibilidad depende de los colectores, del momento de consulta y de la propagación. Una adyacencia observada en un AS-path no demuestra que exista una relación comercial de tránsito, peering sin liquidación, peering pagado u otro acuerdo. Tampoco revela necesariamente quién configuró la sesión, quién contrató la capacidad o quién puede modificarla.

La cuarta capa es la topología y la huella pública de interconexión. PeeringDB puede contener información declarada por un operador sobre tipo de red, política de peering, instalaciones, puntos de intercambio, contactos y presencia. CAIDA AS Rank puede aportar relaciones inferidas y contexto topológico. RIPE Atlas puede ayudar a identificar mediciones o sondas asociadas con el ASN. Estas fuentes son útiles porque acercan la investigación a la infraestructura observable, pero sus valores deben tratarse como declarados, inferidos o medidos según corresponda.

Una ficha detallada y reciente en PeeringDB, alineada con anuncios BGP actuales, objetos registrales coherentes y mediciones independientes, sería una señal más fuerte de participación operativa que una sola inscripción. Aun así, seguiría sin demostrar por sí sola la identidad legal de quien controla la red. La ausencia de una ficha, de instalaciones o de mediciones tampoco demostraría que no existe operación: las interconexiones privadas, los perfiles incompletos y las diferencias de cobertura dejan zonas ciegas.

La quinta capa es la capacidad atribuible de actuar. Es la capa que falta con mayor frecuencia en las investigaciones basadas únicamente en datos públicos de routing. Para hablar de operación o control en sentido fuerte haría falta conectar un cambio técnico con una persona, organización o proceso capaz de causarlo, sostenerlo, alterarlo o revertirlo. Un correo operativo verificable, un registro de cambio publicado por el operador, una declaración contemporánea respaldada por datos técnicos o un expediente contractual podrían ser relevantes. El estándar no es encontrar un nombre junto a un ASN, sino demostrar una relación causal.

Lo que la evidencia disponible permite afirmar

El paquete de investigación reúne 18 fuentes públicas relevantes para las capas registral, de rutas, autorización, topología y medición. Incluye las APIs de prefijos anunciados, estado de routing, historia, actualizaciones, looking glass, vecinos y consistencia de RIPEstat; objetos aut-num y búsquedas inversas de RIPE Database; RDAP; datos RPKI de Cloudflare; y referencias de bgp.tools, Hurricane Electric, PeeringDB, CAIDA AS Rank y RIPE Atlas.

La lista de fuentes identifica cómo podría probarse cada parte de la hipótesis, pero no debe confundirse con resultados actuales. Las respuestas dinámicas no fueron recuperadas en vivo durante esta investigación. Por tanto, no están verificados el conjunto actual de prefijos, su número, los estados RPKI, los mantenedores, los objetos de rutas, los AS vecinos, las instalaciones, los puntos de intercambio ni las fechas de cambio.

Esa limitación no vuelve inútil el trabajo. Cambia la naturaleza de la conclusión. En lugar de afirmar que DFINFRA opera una red determinada, la investigación establece una prueba reproducible para distinguir cuatro situaciones: una presencia puramente administrativa; una identidad registral acompañada de declaraciones IRR; una visibilidad BGP respaldada por autorización criptográfica; y un control operativo atribuible con evidencia de quién puede tomar decisiones.

La diferencia entre esas situaciones importa para continuidad y dependencia. Si una organización aparece como proveedor o intermediario de conectividad, un lector puede querer saber quién tiene capacidad real para mantener el servicio. Si un ASN anuncia prefijos de clientes o de infraestructura propia, la pregunta no es únicamente cuántos prefijos aparecen, sino qué ocurriría si fueran retirados, redirigidos o reasignados. Sin evidencia sobre clientes, contratos, volumen de tráfico o arquitectura física, no es posible traducir una observación de routing en una cifra de mercado, ingresos o dependencia.

Tampoco es válido inferir un controlador alternativo a partir del silencio de una fuente, de una discrepancia entre bases de datos o de un registro incompleto. Las fuentes pueden tener retrasos, definiciones diferentes y cobertura desigual. Una contradicción entre RIPE RIS, bgp.tools y Hurricane Electric debe investigarse como una posible diferencia de tiempo, colectores o metodología antes de convertirse en una acusación sobre quién controla el ASN.

El mecanismo de impacto: continuidad antes que reputación

La cadena causal que debe interesar a operadores e inversores es concreta. Primero, una entidad debe estar vinculada de forma verificable a recursos de numeración o a una red. Segundo, esos recursos deben mostrar actividad operacional en una ventana temporal definida. Tercero, la actividad debe coincidir con controles de autorización y con una huella de interconexión o medición que reduzca la probabilidad de que se trate de una mera inscripción. Cuarto, debe existir evidencia de que la entidad puede provocar o revertir cambios.

Solo entonces puede evaluarse si una alteración de esa capacidad afectaría continuidad, capacidad disponible, rutas de clientes o poder de negociación.

Sin el cuarto eslabón, la investigación puede describir la superficie de Internet, pero no el centro de decisión. Y sin datos sobre servicios dependientes, no puede concluir que una retirada de rutas produciría una pérdida comercial concreta. El rigor exige dejar visible ese límite.

Para lectores técnicos, la próxima medición útil sería una línea base fechada. Esa línea debería registrar los prefijos observados, los orígenes BGP, los caminos visibles, los objetos IRR, las ROA correspondientes, los vecinos y cualquier presencia declarada en instalaciones o IX. Una segunda captura permitiría identificar adiciones, retiros, cambios de longitud máxima, variaciones de adyacencias o modificaciones registrales. Cada cambio debería compararse con una fuente independiente y con evidencia de quién lo inició o podía deshacerlo.

El valor probatorio aumentaría si el mismo cambio apareciera en varias capas: una actualización BGP después de una modificación registral; una ROA que autorizara el nuevo origen; un objeto route coherente; visibilidad desde más de un colector; y una comunicación atribuible al operador. Ninguna coincidencia aislada bastaría. La fuerza surgiría de la convergencia temporal y causal.

Qué no está demostrado

Con los datos reunidos no está demostrado que DFINFRA sea propietaria legal de AS210860. Tampoco está demostrado que opere los routers que puedan originar rutas con ese ASN, que administre sus relaciones de tránsito o peering, que mantenga las ROA, que controle los objetos IRR o que pueda ordenar una retirada de anuncios.

No están demostrados un número actual de prefijos, una tasa de actualizaciones, una relación concreta con un upstream, una instalación física, un punto de intercambio, una base de clientes ni una consecuencia financiera. La existencia de fuentes públicas capaces de medir esos elementos no sustituye la medición efectiva.

Esa conclusión acotada es más útil que una afirmación amplia y frágil. Permite a un operador saber qué comprobar antes de depender de la identidad registral de una contraparte. Permite a un inversor distinguir una huella técnica de una capacidad empresarial. Y permite a un investigador evitar el error habitual de convertir una etiqueta de base de datos en una atribución de control.

La siguiente condición observable

La investigación cambiaría de nivel si, después de una línea base documentada, se produjera un cambio material en el anuncio BGP o en el estado de autorización y existiera evidencia independiente de que DFINFRA lo inició, aprobó o podía revertirlo. El cambio debería ser visible a través de fuentes pertinentes y estar acompañado por una relación temporal clara entre el acto atribuible y el efecto técnico.

Hasta entonces, la descripción más precisa es también la más prudente: DFINFRA aparece como una identidad asociada públicamente con AS210860 dentro de un conjunto de registros y fuentes de routing que permiten investigar su huella operativa. El material disponible señala cómo probar la conexión, pero no la demuestra. La diferencia entre estar registrado, ser visible y tener capacidad de decisión es precisamente el objeto de la investigación.

Fuentes: RIPEstat: prefijos anunciados; RIPEstat: estado de routing; RIPEstat: historia de routing; RIPEstat: actualizaciones BGP; RIPEstat: looking glass; RIPEstat: vecinos del ASN; RIPEstat: consistencia de routing; RIPE Database: objeto aut-num; RIPE Database: búsqueda inversa de origen; RIPEstat: historial Whois; RIPE RDAP; Cloudflare RPKI; bgp.tools; Hurricane Electric BGP Toolkit; PeeringDB; CAIDA AS Rank; RIPE Atlas IPv4; RIPE Atlas IPv6. Más información del directorio: DFINFRA.