Resumen

  • Tata Communications contó que un cliente era dirigido a portales franceses pese a que el registro RIR estaba bien y otras bases Geo-IP reflejaban la ubicación esperada.
  • El dato incorrecto persistía en el proveedor externo de un portal tras unos dos meses de seguimiento, fuera del control directo del operador.

La frase «el registro ya está correcto» suele cerrar una incidencia antes de tiempo. En la experiencia que Tata Communications llevó al Cooperation SIG de APNIC 62, esa frase apenas señalaba el punto en el que empezaba la parte más opaca.

Un cliente terminaba en portales web de Francia. Tata revisó la información del RIR y comprobó que era correcta. Contrastó además varias bases de geolocalización de la industria, que daban el resultado esperado. Una excepción seguía activa: GEOLOCATION.com, nombre utilizado en la presentación, mantenía la asociación con Francia. El portal obtenía el dato de una base Geo-IP externa. Después de cerca de dos meses de gestiones, el proveedor aún no había actualizado la entrada, según las diapositivas. Tata podía aportar evidencia; no podía ordenar el cambio.

Hay que respetar los límites del relato. La presentación de Tata Communications no identifica el bloque, el cliente ni el proveedor, y tampoco ofrece volumen de afectados, desenlace o atribución contractual. El informe de la conferencia APNIC 62 acredita que el tema formó parte del programa. No convierte el ejemplo en una auditoría. Estamos ante un caso operativo, no ante una estadística ni un veredicto sobre una empresa.

Aun así, el recorrido permite ver cuatro estados distintos. Existe el registro del recurso Internet. Existe lo que el operador afirma sobre el uso geográfico de ese recurso. Existe la versión que mantiene el proveedor Geo-IP. Y existe, finalmente, la copia desplegada por el portal. Dos estados pueden coincidir sin arrastrar a los otros dos. La corrección no viaja por causalidad; necesita interfaces, plazos y decisiones.

Los RFC recientes cubren una parte importante. RFC 8805 especifica un formato para que los operadores publiquen geofeeds. RFC 9632 describe cómo descubrirlos mediante RPKI y RFC 9877 cómo validarlos. Así se reduce la duda sobre quién formuló una declaración y sobre si fue alterada. Pero un geofeed autenticado no lleva incorporado un compromiso de ingestión. Cada proveedor conserva sus fuentes, sus filtros y su ciclo de publicación.

El borrador de informe de un taller del IAB documenta precisamente ese terreno: procesos manuales o asíncronos, ubicaciones que pueden quedar obsoletas durante semanas o meses y ausencia de un bucle estándar para que un ISP conozca el estado de su aviso. Aunque ha sido enviado al RFC Editor, sigue siendo un Internet-Draft y no expresa consenso del IETF ni una posición del IAB. Sirve para reconocer el mecanismo, no para extrapolar el caso.

La pieza que falta se parece menos a otra base de datos que a un recibo. Un aviso de corrección debería recibir un identificador estable; registrar qué evidencia fue aceptada; señalar qué versión del conjunto de datos se evalúa; comunicar aceptación, rechazo o necesidad de más pruebas; y, si procede, indicar la versión en la que aparecerá el cambio. El portal, por su parte, debería poder mostrar qué edición consume. Todo ello puede hacerse con identificadores de recursos minimizados, sin exponer al cliente.

Ese diseño también protege al RIR. APNIC no tendría que prometer que una dirección se encuentra en un punto físico. Bastaría con hacer más verificable la transición desde un registro correcto hasta los actores que elaboran y consumen una inferencia. La responsabilidad se asignaría por estados observables y no por suposiciones.

La ausencia de esos estados vuelve engañosos algunos cierres de soporte. Una persona puede comprobar el registro RIR, adjuntar un geofeed y reproducir la decisión equivocada. El proveedor puede acusar recibo y dejar la solicitud para la próxima ingestión. El portal puede seguir con una versión en caché. Todos han realizado una acción, pero «recibido», «aceptado», «publicado» y «desplegado» no significan lo mismo. El usuario sólo ve que nada cambió.

También se puede mejorar la calidad de la evidencia. Cuando no existe un expediente estructurado, los operadores envían capturas, rutas, direcciones e información del cliente a un buzón genérico, sin saber qué señal utiliza el proveedor. Un sistema de estados permitiría identificar la alegación exacta, decir qué prueba fue evaluada y explicar un desacuerdo. No obligaría al proveedor a copiar el geofeed; le obligaría a hacer visible su decisión sobre él.

La especialización seguiría intacta. RIR y RPKI pueden acreditar control del recurso y procedencia de la declaración. El proveedor puede combinarla con enrutamiento, latencia, infraestructura y observaciones propias. El portal puede fijar la frescura que necesita. La trazabilidad une esos juicios, pero no los confunde ni inventa una fuente infalible.

Por eso es insuficiente responder al afectado con un enlace de consulta RIR. Si el dato ya es correcto, la respuesta lo devuelve al principio. El servicio debe señalar de dónde procede su decisión real, cuál es el calendario de actualización y qué prueba alternativa acepta mientras se tramita una corrección. Una selección de idioma puede asumir más incertidumbre que una restricción de acceso o un precio territorial.

Fuentes

La ausencia de esos estados vuelve engañosos algunos cierres de soporte. Una persona puede comprobar el registro RIR, adjuntar un geofeed y reproducir la decisión equivocada. El proveedor puede acusar recibo y dejar la solicitud para la próxima ingestión. El portal puede seguir con una versión en caché. Todos han realizado una acción, pero «recibido», «aceptado», «publicado» y «desplegado» no significan lo mismo. El usuario sólo ve que nada cambió.

También se puede mejorar la calidad de la evidencia. Cuando no existe un expediente estructurado, los operadores envían capturas, rutas, direcciones e información del cliente a un buzón genérico, sin saber qué señal utiliza el proveedor. Un sistema de estados permitiría identificar la alegación exacta, decir qué prueba fue evaluada y explicar un desacuerdo. No obligaría al proveedor a copiar el geofeed; le obligaría a hacer visible su decisión sobre él.

La especialización seguiría intacta. RIR y RPKI pueden acreditar control del recurso y procedencia de la declaración. El proveedor puede combinarla con enrutamiento, latencia, infraestructura y observaciones propias. El portal puede fijar la frescura que necesita. La trazabilidad une esos juicios, pero no los confunde ni inventa una fuente infalible.

Por eso es insuficiente responder al afectado con un enlace de consulta RIR. Si el dato ya es correcto, la respuesta lo devuelve al principio. El servicio debe señalar de dónde procede su decisión real, cuál es el calendario de actualización y qué prueba alternativa acepta mientras se tramita una corrección. Una selección de idioma puede asumir más incertidumbre que una restricción de acceso o un precio territorial.

Fuentes