Resumen

  • El autor de ACSP 2026.4 dijo que, tras crear una Detailed Reassignment para otra Org, la clave API del registrante directo no podía hacer GET del NET hijo por handle. Según su relato, sí podía borrarlo, recuperarlo con mostSpecificNet si conocía el inicio y el fin exactos y encontrar datos públicos en Whois.
  • ARIN cerró la sugerencia el 30 de marzo de 2026. Explicó que había considerado otras herramientas de recuperación y planes de desarrollo futuros, y que un cambio de permisos no era necesario en ese momento. La respuesta no reproduce ni confirma cada resultado reportado.
  • La asimetría tiene una defensa seria: recuperar una asignación no es administrar los campos de la Org destinataria; Whois/RDAP no equivale al NET Payload autenticado; y conceder PUT general al padre erosionaría la finalidad de una reasignación detallada.
  • La carencia operativa puede resolverse con menos privilegio, no con más: una consulta previa que muestre identidad estable, relación directa, descendientes, efectos, vía de ticket y versión, más una matriz pública de capacidades por actor y ruta.

La interfaz humana ya contiene la intuición correcta. Las instrucciones de ARIN para eliminar una reasignación conducen al usuario hasta una red concreta, le piden seleccionar su Net Handle y le hacen confirmar que la acción no puede deshacerse. El acto destructivo debe estar unido a un objeto reconocible.

En una automatización, esa unión no puede depender solo de lo que la base local recordaba cuando se programó el trabajo. El registro puede haber cambiado; una red puede haber adquirido hijos; una relación puede haber sido corregida. Hace falta observar el estado autoritativo cerca del momento de compromiso.

Eso es lo que vuelve interesante a la sugerencia ACSP 2026.4. No porque pruebe un fallo de seguridad —no lo hace—, sino porque coloca el derecho de recuperación y la observabilidad previa en rutas distintas.

Lo que el proponente dijo haber visto

La sugerencia fue presentada el 3 de marzo de 2026. Su autor describió una Detailed Reassignment desde un NET propio hacia otra Org. Al intentar recuperar el nuevo NET mediante su handle, la clave API del padre recibió, según el texto, una denegación por falta de permiso. La clave de la Org receptora sí podía ejecutar ese GET.

El autor añadió tres observaciones. La entidad de origen podía DELETE el NET. Podía obtener un NET Payload a través de mostSpecificNet al suministrar el principio y el final exactos del bloque. Y podía consultar la información pública por handle o dirección IP en Whois. A partir de ahí, pidió que el padre pudiera hacer GET y también PUT, porque eliminar y recrear le permitiría obtener un efecto parecido.

ARIN respondió el 30 de marzo. Tras discutir métodos alternativos para recuperar la información mediante herramientas existentes y considerar planes futuros, concluyó que cambiar los controles de permiso no era necesario en ese momento. El expediente quedó Closed con el acuerdo del proponente.

Los límites probatorios importan. La página oficial conserva el relato y la respuesta, pero no es una prueba independiente. ARIN no dice que haya reproducido cada paso. Tampoco hay un borrado incorrecto, una exposición de datos, una interrupción o un exploit documentados. La documentación vigente permite estudiar las formas del contrato; no demuestra que el comportamiento persista para toda cuenta y objeto.

La alternativa exacta presupone un inventario exacto

El catálogo de métodos Reg-RWS define GET /rest/net/NETHANDLE, DELETE /rest/net/NETHANDLE, PUT /rest/net/NETHANDLE y GET /rest/net/mostSpecificNet/STARTIP/ENDIP. Los GET devuelven NET Payload. DELETE devuelve una Ticketed Request Payload. PUT recibe y devuelve un NET Payload.

Cada ruta exige que el cliente sepa algo diferente. El handle nombra al objeto como identidad registral. La consulta de rango requiere conocer de antemano ambos límites. Whois/RDAP ofrece una superficie pública, no necesariamente la misma carga de aprovisionamiento ni los mismos campos privados.

El expediente ACSP 2023.13 muestra por qué la distinción tiene consecuencias. Una llamada mostSpecificNet de rango exacto no sirve para comenzar con cualquier IP contenida y descubrir cómodamente el objeto. Hay que poseer inicio y final correctos. Por eso la ruta alternativa funciona bien cuando el inventario local ya coincide con ARIN y peor precisamente cuando se necesita reconciliar una discrepancia.

Una organización puede guardar tanto el handle como la red. Pero el control no debe basarse en que ambos campos siempre envejecen juntos. Si el handle GET está restringido y el rango exacto es el único camino API disponible al padre, el proceso corre el riesgo de preguntar al registro solo aquello que su propia memoria ya ha decidido.

Por qué la separación de poderes merece protección

La guía de administración de recursos distingue tres relaciones. En una reasignación simple, el cliente no administra directamente el registro. En una Detailed Reassignment, una Org receptora obtiene autoridad de gestión; el registrante directo conserva autoridad de reclaim. En una reallocation, la receptora puede volver a asignar o reasignar. Algunas funciones de DNS inverso e IRR se distribuyen entre las partes.

