09-09-2022 02:38 AM
I am thinking about turning on the "PEAP Session Resume" feature in ISE but have a few questions.
I understand I can change the session timeout, but how long can a client actually ride on the cached sessions? Does ISE after a given amout of reauthentications require a full authentication again, or can a client potentially go forever on the cached session (given they reauthenticate before the session timeout)?
How does it work with Loadbalancers? Obviously we have the persistance parameter ticked so the same node handles the same client, but how would that work when the loadbalancer discards the session, and then the client tries for a reauthentication?
As i understand it for EAP-TLS there is the "Stateless Session Resume" to share the session between the PSN nodes, but the feature does not exist for PEAP.
Can someone shed some light on this?
Solved! Go to Solution.
09-11-2022 02:25 PM
This topic is shrouded in mystery and not much documentation unless you spend hours trawling the web. Many years ago I did my own lab testing to see what the impact would be of enabling these features - see this link - I observed the packets caught by tcpdump on the PSN node.
As you would have seen in a tcpdump, EAP-TLS/EAP-PEAP methods establish a TLS tunnel.
Session Resume is an efficiency mechanism that reduces the amount of work done during the TLS establishment.
Session Resume has a session lifespan - once that session expires, a full TLS establishment is performed.
Stateless Session Resume is another method that can be used, but which uses a tag of sorts in the TLS packet exchange instead of maintaining a session table in the RADIUS server - for large scale systems this would help to scale the solution.
I don't think load balancer requires any consideration here - the LB would simply see a reduction in packets that it needs to forward onto the PSN - but the job of the LB remains unchanged - and yes, session persistence is very important. I have seen documentation somewhere that says that the RADIUS Session-Timeout should always be less than the LB persistence time - the idea is that the NAD would expire the session while the LB persistence was still valid - if and when the client re-auths, then the LB would send the RADIUS to the same PSN, since the persistence is still there. This would achieve long-term stickiness. Which might also be a bad thing if you want to achieve load balancing
PEAP has another little tweak called "Fast Reconnect". This one adds even more efficiency by not checking the auth status of the client - if you enable Session Resume and Fast Reconnect, then you're saving time by doing less TLS checking, and no auth checking. The danger of Fast Reconnect is that you could allow a device on the network whose credentials have been disabled (e.g. disabled AD account). But in some cases it might just give you the efficiency boost you require.
09-11-2022 02:25 PM
This topic is shrouded in mystery and not much documentation unless you spend hours trawling the web. Many years ago I did my own lab testing to see what the impact would be of enabling these features - see this link - I observed the packets caught by tcpdump on the PSN node.
As you would have seen in a tcpdump, EAP-TLS/EAP-PEAP methods establish a TLS tunnel.
Session Resume is an efficiency mechanism that reduces the amount of work done during the TLS establishment.
Session Resume has a session lifespan - once that session expires, a full TLS establishment is performed.
Stateless Session Resume is another method that can be used, but which uses a tag of sorts in the TLS packet exchange instead of maintaining a session table in the RADIUS server - for large scale systems this would help to scale the solution.
I don't think load balancer requires any consideration here - the LB would simply see a reduction in packets that it needs to forward onto the PSN - but the job of the LB remains unchanged - and yes, session persistence is very important. I have seen documentation somewhere that says that the RADIUS Session-Timeout should always be less than the LB persistence time - the idea is that the NAD would expire the session while the LB persistence was still valid - if and when the client re-auths, then the LB would send the RADIUS to the same PSN, since the persistence is still there. This would achieve long-term stickiness. Which might also be a bad thing if you want to achieve load balancing
PEAP has another little tweak called "Fast Reconnect". This one adds even more efficiency by not checking the auth status of the client - if you enable Session Resume and Fast Reconnect, then you're saving time by doing less TLS checking, and no auth checking. The danger of Fast Reconnect is that you could allow a device on the network whose credentials have been disabled (e.g. disabled AD account). But in some cases it might just give you the efficiency boost you require.
09-12-2022 02:18 AM
Thanks for the indepth explanation.
When searching on the topic I did come acress your old post, but did'nt really find it had a clear answer.
And Craig Hyps did'nt really go into details on the matter either.
Our LB holds the session for 120 mins, so if I set the session timeout to something like 110 mins I should be good?
Do you think it will have impact on existing clients when enabling session resume? Like having to reconnect/reauthenticate?
I dont think I'm gonna enable the Fast Reconnect feature, I cant have disabled users be able to join.
09-18-2022 02:33 PM
I have seen session resume enabled in most of my customer environments without any issues. It won't affect existing connections because this feature becomes effective on new connections. Therefore, if you enable it in ISE, then new connections will benefit from this.
If you set session timeout to 110min with a LB persistence of 120min then the persistence will be retained after a re-auth. That looks ok to me.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide