Re: RADSEC keep TLS connections open with keep-alive
Alan DeKok <[email protected]>
| Newsgroups | gmane.comp.freeradius.user |
|---|---|
| Message-ID | <[email protected]> |
On Mar 3, 2025, at 10:29 AM, Michal Moravec <[email protected]> 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