Resumen

  • La versión del 28 de julio de 2026 incorporó autenticación de Reg-RWS mediante el encabezado Authorization. Al día siguiente, ARIN cerró la sugerencia ACSP 2022.5 y dejó claro que seguiría aceptando tokens en los parámetros de URL.
  • Las fuentes públicas consultadas confirman la alternativa y recomiendan cambiar, pero no indican una fecha de retirada, hitos de migración, el volumen de llamadas que aún usan la URL ni una tasa de adopción. El cierre acredita la entrega de una función; no demuestra que se haya retirado el transporte anterior ni que los clientes hayan migrado.

Una llamada, dos calendarios

Una llamada al registro debe identificar el recurso solicitado y comprobar que el cliente tiene autorización para acceder a él. Reg-RWS permite automatizar tareas que incluyen la gestión de RPKI e IRR, reasignaciones y realocaciones, y actualizaciones de bloques de red. Durante años, la llamada documentada podía llevar un token API en la cadena de consulta de la URL. En julio de 2026, ARIN añadió otra vía: la URL identifica el recurso y la clave viaja aparte en un encabezado Authorization.

El resultado funcional puede ser el mismo; la superficie de exposición no. Una URL suele quedar guardada en el historial del navegador, los registros de solicitudes, los proxies y los diagnósticos. En su explicación de agosto, ARIN señala precisamente el historial del navegador y los registros de servidores y proxies como lugares donde puede persistir una clave incluida en la URL. Trasladarla al encabezado reduce la posibilidad de que se difunda accidentalmente.

No vuelve invisible el secreto: una aplicación, un proxy, una herramienta de trazas o un paquete de soporte todavía puede registrar el valor del encabezado si la configuración es descuidada. La mejora práctica reduce la exposición por defecto; no elimina la gestión de credenciales.

Las fechas separan con nitidez ambos asuntos. La sugerencia ACSP 2022.5 se presentó el 11 de febrero de 2022. Pedía una alternativa al token en las URL REST y advertía que los sistemas que registran la URL completa podían revelar un token válido a quien tuviera acceso a esos registros, con la posibilidad de habilitar acceso no autorizado. El plazo propuesto era «no especificado». El 23 de febrero, ARIN respondió que un encabezado HTTP era la mejor solución, incluiría el trabajo entre las prioridades de la hoja de ruta de ingeniería para 2023 y mantendría abierta la sugerencia hasta su implementación.

El 28 de julio de 2026, ARIN anunció que las llamadas REST podían usar un encabezado Authorization con el esquema ApiKey. El 29 de julio, su respuesta de cierre dijo que la alternativa preferida ya estaba desplegada y que los tokens seguirían aceptándose como parámetros de URL. La solicitud se consideró cumplida porque existía la alternativa pedida; el cierre no afirmaba que el acceso anterior hubiese terminado. La explicación técnica del 11 de agosto y ARIN Bits de septiembre confirmaron que el método URL seguía siendo aceptable por el momento, que acabaría retirándose y que se recomendaba migrar ya.

Hay dos calendarios superpuestos. El primero mide la entrega: una sugerencia se registra, se evalúa, se implementa y se cierra. El segundo mide la migración: los clientes se enteran, actualizan sus herramientas, validan la nueva forma de la llamada, sacan el secreto de las URL y dejan de usar el camino anterior. El primer calendario tiene un cierre explícito en el registro público. El segundo todavía carece de fecha pública y de una medida publicada.

Esto no cuestiona el cierre de la sugerencia. Una petición para añadir una alternativa puede quedar satisfecha cuando esa alternativa funciona, aunque los clientes necesiten tiempo para adoptarla. La cuestión de gobernanza empieza después. Mientras el método anterior siga admitido, ya no se trata solo de un cambio de código: es un acuerdo operativo entre ARIN y las organizaciones cuyos scripts, plataformas de automatización y proveedores llaman al registro.

Por qué importa dónde viaja la clave

Una clave API no es un dato ordinario de la solicitud. ARIN la describe como un secreto que identifica al usuario y señala que algunas operaciones REST requieren que la cuenta esté vinculada a un Point of Contact con la autoridad pertinente. Cuando el token aparece en la cadena de consulta, viaja junto con la dirección del recurso. Los sistemas que conservan o copian URL pueden mantenerlo después de que termine el proceso que hizo la llamada. El historial del navegador y los registros de servidores y proxies que menciona ARIN describen ese mecanismo de retención accidental.

