Resumen

  • La asignación registral, la autoridad para modificar una base de datos, la autorización de origen, la visibilidad BGP, el control operativo y la responsabilidad contractual son proposiciones distintas.
  • La evidencia disponible no identifica a la persona o entidad que puede iniciar o revertir cambios de enrutamiento o de servicio para AS210057; cada posible fallo exige una vía de corrección diferente.

Un registro no es una cadena completa de responsabilidad

El primer límite es de jurisdicción. El registro de arranque de RDAP de IANA indica qué registro regional debe atender un número de sistema autónomo; no identifica por sí mismo al titular, al operador ni a un cliente. La ficha de AS210057 en los servicios de RIPE NCC puede mostrar el nombre del sistema, la organización enlazada, contactos, estado, mantenedores y fechas de modificación. Esas son pruebas sobre el objeto registral, no sobre quién configura actualmente los routers. IANA RDAP y los registros de RIPE NCC deben leerse junto con el objeto aut-num nativo y su interfaz de consulta.

La distinción importa porque un mantenedor o una cuenta autorizada puede tener capacidad para modificar un objeto de la base de datos sin ser el operador de la red, el proveedor de tránsito o la contraparte contractual de un usuario. El historial del objeto puede demostrar que cambiaron campos registrales, pero una modificación administrativa no demuestra que haya cambiado el control físico o lógico de la infraestructura. El historial de versiones sirve para fechar cambios de registro, no para convertirlos automáticamente en cambios de operación.

Las estadísticas delegadas y los resúmenes derivados ayudan a corroborar la existencia administrativa del recurso y su visibilidad, pero tienen un alcance más estrecho que el objeto original. La estadística delegada de RIPE NCC, el resumen de AS210057 y la vista WHOIS derivada no prueban por separado la identidad jurídica, el control diario o la continuidad de un servicio.

Autorización no equivale a operación

Una segunda capa se refiere a la autorización de rutas. Los objetos IRR pueden expresar que una relación entre un prefijo y un origen está declarada en una base de datos mantenida mediante autenticación. RPKI y las ROA añaden una autorización criptográfica del origen para un prefijo, evaluada según el recurso, el origen y el momento. Ninguna de esas capas demuestra quién opera cada router ni que una ruta autorizada se haya anunciado efectivamente.

La búsqueda inversa de objetos route y route6 debe contrastarse con la lista de prefijos anunciados y con los datos de estado de enrutamiento. La documentación de RPKI de RIPE NCC, RFC 6482 y la guía sobre objetos de autorización describen instrumentos de autorización, no una prueba universal de propiedad o control operativo.

Una observación BGP también es temporal y depende del punto de observación. Los datos de RIPE RIS, Route Views, el estado BGP de RIPEstat, el historial de enrutamiento y el historial RPKI pueden establecer qué observó una fuente durante un intervalo definido. No establecen por sí solos quién dio la orden, quién podía revertirla o quién asumía una obligación frente a terceros. PeeringDB y una vista de terceros como bgp.tools pueden aportar contexto, pero no sustituyen las fuentes registrales ni los contratos.

La identidad sigue siendo una cuestión abierta

El nombre INFINITYWIFI en un objeto de ASN es una etiqueta registral. La investigación disponible no aporta un puente verificado entre INFINITYWIFI, AS210057 y Comcast o Xfinity WiFi. Una coincidencia nominal no demuestra afiliación, propiedad, operación, clientes o ingresos. La búsqueda del registro mercantil británico para InfinityWiFi Limited puede servir para comprobar una posible identidad jurídica, pero la mera coincidencia del nombre tampoco conecta automáticamente esa sociedad con el ASN o con un servicio concreto.

Por eso, la pregunta pendiente no es simplemente quién aparece escrito en una página. Es qué persona o entidad tiene capacidad demostrable para iniciar, modificar y revertir una acción de red, y qué documento vincula esa capacidad con una obligación frente a un cliente o a un operador afectado.

Qué recurso corresponde a cada fallo

El remedio debe seguir la proposición que se pueda probar. Si el error es un dato registral, la ruta inicial es la corrección mediante el mantenedor autorizado o el soporte de la base de datos, conforme a la documentación de la base de datos de RIPE y sus canales de contacto. Si el problema es tráfico abusivo o sospecha de uso indebido de una ruta, el contacto de abuso y los titulares de recursos u operadores técnicos son puntos de escalamiento; un buzón de abuso no equivale a atención al cliente ni garantiza restauración, reembolso o adjudicación de titularidad.

Si el fallo es una relación de origen no autorizada, la revisión debe incluir al titular del prefijo, la autorización aplicable, los objetos IRR, la validación RPKI y observaciones independientes durante un intervalo definido. Si el fallo es una interrupción del servicio, hace falta identificar primero la contraparte contractual, el servicio afectado, la fecha, la obligación incumplida y la jurisdicción. Sin contrato, factura, cuenta, reclamación o registro de incidente, no puede atribuirse una reparación contractual a INFINITYWIFI o a AS210057.

En el Reino Unido, una eventual vía regulatoria dependería de demostrar que existe un proveedor y una relación de servicio dentro del ámbito correspondiente. Las guías de Ofcom sobre reclamaciones de telefonía e Internet, las condiciones generales de telecomunicaciones, el marco legal aplicable y la información sobre compensación automática no crean por sí mismos una relación contractual ni prueban que Ofcom tenga jurisdicción sobre este caso.

El resultado verificable, por ahora, es más limitado y más útil que una atribución apresurada: los registros, los sistemas de autorización, los colectores de rutas, los contactos técnicos y los reguladores ocupan posiciones diferentes en la cadena de responsabilidad. La evidencia suministrada no identifica todavía al controlador operativo ni a la contraparte que debería responder por un fallo de servicio. Para cambiar esa conclusión harían falta un objeto registral actual inspeccionado directamente, evidencia operativa corroborada, una identidad jurídica vinculada y un contrato, incidente o procedimiento con partes identificables.

Fuentes adicionales de verificación: contacto de abuso de RIPEstat y documentación RIPE-679 sobre objetos de autorización.

Fuentes adicionales de verificación: documentación RIPE-679.