Resumen

  • El borrador individual del 28 de octubre propone client_ip_ranges, una lista directa de prefijos IPv4/IPv6, y client_ip_ranges_uri, la dirección HTTPS de un documento JSON. Son opciones excluyentes. Registrar o descargar la declaración no equivale a aceptar sus rangos.
  • Una descarga fallida, un documento inválido o la retirada de la declaración no pueden ampliar por sí solos el acceso. El servidor puede conservar la lista aceptada, recortarla a la intersección con una sustituta y ponerle fecha de vencimiento. Una vez vencida, quien aplicaba la restricción debe rechazar al cliente hasta aceptar una lista actual o retirar expresamente el control.

La IP nueva espera su turno

Una empresa traslada su cliente OAuth a otra salida de nube. Publica el documento y recibe una respuesta HTTP correcta. El servidor que entrega tokens aún reconoce las direcciones antiguas. Según el texto propuesto, la llegada del archivo no obliga a abrir la puerta a las nuevas IP. El servidor valida el conjunto completo y decide si lo acepta bajo su política. Una ampliación sorpresiva puede esperar aprobación.

Hay dos formas de declarar la procedencia: prefijos en el propio metadato o una URL HTTPS que devuelva el documento. No se pueden presentar ambas. Si no hay ninguno de los dos campos, el cliente no declara rango; si publica una matriz vacía, declara un conjunto vacío. Frente a las reglas de actualización de la RFC 7592, el borrador exige tratar esa matriz vacía como declaración, no como borrado del campo. Un conjunto vacío aceptado cierra el paso a todas las IP.

La aceptación sustituye la lista anterior entera; no existe un formato incremental. Si una lista nueva ya es válida pero todavía no está aprobada, el servidor puede limitar la antigua a la intersección de ambas. Así retira una salida vieja sin conceder todavía la nueva. El cliente debería anunciar la IP futura antes de empezar a usarla y conservar la anterior mientras siga enviando peticiones desde ella. Los intervalos de descarga y la demora de aprobación importan tanto como el cambio de configuración.

El fallo del archivo tiene una regla de hierro: no puede convertir una IP rechazada en admitida. Lo mismo ocurre si el cliente retira los dos metadatos. Levantar la restricción después de esa retirada requiere una decisión local explícita. El servidor debería fijar cuánto tiempo mantiene la lista aceptada durante un error, una retirada o una sustitución pendiente. Agotado ese plazo, el servidor que la aplicaba rechaza las peticiones hasta aceptar un conjunto bajo la declaración vigente o decidir expresamente que deja de aplicar el filtro. Volver a validar una sustitución sin aprobar no reinicia el plazo.

Conservar por demasiado tiempo también cuesta. La dirección abandonada puede acabar en manos de otro. La intersección y el límite temporal reducen el periodo en que una IP antigua conserva paso. La RFC 9111 explica la caché HTTP, pero el borrador mantiene separada la lista aceptada: un 304 Not Modified no es una nueva aprobación y el vencimiento de la caché no retira automáticamente el permiso.

El filtro tampoco demuestra identidad. Un cortafuegos anterior al endpoint ve direcciones de origen, no qué cliente OAuth hizo la petición; solo puede aplicar el agregado de rangos. El servidor puede imponer la regla de cada cliente después de identificarlo. Una declaración firmada que contiene la URL avala la URL, no cada versión futura del documento alojado allí. Su anfitrión puede dejar al cliente sin servicio publicando una lista vacía o dejando el documento inaccesible hasta agotar la retención.

El registro IETF muestra una propuesta individual, sin resultado de despliegue. La prueba de una mudanza real tendría que mostrar qué versión se descargó, qué lista se aceptó, quién aprobó la ampliación y cuándo dejó de valer la antigua.

Fuentes: borrador; estado IETF; RFC 7592; RFC 9111.