El método con encabezado cambia dónde coloca el cliente la credencial, no qué recurso solicita. El formato que documenta ARIN usa el campo Authorization y el esquema ApiKey. El cliente, la herramienta de automatización o el servicio de aprovisionamiento debe enviar ese campo de forma consistente sin alterar el punto de conexión ni el sentido de la solicitud. Así, la URL ya no necesita incluir el secreto como parámetro adicional.

Existe un paralelo útil con un límite importante. El RFC 6750 de la IETF trata de tokens OAuth bearer, no del esquema ApiKey de ARIN. Recomienda el encabezado Authorization y desaconseja colocar esos tokens en parámetros URI, entre otras razones porque es probable que las URL queden registradas. No significa que Reg-RWS use OAuth ni que ese RFC lo regule. Sí muestra que la diferencia de exposición es conocida en HTTP: un valor sensible dentro de un URI tiene más probabilidades de llegar a registros de uso general que una credencial situada en un campo específico de la solicitud.

Un encabezado no es una política de seguridad completa. Un administrador puede registrar todos los encabezados; una herramienta de trazas puede capturarlos; un volcado de depuración puede conservarlos; y un cliente puede volver a poner el secreto en la URL antes de seguir una redirección. Por tanto, migrar a encabezados debe ir acompañado de filtrar los valores de Authorization en los registros, guardar las claves de forma protegida, validar certificados y disponer de una manera de sustituir una clave expuesta. Son controles del operador, no nuevas funciones de ARIN que este artículo atribuya a la organización.

La carga de migración tampoco es igual para todos. Un equipo con un cliente mantenido puede cambiar un campo de configuración y probar algunas llamadas. Un operador con scripts antiguos, software de proveedores, tareas programadas, operaciones externalizadas y cadenas de herramientas distintas para RPKI o IRR tiene que encontrar cada lugar donde se construye la cadena de consulta. El registro no ve ese trabajo salvo que lo mida. Por eso, mantener la compatibilidad no demuestra que un cliente haya escogido el método menos seguro después de conocer la alternativa.

Qué acredita el registro público

Las fuentes sostienen cuatro afirmaciones distintas:

  1. La autenticación por encabezado está disponible para Reg-RWS. La versión de julio y la documentación actual de métodos REST la describen.
  2. ARIN prefiere ese método y recomienda migrar. Así lo indican la explicación técnica de agosto y el resumen de septiembre.
  3. Las llamadas con el token en la URL siguen admitidas según la documentación pública consultada. La respuesta de cierre del 29 de julio lo dice de forma expresa, y la página actual de métodos REST lo repite.
  4. Las fuentes revisadas no publican fecha de retirada, hitos de migración, volumen de llamadas que aún dependen de la URL ni tasa de adopción del encabezado.

La cuarta afirmación tiene un alcance deliberadamente limitado. Significa que esas medidas no aparecen en las fuentes públicas citadas; no demuestra que ARIN carezca de datos internos, de un plan privado o de conversaciones con clientes. Tampoco hay en esas fuentes un incidente de seguridad. La sugerencia de 2022 describe una vía plausible de exposición. Los materiales de 2026 explican por qué ARIN prefiere la alternativa. Ninguno informa que un token haya quedado expuesto ni que se haya producido una acción no autorizada en el registro.

Esta distinción evita dos errores opuestos. Uno sería usar los cuatro años como prueba de fracaso. La sugerencia no fijó un plazo y el registro muestra una alternativa desplegada. El otro sería interpretar el cierre como prueba de que el riesgo ha desaparecido. La respuesta mantiene explícitamente la compatibilidad con la URL, y la recomendación de septiembre habla de retirarla en el futuro, sin fecha. Puede existir una opción más segura mientras sigue activo un camino con más exposición.

La compatibilidad también es un compromiso de servicio

Mantener temporalmente el método anterior suele ser lo responsable. Un corte inmediato puede romper un proceso desatendido pero importante para administrar recursos. El fallo de una tarea automatizada podría retrasar cambios en el registro, operaciones RPKI o IRR, reasignaciones u otras tareas construidas alrededor de Reg-RWS. Las fuentes públicas acreditan esos usos generales, pero no cuantifican el daño de una interrupción concreta. La API del registro forma parte de la infraestructura diaria de los operadores; no es un endpoint de demostración que puedan descartar sin más.

