RADSEC keep TLS connections open with keep-alive

[Alan DeKok]

On Mar 3, 2025, at 10:29 AM, Michal Moravec <michal.moravec at macadmin.cz> wrote:
> We have done some light testing and we see the overhead of establishing TCP + TLS connection between NAS and RADIUS server increases the duration of the entire EAP exchange by at least 20%.
> This can affect end user experience. Especially if the RADIUS server is hosted in another country and RTT is not insignificant.

 Good point.  Yes, the extra overhead is pretty bad.

> Do you think it is reasonable to ask vendors about use of Status-Server messages for purpose of maintaining RADSEC connections open?

  Yes.  The RADIUS/TLS RFC is being updated, and the new revision will recommend the use of Status-Server.

> I have read RFC 5997 you happen to be author of. Hats off to you sir! :-)

  Thanks!

> I understand the intent is to check whether the server is available without using Access-Request packet.
> However maintaining connections is not really covered since only UDP transport is considered.
> 
> RFC 6614 mentions "status-server" packets only in "Implementation Overview: Radiator" appendix (an implantation example)

  FreeRADIUS implements it as a keep-alive.

>>> The implementation uses TCP keepalive socket options, but does not send Status-Server packets.  Once established, TLS connections are kept open throughout the server instance lifetime.
> 
> Other solutions I can think off to mitigate the overhead of establishing RADSEC TLS connection:
> 1) Just accept it. Increase is not that bad.
> 2) Deploy RADIUS proxy to the network with NAS devices. RADSEC connection would be established only between the proxy and the RADIUS server. 
>    Aggregating RADIUS traffic from all NAS devices with a reasonable idle timeout set on the RADIUS server (several minutes max) should keep the RADSEC TLS connection open more often than not.

  That should work.  But RADIUS proving is a disaster.  Hence the conference next week, to see what we can do about it.

  Alan DeKok.