Resumen

  • Con Service-Type Authorize Only, el NAS nunca debe responder CoA-ACK: si acepta iniciar la operación, devuelve CoA-NAK con Error-Cause 507 y origina un Access-Request.
  • La respuesta RADIUS conserva significado preciso, pero no sustituye los comprobantes anteriores y posteriores: autorización del emisor, conjunto de sesiones, estado del NAS, contabilidad y tráfico.

Un sistema de operaciones que convierte ACK en verde y NAK en rojo parece claro hasta que el estándar usa un NAK para informar que el siguiente paso comenzó correctamente. No es una excepción ornamental. Es una advertencia sobre el modelo de datos: los nombres de las clases no contienen todo el resultado.

RFC 5176 permite cambiar o terminar una sesión después de la autorización inicial. Una Disconnect-Request pide eliminar contexto de sesión. Una CoA-Request modifica la autorización activa. Ambas llegan a una superficie en la que el NAS tiene que reconocer al solicitante, decidir si puede obedecerle, encontrar el estado correspondiente y efectuar una transición coherente.

El 507 es un puente, no un veredicto

Authorize Only no lleva en la propia CoA la decisión final. Cuando el NAS acepta iniciar una nueva consulta de autorización, responde CoA-NAK con Request Initiated, código 507. A continuación envía un Access-Request. Solo el Access-Accept o Access-Reject posterior resuelve la política solicitada.

Registrar el NAK sin el 507 produce un falso fracaso. Registrar el 507 como éxito definitivo produce una falsa conclusión. La información completa es una relación entre dos intercambios: la primera respuesta confirma el inicio y el segundo diálogo decide el estado.

La misma necesidad de contexto aparece en el resto del registro Error-Cause. Session Context Not Found describe una ausencia de estado; Administratively Prohibited, una decisión de autoridad; Request Not Routable, un límite del proxy; Resources Unavailable, una incapacidad temporal; Multiple Session Selection Unsupported, un problema de cardinalidad. Agruparlos como “fallo CoA” oculta dónde debe actuar el operador.

Los errata verificados corrigen además intuiciones simplistas: los valores exitosos del rango 200 no están encerrados exclusivamente en ACK, y Error-Cause también puede aparecer en respuestas ACK. El parseo correcto exige conservar la combinación, no deducirla por el nombre del paquete.

Antes de responder, el NAS tuvo que elegir

Una petición puede incluir User-Name, NAS-Port, Framed-IP-Address, Calling-Station-Id, Acct-Session-Id, Chargeable-User-Identity y otros atributos admitidos. Esos datos forman un selector. Puede no encontrar nada, encontrar una sesión o encontrar varias.

Si aparecen varias coincidencias, RFC 5176 aplica la orden a todas. La transición debe ser atómica: todos los cambios en todas las sesiones o ninguno. Si el NAS no admite la selección múltiple, devuelve el código 508. La regla impide medias ejecuciones, pero no garantiza que el conjunto coincidente fuera el deseado.

Por eso la autenticidad del paquete no resuelve el riesgo principal. Un mensaje bien protegido puede expresar un selector demasiado amplio. Un ACK posterior puede afirmar honestamente que el NAS cambió todas las sesiones elegidas, aunque el operador solo hubiera imaginado una. El comprobante que falta es el conjunto de coincidencias conservado antes de ejecutar.

El ACK merece crédito, no poderes ilimitados

Disconnect-ACK significa que el NAS afirma haber descartado el contexto y que las sesiones seleccionadas ya no están conectadas. CoA-ACK significa que las modificaciones de autorización se realizaron con éxito. Son afirmaciones de ejecución, no simples recibos de transporte.

Pero toda afirmación tiene un emisor y un campo de visión. El NAS no puede observar automáticamente la réplica de una base de políticas, la liquidación contable, el estado de una pasarela posterior ni la experiencia del usuario. La evidencia operativa añade la tabla de sesiones, los registros Accounting-Stop o Interim y la observación del tráfico. No debilita el ACK; delimita su autoridad.

Un canal seguro no decide quién manda

En el transporte UDP histórico, la dirección de origen selecciona el secreto compartido y el Request Authenticator usa la construcción RADIUS basada en MD5. Event-Timestamp y la detección de retransmisiones/duplicados atienden a la frescura. Aun así, RFC 5176 separa la autenticación de la autorización: en un NAS compartido, un cliente válido de un proveedor no debe modificar usuarios de otro.

RFC 9765 actualiza el panorama con RADIUS/1.1 sobre TLS o DTLS negociado. Allí el canal protegido reemplaza la vieja autenticación de paquete y no se envía Message-Authenticator. La modernización reduce riesgos criptográficos; no crea por sí sola el mandato para modificar cualquier sesión.

El proxy tampoco fusiona niveles. RFC 8559 utiliza Operator-Name y un Operator-NAS-Identifier opaco para devolver la solicitud al NAS correcto. Encontrar el equipo es distinto de encontrar dentro de él el contexto exacto de abonado.

Esta separación encaja con una disciplina más amplia: cada símbolo debe responder solo por la realidad que observó. El cliente responde por la orden, el proxy por el encaminamiento, el NAS por su transición, la contabilidad por sus registros y el tráfico por el efecto. La claridad nace de enlazarlos, no de convertir uno en autoridad universal.

Fuentes