Resumen

  • La revisión 18 del Internet-Draft de RadSec exige al cliente descartar una respuesta cuyo Response Authenticator no valide, pero conservar la conexión (D)TLS. También impone conservarla si no hay una solicitud pendiente que corresponda a la respuesta. Sigue siendo un texto del grupo RADEXT en evaluación del IESG, no un RFC aprobado.
  • La nueva explicación se centra en el tiempo: tras agotar la espera, el cliente puede reasignar el Identifier de un octeto; entonces llega la respuesta a la solicitud anterior y falla la comprobación contra la nueva. La regla no acepta ese paquete ni elimina la obligación de cerrar cuando falle un Message-Authenticator pertinente.

Una respuesta no lleva una etiqueta temporal que diga «pertenezco a la solicitud que ya expiró». El cliente conoce el Identifier y su tabla actual de solicitudes. Si el número se ha vuelto a usar, una contestación rezagada puede encontrarse con una entrada distinta de la que motivó su envío. El Response Authenticator no encaja. En ese instante hay una decisión operativa: invalidar el paquete, o convertirlo además en una caída de toda la conexión RadSec.

El texto del 30 de septiembre elige la primera consecuencia para ese supuesto. Su sección 3.12 pasa el fallo de Response Authenticator a una categoría con dos mandatos simultáneos: descartar la respuesta y mantener abierta la conexión. A las respuestas sin solicitud pendiente les da la misma salida. En la revisión 17, el fallo del autenticador estaba en la lista que cerraba la conexión, mientras que para una respuesta huérfana se dejaba abierta la elección de cerrar o no. La nueva sección A.1 detalla la carrera entre la respuesta antigua y la reutilización del Identifier.

No es una licencia para responder «aceptado» ante un dato que no pasó la verificación.

La diferencia respecto del RFC 6613 es precisa. En RADIUS/TCP, aquel texto exigía cerrar TCP ante un Response Authenticator inválido y dejaba la respuesta no emparejada a criterio de la implementación. El Identifier ocupa un octeto y permite 256 valores en una conexión. Bajo carga, un cliente puede agotar la espera de una solicitud y volver a usar pronto su número. El servidor responde a la antigua justo antes de ver la nueva; el cliente ya no dispone del contexto original y la comparación falla. Los intermediarios con temporizadores distintos añaden otra vía para que llegue un paquete cuando nadie lo espera.

El borrador describe mecanismos posibles, no un fallo constatado en una red concreta.

La frontera de seguridad no desaparece. El paquete con Response Authenticator inválido queda fuera. El borrador explica que, una vez descartado por ese motivo, inspeccionar también su Message-Authenticator no cambia la decisión. Pero si la solicitud se identifica correctamente y el Message-Authenticator de la respuesta falla, la conexión debe cerrarse. Cuando el servidor considera inaceptable al cliente, debe terminar inmediatamente (D)TLS; RADIUS/TLS también cierra TCP. Mezclar todos esos casos bajo la misma alarma de «autenticación fallida» oscurecería justo la distinción que la revisión intenta fijar.

La prueba útil no consiste sólo en mirar que la sesión siga levantada. Debe demostrar que la respuesta tardía fue eliminada, que la asociación con la solicitud nueva no produjo una aceptación espuria y que una transacción válida posterior pudo continuar. Hay que conservar la causa de descarte, la etapa de validación y el número de paquete sin inundar el sistema de registros. La propia propuesta pide limitar la tasa de anotaciones para paquetes ignorados cuando no se cierra la conexión. Este desglose de pruebas es una recomendación editorial para la operación, no una especificación nueva de telemetría.

Datatracker mantiene la revisión 18 como Internet-Draft activo del grupo RADEXT, enviado para publicación y en IESG Evaluation::AD Followup. Aspira a Proposed Standard. Sólo si se aprueba sustituiría los RFC 6614 y 7360; no hay aprobación final en la fuente consultada. La innovación que importa al operador es pequeña pero decisiva: una respuesta puede merecer el rechazo sin que ese mismo hecho condene a todos los intercambios que comparten la conexión.

Fuentes