Resumen

  • La investigación asocia públicamente a ROYA Communications and Internet Services Company Ltd con AS210837, pero las respuestas actuales de los registros y observatorios no fueron recuperadas en esta investigación.
  • Un hallazgo de continuidad exigiría combinar identidad registral, anuncios observados y fechados, alcance, dependencias, señales de control operativo y pruebas repetidas de recuperación; ningún registro aislado puede demostrarlo todo.

La pregunta no es si existe el ASN

Un número de sistema autónomo resuelve una pregunta administrativa: qué identificador aparece en un registro y qué organización está vinculada a él. No resuelve automáticamente la pregunta operativa: quién anuncia rutas, quién decide la política de encaminamiento, qué infraestructura sostiene la conectividad, qué dependencias pueden interrumpirla y qué evidencia mostraría que una reparación resistió el paso del tiempo.

En el caso de ROYA, el material de investigación disponible trata la asociación con AS210837 como una relación pública acotada, no como una prueba de operación actual. La investigación no recuperó las respuestas vivas de RIPE Database, RDAP, RIPEstat, PeeringDB ni de los agregadores de BGP citados en este artículo. Por ello, no es responsable afirmar en este artículo cuántos prefijos anuncia AS210837, qué vecinos tiene, si dispone de ROAs válidos o si ofrece actualmente servicio a clientes.

La diferencia entre lo que está registrado y lo que está observado es el centro del caso. El objeto de RIPE puede documentar una identidad, referencias administrativas, mantenedores o una política declarada. Un recolector BGP puede observar un anuncio desde determinados puntos de vista. Un validador RPKI puede evaluar una relación entre un prefijo y un origen. PeeringDB puede conservar información publicada por el operador. Cada capa aporta una pieza distinta. Ninguna, por separado, demuestra control operativo completo ni continuidad del servicio.

Qué puede demostrar el registro

La fuente primaria para empezar sería el objeto aut-num de AS210837 en RIPE Database, complementado por el registro RDAP del mismo sistema. Esas fuentes son apropiadas para comprobar el estado registral, la organización vinculada, las referencias administrativas, los mantenedores, las fechas de creación o modificación y cualquier política RPSL declarada. La consulta al objeto y la consulta RDAP deberían compararse porque presentan la información con estructuras y relaciones diferentes: objeto aut-num de AS210837 en RIPE Database y registro RDAP de AS210837.

Pero una fecha de modificación del registro no es una fecha de disponibilidad de red. Una política import o export describe intención declarada, no prueba que una sesión BGP estuviera activa en el momento de la consulta. La organización enlazada al ASN tampoco demuestra quién opera cada router, quién tiene acceso a las credenciales, quién mantiene los filtros ni quién puede restaurar el servicio.

La diferencia importa para la atribución. Decir que una entidad aparece vinculada a un ASN es una afirmación sobre una relación registral. Decir que esa entidad controla las rutas, atiende clientes o puede reparar una interrupción es una afirmación adicional que requiere otra evidencia. Confundir ambas convierte un directorio administrativo en una conclusión sobre la realidad operacional.

La intención declarada no equivale a un anuncio vivo

Una búsqueda inversa en RIPE Database puede identificar objetos route y route6 cuyo origen declarado es AS210837: búsqueda de objetos de ruta y route6 para AS210837. Esos objetos pueden ser útiles para generar filtros y comparar la intención declarada con lo que observan los recolectores. No prueban, por sí solos, que un prefijo esté siendo anunciado en BGP ni que un anuncio sea aceptado por otros operadores.

La comparación correcta tiene al menos tres capas. Primero, qué prefijos aparecen declarados en el registro de encaminamiento. Segundo, cuáles son observados por uno o más recolectores durante un intervalo definido. Tercero, si existe una autorización RPKI compatible con cada relación prefijo-origen. Una discrepancia no debe etiquetarse automáticamente como fraude, abandono o fallo. Puede reflejar datos antiguos, cambios de operador, visibilidad incompleta, diferencias de tiempo o una configuración que no se actualizó en todos los sistemas.

Por eso, la ausencia de un objeto IRR no prueba que nunca existiera una ruta, y la existencia de un objeto IRR no prueba que la ruta esté activa. El registro describe una declaración técnica. La observación de BGP describe una señal externa. Son evidencias relacionadas, pero no intercambiables.

Qué pueden observar los recolectores BGP

RIPEstat ofrece varios puntos de entrada para observar la presencia de AS210837 en el plano de control. La vista general del ASN puede indicar si el sistema fue observado como anunciado en el momento de la consulta. La lista de prefijos anunciados puede enumerar prefijos atribuidos por RIPE RIS al ASN. El estado BGP puede aportar rutas y trayectorias visibles. La lista de vecinos puede mostrar ASNs adyacentes en los caminos observados.

