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