Resumen

  • El borrador RadSec bis, revisión 18, limita la prueba de disponibilidad al par y a la conexión observados; un proxy RADIUS no revela el estado de los dominios que enruta aguas abajo.
  • La operación segura necesita unir el watchdog con el realm, la ruta, el servidor de origen, el propietario del reintento, la decisión de autorización y el resultado aplicado.

Un controlador de acceso mantiene dos conexiones TLS con un proxy de federación. En ambas se validó el certificado y el transporte sigue abierto. Las solicitudes de ocho dominios reciben respuesta. Las del noveno quedan pendientes. Si el cuadro de mando agrega por dirección del proxy, mostrará éxito. Si agrega por servicio solicitado, mostrará una interrupción.

La diferencia no es cosmética. Determina qué tráfico se mueve, quién debe intervenir y qué evidencia autoriza la acción.

RADIUS delega por saltos. El equipo de acceso no conversa necesariamente con el servidor que conoce al usuario. Entrega el paquete a un proxy; este interpreta el realm, elige un siguiente destino y puede atravesar otros intermediarios antes de llegar al servidor de origen o a su almacén de credenciales. Cada proxy es servidor para el vecino anterior y cliente para el siguiente. El primero puede estar perfectamente operativo mientras una sola rama del grafo ha dejado de responder.

La sección 3.8 de draft-ietf-radext-radiusdtls-bis-18 reconoce esta opacidad. El cliente RadSec debe evaluar la conexión TCP, TLS o DTLS y también el watchdog de la capa de aplicación definido por RFC 3539. Solo marca la conexión como caída cuando la pila de red ya no la considera viable, cuando D(TLS) no ofrece una conexión utilizable o cuando el watchdog la declara caída. La comprobación se hace por conexión; un fallo no permite retirar todas las conexiones al mismo servidor.

El lenguaje protege la disponibilidad porque no convierte una anomalía local en un veredicto global. Pero también expone el límite inverso. Que una conexión siga arriba no dice si el proxy conserva una ruta correcta para cada dominio, si la siguiente red está accesible, si el servidor de origen está saturado o si un backend concreto puede consultar sus datos.

Status-Server tiene precisamente ese alcance. RFC 5997 ordena que un servidor o proxy no reenvíe la solicitud. Responde el destino interrogado, no una cadena completa. Como la consulta no usa el nombre de usuario para llegar a un realm, su resultado no permite inferir la accesibilidad de ese realm. El watchdog elimina una ambigüedad —distingue al primer salto de lo que hay detrás— sin fingir que observa lo que no atraviesa.

La revisión 18 exige esta extensión en clientes y servidores RadSec. Recomienda apartar el Identifier cero para el watchdog, dado que cada conexión solo dispone de 256 valores simultáneos. Los keepalives de TCP y los latidos de DTLS pueden detectar antes una rotura de transporte. Todos esos instrumentos responden a una pregunta legítima: ¿sigue disponible este canal hacia este par? Ninguno responde: ¿podrá este abonado terminar la autenticación?

Confundir las preguntas conduce a dos automatismos peligrosos. El primero retira el proxy completo cuando una solicitud de un realm expira. El resto de los dominios migra sin necesidad; el servidor secundario recibe una avalancha y la reconexión introduce más trabajo. La ausencia de una respuesta remota se transforma en una falsa caída local. RFC 3539 explica que un cliente situado antes de un agente no puede deducir los parámetros de transporte extremo a extremo que justificarían ese temporizador.

El segundo automatismo hace lo contrario. Mientras Status-Server conteste, mantiene la ruta rota para el realm afectado. La sonda dice la verdad, pero el sistema la usa como mandato fuera de su jurisdicción. Hace falta una observación ligada a la selección del realm: qué regla se aplicó, qué siguiente salto recibió la solicitud, qué contestó el servidor de origen, qué hizo el almacén de credenciales y qué instrucción ejecutó el NAS.

La nueva respuesta Protocol-Error conserva la misma disciplina. Sirve para un paquete no deseado en el salto actual, no se reenvía y puede detener los reintentos sobre esa conexión. Su recepción permite buscar otra ruta. No confirma que un destino posterior acepte el paquete ni que el usuario obtenga servicio.

La protección criptográfica tampoco crea visibilidad extremo a extremo. TLS o DTLS autentica al par contiguo y protege ese tramo. El borrador advierte que un proxy puede entregar el mismo paquete por RADIUS/UDP en el siguiente salto. El cliente original no puede imponer desde el protocolo que toda la cadena use un transporte seguro. Si la organización exige esa propiedad, debe controlar la configuración de los intermediarios. Un primer tramo cifrado no convierte el grafo oculto en una sola sesión.

Los reintentos muestran otra frontera de control. Sobre TCP o TLS, RADIUS se apoya en un transporte fiable y no retransmite el paquete en esa conexión. UDP y DTLS necesitan retransmisión de aplicación. Cuando un proxy recibe por un medio no fiable y envía por uno fiable, no debe propagar de nuevo las copias que llegan. Cuando recibe por el medio fiable y sale por el no fiable, asume el temporizador y la retransmisión. Si la conexión de entrada se cierra o el cliente reutiliza el Identifier, tiene que abandonar las copias pendientes del intento anterior.

Por eso un tiempo de espera no identifica por sí solo al responsable. Puede haber expirado el cliente mientras el proxy conserva estado. Puede estar vivo el proxy y bloqueado el home server. Puede haber procesado el servidor una solicitud cuya respuesta aún viaja. La corrección exige registrar quién era dueño del reintento en cada frontera.

El atributo contable aporta un caso concreto. La revisión 18 recomienda un Event-Timestamp fijo que nombra el instante real del evento. No debe modificarse al retransmitir. En cambio, actualizar Acct-Delay-Time genera un paquete nuevo con información casi idéntica y quizá un Identifier nuevo. Si un proxy pasa de TLS a UDP, puede abrir una serie independiente de reintentos por cada versión mientras el servidor lento ya procesa la primera. El apéndice A.2 ilustra la multiplicación con los ID 101, 102 y 103.

Mantener la hora del evento ayuda a detectar duplicados, pero no ofrece una clave universal ni garantiza que una operación de negocio ocurra una sola vez. El comprobante necesita evento, identidad del paquete, salto, temporizador, resultado del servidor y efecto posterior.

Incluso una validación criptográfica fallida puede pertenecer a una carrera y no a un ataque. El apéndice A.1 describe la reutilización de un Identifier tras un timeout. Una respuesta tardía de la solicitud antigua llega cuando el cliente ya conserva la nueva; el Response Authenticator no coincide. Se descarta ese paquete, pero se mantiene la conexión. El fallo de un mensaje, la caída de un canal y la mala conducta del par no son sinónimos.

La revisión 18 se publicó como Internet-Draft activo el 30 de septiembre de 2026, pretende llegar a Proposed Standard y expira el 3 de abril de 2027. Todavía no es RFC. Solo una futura aprobación y publicación haría efectivo su reemplazo de los RFC experimentales 6614 y 7360. El expediente no demuestra adopción, interoperabilidad ni un incidente de ninguna red concreta.

La afirmación operacional correcta es deliberadamente limitada: este par RadSec respondió por esta conexión a esta hora. Para afirmar disponibilidad de acceso se añaden el realm, la ruta, la dependencia final, la autorización, la ejecución del NAS y el resultado observado. La coordinación común funciona cuando conserva esas fronteras, no cuando un indicador ocupa todos los niveles de realidad.

Fuentes