Estas fuentes responden preguntas de observación, no todas las preguntas de operación. Un anuncio visto por RIPE RIS prueba que determinados colectores recibieron una ruta compatible con ese origen. No prueba alcance universal desde todas las redes, tráfico de clientes, propiedad legal del espacio de direcciones ni control exclusivo sobre la infraestructura. Un vecino observado antes o después de AS210837 en una ruta demuestra una adyacencia visible en ese camino; no demuestra por sí mismo que exista un contrato comercial de tránsito.

También deben considerarse las diferencias entre las fuentes. BGPView, bgp.tools y otros servicios pueden ofrecer vistas agregadas o derivadas, pero sus resultados pueden depender de colectores compartidos, ventanas de caché y reglas de inferencia distintas. La API de prefijos de BGPView, sus clasificaciones de upstreams, sus clasificaciones de pares y la vista de bgp.tools son útiles para contrastar observaciones, no para convertir una etiqueta inferida en un contrato probado.

Una investigación responsable debe registrar la hora de cada consulta y comparar conjuntos equivalentes. Un recuento de prefijos de un día no debe compararse sin más con un recuento de otra fecha. Un cambio puede ser real, pero también puede deberse a ventanas de observación, cobertura de colectores o diferencias de agregación.

Detección, interrupción y recuperación

Las series temporales son necesarias para estudiar continuidad, aunque tampoco resuelven toda la pregunta. La API de actualizaciones BGP puede ayudar a localizar anuncios y retiros dentro de un intervalo. La historia de encaminamiento puede mostrar cambios en la visibilidad de prefijos. BGPlay puede ayudar a visualizar cambios de caminos y episodios de desaparición o reaparición.

Un retiro observado es una señal de cambio en el plano de control. No identifica por sí mismo la causa: puede tratarse de una decisión administrativa, una modificación de política, un fallo de transporte, una pérdida de alimentación eléctrica, una intervención de seguridad o una variación de la visibilidad de los colectores. Una reaparición demuestra recuperación de visibilidad del anuncio, pero no demuestra que los usuarios recuperaran el acceso, que los sistemas internos estuvieran sanos o que el problema no volviera a ocurrir.

La continuidad tiene dos dimensiones que deben mantenerse separadas. La primera es la continuidad del anuncio: si el mundo exterior sigue observando rutas. La segunda es la continuidad del servicio: si los usuarios pueden alcanzar los destinos y recibir el servicio esperado. Un sistema puede mantener una ruta anunciada mientras su plano de datos está degradado. También puede retirar una ruta durante un cambio controlado sin que exista un fallo del servicio. La señal BGP es indispensable, pero no suficiente.

Para atribuir prevención y detección hay que buscar indicadores de control. La prevención puede incluir filtros de origen, objetos IRR, ROAs, validación RPKI, límites de prefijos y redundancia de tránsito. La detección puede incluir alertas sobre retiros, cambios de camino, pérdida de visibilidad y degradación de alcance. Sin registros operativos, intervalos reproducibles y una atribución clara de quién podía actuar, no se puede afirmar que esos controles existieran o fueran efectivos en ROYA.

RPKI: autorización, no garantía de servicio

RPKI debe interpretarse por relación entre prefijo y ASN de origen, no como una propiedad única e inmutable de AS210837. La historia RPKI de RIPEstat y las vistas de Cloudflare RPKI para AS210837 son fuentes candidatas para comprobar estados y ROAs, pero las respuestas actuales no fueron recuperadas en esta investigación.

Un resultado Valid puede respaldar que existe una autorización criptográfica para que un ASN origine un prefijo dentro de una longitud máxima concreta. No autentica el camino BGP completo, no demuestra que todos los upstreams rechacen rutas inválidas y no confirma que el servicio de usuarios esté disponible. Un resultado NotFound indica que el validador no encontró una autorización aplicable; no equivale automáticamente a una acusación de secuestro. Un resultado Invalid requiere examinar el prefijo, el origen, la longitud máxima y las autorizaciones que lo cubren.

La propia especificación de ROA explica el alcance de esa autorización en RFC 6482, mientras que la validación del origen se describe en RFC 6811. La conclusión práctica es estrecha: RPKI puede reforzar un control preventivo contra ciertos anuncios de origen no autorizados, pero no prueba quién mantiene los routers, quién decide las rutas, si el camino completo es seguro ni si los clientes reciben servicio.

Dependencias y peering: lo que aún no se sabe

