On Mar 3, 2025, at 10:29 AM, Michal Moravec <michal.moravec@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.