RADSEC keep TLS connections open with keep-alive

[Michal Moravec]

Hey Alan,

> On 20. 2. 2025, at 17:10, Alan DeKok <aland at 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 at deployingradius.com> wrote:
> 
> On Feb 20, 2025, at 10:34 AM, Michal Moravec <michal.moravec at 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