Esta arquitectura explica por qué la lógica “si puede borrar, puede leer y modificar todo” es demasiado gruesa. El derecho del padre es terminar una relación sobre recursos cuya responsabilidad conserva. El derecho del destinatario es gestionar los detalles de la relación mientras existe. Son propósitos distintos.

También lo son sus datos. El NET Payload incluye más que lo visible en un directorio: versión, comentarios, fecha, Org o customer handle, red, padre, nombre, origin AS y vínculos POC. Varios campos jerárquicos no pueden cambiarse en un PUT. Que un dato público pueda localizarse por Whois no autoriza a equiparar ambas representaciones.

Por tanto, una política no tiene por qué ser monotónica. DELETE no implica universalmente GET; GET no implica PUT. La Org receptora no debe perder privacidad y autonomía solo para simplificar un script del padre.

Pero esa conclusión tampoco legitima un DELETE ciego. Menor privilegio significa ajustar datos y acción a una finalidad. Para reclamar con seguridad, la finalidad necesita menos campos que una administración completa, pero necesita algunos.

El momento peligroso está entre seleccionar y confirmar

ARIN dice que DELETE solo se aplica a reasignaciones o reallocations. Si el NET no tiene redes hijas, la solicitud puede procesarse automáticamente y la respuesta incluirá detalles del objeto eliminado. Si hay redes anidadas, se crea un ticket; hay que esperar a su resolución antes de reutilizar el espacio.

El sistema ya considera que la topología descendente cambia el significado del acto. Sin hijos, la consecuencia puede ser inmediata. Con hijos, hay revisión. La pregunta es cómo conoce el operador esa diferencia antes de enviar la acción, especialmente cuando su propia vista puede estar desactualizada.

La guía de modificación de NET recomienda obtener primero el NET actual con GET. Es una regla de concurrencia razonable: no modificar un objeto viejo. Para el actor que puede recuperar pero no debe recibir la carga completa, se necesita un equivalente reducido.

Podría llamarse vista previa de reclaim. No tendría comentarios privados ni POC protegidos. Devolvería únicamente:

  1. handle estable y rango normalizado;
  2. clase de objeto y relación de hijo directo;
  3. tipo de destinatario sin identidad de contacto sensible;
  4. presencia de NET descendientes;
  5. resultado previsto, automático o ticketed;
  6. resumen de dependencias DNS, IRR y de objetos de enrutamiento;
  7. alcance de notificaciones y evidencia de auditoría;
  8. token de versión de corta duración.

El DELETE posterior incluiría el token. Si la jerarquía, el rango o una dependencia material cambian, ARIN rechazaría la operación y exigiría una nueva vista. La capacidad de reclaim seguiría acotada. La Org receptora seguiría controlando sus detalles. Lo que desaparece es la distancia entre el estado revisado y el estado eliminado.

Una matriz para dejar de aprender mediante errores

La documentación pública debería convertir las decisiones implícitas en un objeto versionado. Su unidad sería:

rol del actor × relación × clase de NET × ruta de identificador × verbo × campos × precondición × resultado

La matriz separaría reasignación simple, detallada y reallocation; padre directo y descendiente; administrador de Org y POC; handle, rango exacto y directorio público; payload completo, público y recortado; respuesta automática y ticket. Indicaría los campos inmutables y la vía segura de corrección.

No se trata de exigir igualdad. Una celda puede negar el payload completo al padre y permitir una vista de reclaim. Otra puede permitir a la Org receptora leer y modificar los campos que administra. La utilidad está en que cada diferencia sea intencional, explicada y comprobable.

Los operadores podrían convertir la matriz en pruebas de contrato. Antes de desplegar, comprobarían que la cuenta, la clase de objeto y la ruta dan el resultado esperado. Un error dejaría de ser solo “no autorizado” para señalar si la causa es rol equivocado, relación indirecta, identificador incompatible, campo protegido o versión caducada.

Closed pertenece al flujo de sugerencias

ARIN tenía derecho a decidir que las herramientas existentes bastaban y que otro desarrollo podía esperar. El proponente aceptó el cierre. Nada obliga a transformar cada sugerencia en un cambio de producto.

Lo que no debe hacerse es convertir ese estado administrativo en una afirmación técnica más amplia. Closed no significa que ARIN confirmara cada paso, que implementara un arreglo o que la pregunta operativa haya quedado resuelta para siempre. “Innecesario en ese momento” conserva espacio para que un contrato futuro cambie.

Si la política pretendida es que el padre pueda recuperar pero no leer la carga completa por handle, debe publicarse así. Si la consulta por rango o ARIN Online es la comprobación recomendada, hay que declarar qué inventario presupone y qué identidad confirma. Si un desarrollo futuro va a unificar la resolución, debe llegar con versión, fecha y migración.

Las fronteras más sólidas no son las que más niegan. Son las que permiten saber por qué una acción está permitida, qué estado se verificó y qué información quedó deliberadamente fuera. Antes de una eliminación, esa explicación debe existir todavía a tiempo para detenerla.