RADSEC keep TLS connections open with keep-alive
Alan DeKok
aland at deployingradius.com
Mon Mar 3 17:02:16 UTC 2025
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.
More information about the Freeradius-Users
mailing list