RADSEC keep TLS connections open with keep-alive
Hi there, Is it possible to configure FreeRADIUS server not to close TCP/TLS RADSEC connection between NAS and RADIUS server after completing a single request? Some network vendors support sending keep-alive messages through the connection in order to keep it established and re-use it for subsequent requests. I think a possible alternate solution would be to put a load balancer in front of the RADIUS server which would handle the persistent connection. Best, Michal Moravec
On Feb 20, 2025, at 5:58 AM, Michal Moravec <michal.moravec@macadmin.cz> wrote:
Is it possible to configure FreeRADIUS server not to close TCP/TLS RADSEC connection between NAS and RADIUS server after completing a single request?
Huh? The server doesn't do that. If the connection is closed after one request, it's likely that the other end is closing it. As always... *read the debug log* to see what's going on. The messages will tell you if FreeRADIUS closed the connection due to idle timeout, etc., or if the other end closed the connection.
Some network vendors support sending keep-alive messages through the connection in order to keep it established and re-use it for subsequent requests.
This is the Status-Server packet. FreeRADIUS supports this.
I think a possible alternate solution would be to put a load balancer in front of the RADIUS server which would handle the persistent connection.
Or, configure the client to *not* close the connection after every packet. I doubt very much that this is a FreeRADIUS issue. We've done huge amounts of testing with billions of packets. It absolutely does not close the TLS connection after every single packet. Alan DeKok.
Hey Alan,
On 20. 2. 2025, at 13:16, Alan DeKok <aland@deployingradius.com> wrote:
On Feb 20, 2025, at 5:58 AM, Michal Moravec <michal.moravec@macadmin.cz> wrote:
Is it possible to configure FreeRADIUS server not to close TCP/TLS RADSEC connection between NAS and RADIUS server after completing a single request?
Huh? The server doesn't do that.
If the connection is closed after one request, it's likely that the other end is closing it. Thank you for pointing me in the right direction. I read this somewhere and interpreted the situation I saw under a wrong assumption. Sorry! :-)
What actually happened was the server closing the connection after 30 seconds which is the default idle_timeout in both listen and client/limit (<- even when undefined) stanzas in tls (radsec) configuration file. After changing idle_timeout to higher value in both in client/limit and listen stanzas, the server keeps the tcp connection open for defined amount of time.
Some network vendors support sending keep-alive messages through the connection in order to keep it established and re-use it for subsequent requests.
This is the Status-Server packet. FreeRADIUS supports this. In this case the vendor is Cisco Meraki. It seems they don't send "Status-Server". NAS sends TCP keep-alive message (empty TCP header with ACK flag) every 270 seconds until it reaches "RADSec TLS idle timeout" (default 15 minutes) which I interpret as connection being open for X minutes without any actual application-level traffic.
So I tried this: 1. EAP authentication from a client which makes NAS to open the tcp radsec connection to FreeRADIUS 2. RADIUS with idle_timeout = 330 then says "Waking up in 324.8 seconds." 3. Some time after that NAS sends TCP keep-alive 4. RADIUS wakes up as scheduled and closes the connection with "Reached idle timeout on socket auth+acct from client (A.B.C.D, 42471)" I guess the answer is to use higher value for idle_timeout since TCP keep-alive does not seem to affect this? Best, Michal
On Feb 20, 2025, at 10:34 AM, Michal Moravec <michal.moravec@macadmin.cz> wrote:
What actually happened was the server closing the connection after 30 seconds which is the default idle_timeout in both listen and client/limit (<- even when undefined) stanzas in tls (radsec) configuration file. After changing idle_timeout to higher value in both in client/limit and listen stanzas, the server keeps the tcp connection open for defined amount of time.
That's good.
Some network vendors support sending keep-alive messages through the connection in order to keep it established and re-use it for subsequent requests.
This is the Status-Server packet. FreeRADIUS supports this. In this case the vendor is Cisco Meraki. It seems they don't send "Status-Server". NAS sends TCP keep-alive message (empty TCP header with ACK flag) every 270 seconds until it reaches "RADSec TLS idle timeout" (default 15 minutes) which I interpret as connection being open for X minutes without any actual application-level traffic.
Unfortunately those packets ensure that intermediate firewalls don't close the TCP connection. But the application doesn't see those packets.
So I tried this: 1. EAP authentication from a client which makes NAS to open the tcp radsec connection to FreeRADIUS 2. RADIUS with idle_timeout = 330 then says "Waking up in 324.8 seconds." 3. Some time after that NAS sends TCP keep-alive 4. RADIUS wakes up as scheduled and closes the connection with "Reached idle timeout on socket auth+acct from client (A.B.C.D, 42471)"
I guess the answer is to use higher value for idle_timeout since TCP keep-alive does not seem to affect this?
Yes. Though there usually isn't a lot of benefit in keeping connections open for 10+ minutes without any traffic. Alan DeKok.
Hey Alan,
On 20. 2. 2025, at 17:10, Alan DeKok <aland@deployingradius.com> wrote:
Though there usually isn't a lot of benefit in keeping connections open for 10+ minutes without any traffic.
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. Do you think it is reasonable to ask vendors about use of Status-Server messages for purpose of maintaining RADSEC connections open? I have read RFC 5997 you happen to be author of. Hats off to you sir! :-) 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)
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. Best, Michal
On 20. 2. 2025, at 17:10, Alan DeKok <aland@deployingradius.com> wrote:
On Feb 20, 2025, at 10:34 AM, Michal Moravec <michal.moravec@macadmin.cz> wrote:
What actually happened was the server closing the connection after 30 seconds which is the default idle_timeout in both listen and client/limit (<- even when undefined) stanzas in tls (radsec) configuration file. After changing idle_timeout to higher value in both in client/limit and listen stanzas, the server keeps the tcp connection open for defined amount of time.
That's good.
Some network vendors support sending keep-alive messages through the connection in order to keep it established and re-use it for subsequent requests.
This is the Status-Server packet. FreeRADIUS supports this. In this case the vendor is Cisco Meraki. It seems they don't send "Status-Server". NAS sends TCP keep-alive message (empty TCP header with ACK flag) every 270 seconds until it reaches "RADSec TLS idle timeout" (default 15 minutes) which I interpret as connection being open for X minutes without any actual application-level traffic.
Unfortunately those packets ensure that intermediate firewalls don't close the TCP connection. But the application doesn't see those packets.
So I tried this: 1. EAP authentication from a client which makes NAS to open the tcp radsec connection to FreeRADIUS 2. RADIUS with idle_timeout = 330 then says "Waking up in 324.8 seconds." 3. Some time after that NAS sends TCP keep-alive 4. RADIUS wakes up as scheduled and closes the connection with "Reached idle timeout on socket auth+acct from client (A.B.C.D, 42471)"
I guess the answer is to use higher value for idle_timeout since TCP keep-alive does not seem to affect this?
Yes.
Though there usually isn't a lot of benefit in keeping connections open for 10+ minutes without any traffic.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
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.
One day perhaps we’ll define RADIUS over QUIC or god forbid over HTTP(v3). Much closer in cost to straight up unencrypted RADIUS including during TLS setup. Still even if we do it’ll take 10+ years for manufacturers of systems to bother to adopt such a change. A.Winfield From: Freeradius-Users <freeradius-users-bounces+alister.winfield=sky.uk@lists.freeradius.org> on behalf of Alan DeKok <aland@deployingradius.com> Date: Monday, 3 March 2025 at 17:02 To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Subject: [EXTERNAL] Re: RADSEC keep TLS connections open with keep-alive 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. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html -------------------------------------------------------------------- This email is from an external source. Please do not open attachments or click links from an unknown or suspicious origin. Phishing attempts can be reported by using the report message button in Outlook or sending them as an attachment to phishing@sky.uk. Thank you -------------------------------------------------------------------- Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of Sky Limited and Sky International AG and are used under licence. Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075), Sky Subscribers Services Limited (Registration No. 2340150) and Sky CP Limited (Registration No. 9513259) are direct or indirect subsidiaries of Sky Limited (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD
participants (3)
-
Alan DeKok -
Michal Moravec -
Winfield, Alister (Senior Solutions Architect)