New Features Development Question

[Arran Cudbard-Bell]

> On May 16, 2020, at 8:19 AM, Alan DeKok <aland at deployingradius.com> wrote:
> 
> On May 16, 2020, at 6:42 AM, Alan Buxey <alan.buxey at 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