Fwd: New Features Development Question
Dear FreeRADIUS developers, I'm evaluating of implementation of the following features in my local copy of FreeRADIUS for the PoC that I'm building locally: * Support of unloading RADIUS/EAP/TLS state to external DB (e.g. Redis) at the end of every RADIUS request processing and locating and loading the state back from the external DB to the application when the next request RADIUS of the same RADIUS session comes. This would be extremely helpful for building scalable clusters of stateless FreeRADIUS servers (I need it for my PoC) * Support of external generic CA and CTL for certificate based user authentications * Support of configurable debug and audit log to external loggers Are FreeRADIUS leads and the community interested in my contribution of any of these feature to FreeRADIUS? Thanks Oleg Pekar
On May 11, 2020, at 8:38 AM, Oleg Pekar <oleg.pekar.2017@gmail.com> wrote:
Dear FreeRADIUS developers, I'm evaluating of implementation of the following features in my local copy of FreeRADIUS for the PoC that I'm building locally:
Which version is this for? We're trying to do major new features only in v4. However, that's taking longer than expected. So we're OK with minor code changes to v3. But that work cannot involve major code changes. We just don't have the bandwidth to support multiple releases.
* Support of unloading RADIUS/EAP/TLS state to external DB (e.g. Redis) at the end of every RADIUS request processing and locating and loading the state back from the external DB to the application when the next request RADIUS of the same RADIUS session comes. This would be extremely helpful for building scalable clusters of stateless FreeRADIUS servers (I need it for my PoC)
IIRC, that's already supported in v4. I'll check with Arran, as he added that feature.
* Support of external generic CA and CTL for certificate based user authentications
I'm not sure what that means. "generic CAs" ?
* Support of configurable debug and audit log to external loggers
We have a plan for that in v4. But even there, it involves some fairly serious changes, even if they are largely of the form "change A to B".
Are FreeRADIUS leads and the community interested in my contribution of any of these feature to FreeRADIUS?
We're always interested in new features and contributions. My $0.02 would be to open up 3 GitHub issues, one for each topic. Then describe what you plan to do, and how you plan to do it. We can discuss the changes and see if they can be done in v3. If it works, we can pull the changes into the main release of v3. We *don't* want multiple different versions of v3 floating around, each with different features. We've seen at least one company heavily modify version 1.1.4. And then 10+ years later, they're stuck with it. They don't get the benefit of any of the new features. And end up re-implementing the features themselves. So *small* changes are likely OK for v3. Large rearchitecture will have to wait for v4. Alan DeKok.
On May 11, 2020, at 8:26 AM, Alan DeKok <aland@deployingradius.com> wrote:
On May 11, 2020, at 8:38 AM, Oleg Pekar <oleg.pekar.2017@gmail.com> wrote:
Dear FreeRADIUS developers, I'm evaluating of implementation of the following features in my local copy of FreeRADIUS for the PoC that I'm building locally:
Which version is this for?
We're trying to do major new features only in v4. However, that's taking longer than expected. So we're OK with minor code changes to v3. But that work cannot involve major code changes. We just don't have the bandwidth to support multiple releases.
* Support of unloading RADIUS/EAP/TLS state to external DB (e.g. Redis) at the end of every RADIUS request processing and locating and loading the state back from the external DB to the application when the next request RADIUS of the same RADIUS session comes. This would be extremely helpful for building scalable clusters of stateless FreeRADIUS servers (I need it for my PoC)
IIRC, that's already supported in v4. I'll check with Arran, as he added that feature.
It's unclear, he may be talking about spreading TLS based EAP methods across multiple FreeRADIUS instances instead of doing session resumption. If it's session resumption that's already supported in v4.
* Support of external generic CA and CTL for certificate based user authentications
I'm not sure what that means. "generic CAs" ?
Yeah no idea either.
* Support of configurable debug and audit log to external loggers
We have a plan for that in v4. But even there, it involves some fairly serious changes, even if they are largely of the form "change A to B".
See rlm_logtee in v4. It's already there. -Arran
hi,
It's unclear, he may be talking about spreading TLS based EAP methods across multiple FreeRADIUS instances instead of doing session resumption.
thats how I read it - all servers use a state value stored in a REDIS (could be others such as memcache) so that the ongoing session is known as doesnt have to go back to the same server in a cluster (I've recently done the same with a SAML setup)
* Support of external generic CA and CTL for certificate based user authentications
I'm not sure what that means. "generic CAs" ?
well, is this just supporting known CAs - just copy the system cert chain to the FR CA directory..... but ...wouldn't the server cert have to be signed by those CAs as thats the whole point of the CA, mutual trust of client to the server. I'd like to hear more of this idea to understand. alan
On May 16, 2020, at 6:42 AM, Alan Buxey <alan.buxey@gmail.com> wrote:
thats how I read it - all servers use a state value stored in a REDIS (could be others such as memcache) so that the ongoing session is known as doesnt have to go back to the same server in a cluster (I've recently done the same with a SAML setup)
Our tests show that this isn't a large help. Serializing an SSL session and writing it to a DB has a huge cost. Plus, EAP packets for the same session come very quickly. Quickly enough that the serializing the SSL sessions slows it down noticeably. What's better is to use a RADIUS-aware load balancer in front of a cluster. It can hash the callers MAC address, and ensure that all packets for an EAP session go to one back-end. We can also serialize the session resumption data. Since users resume sessions at long intervals (minutes to hours), it's OK total the cost of serializing it, and to put that data in a DB. Alan DeKok.
On May 16, 2020, at 8:19 AM, Alan DeKok <aland@deployingradius.com> wrote:
On May 16, 2020, at 6:42 AM, Alan Buxey <alan.buxey@gmail.com> wrote:
thats how I read it - all servers use a state value stored in a REDIS (could be others such as memcache) so that the ongoing session is known as doesnt have to go back to the same server in a cluster (I've recently done the same with a SAML setup)
Our tests show that this isn't a large help. Serializing an SSL session and writing it to a DB has a huge cost. Plus, EAP packets for the same session come very quickly. Quickly enough that the serializing the SSL sessions slows it down noticeably.
I don't think it'd have a huge impact if the I/O was async, it'll just increase session establishment latency.... I just don't see the point? There are plenty of load balancers that can route the packets to the same server, and if that server goes down? Oh well... In reality you'll struggle to push more than a few thousand EAP-PEAP authentications/s anyway. If authentication times out when the auth server goes down, the supplicant will try again.
What's better is to use a RADIUS-aware load balancer in front of a cluster. It can hash the callers MAC address, and ensure that all packets for an EAP session go to one back-end.
Agreed.
We can also serialize the session resumption data. Since users resume sessions at long intervals (minutes to hours), it's OK total the cost of serializing it, and to put that data in a DB.
Yep, and that's supported for pretty much every EAP method that allows it. The better method though, is sending back all the encoded session-state attributes in the ticket, then there's no need for the central database. That's not done currently unfortunately because of limitations in the OpenSSL API. -Arran
participants (4)
-
Alan Buxey -
Alan DeKok -
Arran Cudbard-Bell -
Oleg Pekar