La compatibilidad también tiene costes. Cada formato admitido crea un estado que tienen que entender la documentación, el soporte, quienes mantienen los clientes y quienes los usan. Si se recomienda un método mientras otro sigue funcionando sin plazo, «preferido» puede convertirse en una instrucción sin fecha de decisión. Las nuevas integraciones pueden copiar ejemplos antiguos; los scripts inactivos pueden no revisarse nunca; y una auditoría interna puede dar el asunto por resuelto solo porque existe la opción del encabezado.

La respuesta no es suponer que ARIN deba publicar datos de uso identificables, que podrían ser sensibles. Una transición puede hacerse visible sin revelar identidades ni secretos. Como mínimo, ARIN podría describir las fases que prevé, el hecho que pondría en marcha el calendario de retirada, el preaviso que dará, cómo anunciará los cambios de compatibilidad y qué evidencia justificaría prolongar la ventana. Si todavía no ha fijado una fecha, decirlo claramente ayuda más que obligar a los clientes a deducirla de «algún día».

Las fuentes revisadas no muestran que ARIN se haya comprometido a esos hitos. Son recomendaciones para que una retirada futura resulte previsible, no una descripción de un plan actual. La precisión importa: publicar una fecha crea una obligación. Si ARIN aún no ha tomado esa decisión, el análisis no debe fingir lo contrario.

Una retirada necesita algo más que una nota de versión

Una migración técnicamente completa no consiste solo en que funcione un ejemplo con encabezado. Los operadores necesitan saber qué puntos de conexión y herramientas lo aceptan, si alguna biblioteca tiene incompatibilidades conocidas, qué error aparece si falta el encabezado o está mal formado, y si una llamada puede enviar a la vez el encabezado y el token en la URL. Las guías públicas de ARIN responden a la sintaxis esencial. En lo revisado no hay un inventario público por cliente ni un panel de adopción.

Un panel no tendría que identificar clientes. Las cifras agregadas pueden mostrar si las llamadas con encabezado sustituyen a las que usan el parámetro de URL, si queda una cola larga y si la migración se concentra en unas pocas integraciones. Un aviso de retirada podría asociar esas señales a fechas: anuncio, cese de nuevos ejemplos con URL, periodo de advertencia, revisión final de compatibilidad y ventana propuesta de retirada. Si no es posible publicar una medida sin revelar datos operativos, ARIN podría publicar los criterios de decisión e indicar si cada fase se ha cumplido.

Para los clientes, esperar a que exista una fecha universal no es una estrategia de seguridad. La recomendación ya es clara: quitar la clave API de las URL cuando el cliente admita autenticación por encabezado. Los equipos pueden buscar cómo se construyen las cadenas de consulta en código y configuración, actualizar primero las bibliotecas compartidas, comprobar que los registros y las trazas redactan Authorization, probar operaciones representativas conforme a sus propios controles de cambio y reemplazar las claves expuestas. Esas medidas convienen independientemente de la fecha de retirada.

La migración debe probarse; no basta con cambiar una cadena y suponer que todos los clientes se comportan igual.

El registro tampoco debería convertir el plazo final en una sorpresa. Un proceso escalonado da tiempo para localizar clientes que el operador no mantiene, contactar proveedores, actualizar procedimientos y validar la supervisión. Los avisos pueden preceder al rechazo; el rechazo puede esperar a un hito posterior; un proceso de excepción documentado puede gestionar una dependencia real sin perpetuar silenciosamente una vía provisional. Las fuentes no indican que ARIN haya elegido estos controles. Son componentes habituales cuando los efectos de compatibilidad alcanzan más allá de la organización que despliega el cambio.

Qué significa «cerrada»

La sugerencia de 2022 pedía una manera más segura de autenticar llamadas REST. ARIN la ofreció y cerró el expediente. En ese sentido acotado, el estado es correcto. Pero el estado de seguimiento no mide una migración. Indica que se implementó la alternativa solicitada; no responde cuántos clientes siguen usando el formato anterior, cuánto aviso recibirán ni cuándo terminará la compatibilidad.

Para los clientes de ARIN, la conclusión práctica es sencilla: usar el encabezado en clientes nuevos y mantenidos, y tratar la compatibilidad con URL como tal, no como una opción de seguridad equivalente. Para ARIN, la tarea de gobernanza pendiente es hacer que la retirada futura sea lo bastante legible para convertir una recomendación en una migración coordinada. Las fuentes no justifican afirmar que hubo una filtración ni atribuir culpa. Sí justifican preguntar qué señal pública marcará el comienzo del segundo calendario.

Fuentes