PeeringDB puede aportar información publicada por un operador sobre nombre de red, política, instalaciones, puntos de intercambio y funciones de contacto. La consulta de red para AS210837 está disponible como registro de PeeringDB. Si existe un registro coincidente, su contenido puede orientar la investigación de dependencias. Si no existe, solo demostraría que no se encontró allí un registro público coincidente en el momento de la consulta.

La presencia en PeeringDB no prueba que una sesión siga activa. La ausencia no prueba que no haya tránsito privado, interconexión no publicada o una relación que se documente en otra fuente. Del mismo modo, una lista de upstreams inferida por un agregador no demuestra condiciones contractuales, capacidad reservada ni responsabilidad exclusiva por la conectividad.

Para determinar quién controla la prevención y la detección habría que conectar las dependencias observadas con decisiones concretas. Si una ruta desaparece, ¿qué organización puede cambiar la sesión? Si un ROA es incorrecto, ¿quién puede modificarlo? Si un upstream deja de transportar tráfico, ¿existe un camino alternativo? Si el operador depende de una sola instalación, una sola alimentación o un solo proveedor, ¿hay evidencia de redundancia? El material disponible identifica las fuentes que podrían ayudar a contestar estas preguntas, pero no contiene las respuestas actuales.

Las vistas de Cloudflare Radar para el ASN, CAIDA AS Rank, IODA, BGP.he.net y las APIs de BGPView pueden servir para ampliar la comparación. Algunas muestran actividad de encaminamiento, otras proporcionan inferencias de relaciones o señales de impacto. Ninguna debe ser presentada como una prueba completa de control, dependencia comercial o resiliencia sin revisar su metodología y su ventana temporal.

Qué requeriría un hallazgo de reparación durable

Una reparación durable no se demuestra con una captura favorable. Requiere repetición y conexión entre capas. Como mínimo, una investigación posterior debería:

  1. Recuperar en fechas y horas registradas el objeto de RIPE, RDAP y los objetos IRR.
  2. Enumerar los prefijos observados por más de un colector y conservar sus tiempos de observación.
  3. Comparar los caminos y vecinos con las políticas declaradas, sin convertir automáticamente una adyacencia en una relación comercial.
  4. Evaluar cada par prefijo-origen en al menos un validador RPKI y registrar el ROA aplicable.
  5. Contrastar la visibilidad del plano de control con mediciones de alcance o del plano de datos cuando estén disponibles.
  6. Identificar qué organización o función podía prevenir, detectar y corregir cada clase de fallo.
  7. Repetir las mediciones después de la supuesta reparación para comprobar que la mejora no fue momentánea.

La palabra “durable” añade una exigencia temporal. Una ruta restaurada durante una hora prueba menos que una ruta observada de forma estable en intervalos separados y desde fuentes independientes. Incluso esa estabilidad no demuestra por sí sola la calidad del servicio de clientes. La conclusión debe indicar exactamente qué capa se observó y cuál permanece desconocida.

Conclusión acotada

La evidencia reunida para esta investigación permite definir una investigación verificable, no emitir un certificado de operación actual. ROYA está asociada públicamente con AS210837 en el material de investigación, pero las respuestas vivas necesarias para confirmar estado registral actual, prefijos, caminos, relaciones, ROAs y continuidad no fueron recuperadas. Por ello, no puede afirmarse aquí que AS210837 esté anunciando rutas, que ROYA controle actualmente esas rutas, que exista una base de clientes activa o que haya demostrado una reparación durable.

La lección no es que el ASN carezca de valor. Es que su valor depende de la pregunta. Para identificar un punto de partida administrativo, el registro es relevante. Para demostrar operación, hacen falta observaciones de encaminamiento. Para evaluar prevención, hay que examinar filtros, IRR y RPKI. Para evaluar detección y recuperación, se necesitan series temporales y registros de incidentes. Para atribuir control, deben identificarse las decisiones y las personas u organizaciones capaces de ejecutarlas. Para afirmar resiliencia, la evidencia debe repetirse después de la reparación.

En ausencia de esa cadena completa, la conclusión más rigurosa es también la más limitada: AS210837 es un objeto investigable asociado públicamente con ROYA, pero la continuidad operacional y la capacidad de reparación siguen sin estar establecidas por las respuestas actuales de las fuentes consultadas.

Fuentes y límites de la consulta

Las fuentes anteriores fueron identificadas como registros públicos o servicios técnicamente relevantes. En esta investigación no fue posible recuperar sus respuestas HTTP en vivo. Los prefijos actuales, estados RPKI, caminos, relaciones, alcance y eventos de continuidad deben verificarse antes de tratarlos como hechos actuales.