EAP-TLS performance SQL backend bottleneck
Hello, Can anyone recommend improving performance for EAP-TLS when using SQL backend? Currently we see around 11 message exchanges (10 Access-Challenge messages from the server) for each EAP-TLS authentication and each time client sends data, the server tries to fetch data from database which is bad. This results in huge number of database lookups that kill performance. What is recommended way to deal with such problem? Thanks -- View this message in context: http://www.nabble.com/EAP-TLS-performance-SQL-backend-bottleneck-tp25386668p... Sent from the FreeRadius - User mailing list archive at Nabble.com.
Can anyone recommend improving performance for EAP-TLS when using SQL backend? Currently we see around 11 message exchanges (10 Access-Challenge messages from the server) for each EAP-TLS authentication and each time client sends data, the server tries to fetch data from database which is bad. This results in huge number of database lookups that kill performance.
What is recommended way to deal with such problem?
Upgrade, or revert to default configuration (which doesn't do that in newer versions). Ivan Kalik Kalik Informatika ISP
I am using 2.1.4 release. Are you saying that the latest release improved that? I did not change the default configuration. here is how it looks: authorize { ... eap { ok = return } ... sql } We see that it fetches data from database 4(radcheck,radusergroup,radgroupcheck,radgroupreply)*11 (handshake challenges) = 44 times for every EAP-TLS authentication leopold wrote:
Hello, Can anyone recommend improving performance for EAP-TLS when using SQL backend? Currently we see around 11 message exchanges (10 Access-Challenge messages from the server) for each EAP-TLS authentication and each time client sends data, the server tries to fetch data from database which is bad. This results in huge number of database lookups that kill performance.
What is recommended way to deal with such problem? Thanks
-- View this message in context: http://www.nabble.com/EAP-TLS-performance-SQL-backend-bottleneck-tp25386668p... Sent from the FreeRadius - User mailing list archive at Nabble.com.
The documentation says that it was improved only for TTLS and PEAP, but not for TLS. EAPTLS module always returns "updated" in authorize section and only in the end it returns "ok" in authenticate section. We need to avoid calling SQL module in authorize section leopold wrote:
Hello, Can anyone recommend improving performance for EAP-TLS when using SQL backend? Currently we see around 11 message exchanges (10 Access-Challenge messages from the server) for each EAP-TLS authentication and each time client sends data, the server tries to fetch data from database which is bad. This results in huge number of database lookups that kill performance.
What is recommended way to deal with such problem? Thanks
-- View this message in context: http://www.nabble.com/EAP-TLS-performance-SQL-backend-bottleneck-tp25386668p... Sent from the FreeRadius - User mailing list archive at Nabble.com.
Hi,
The documentation says that it was improved only for TTLS and PEAP, but not for TLS. EAPTLS module always returns "updated" in authorize section and only in the end it returns "ok" in authenticate section. We need to avoid calling SQL module in authorize section
do you need SQL in authorize section anyway? if you are using the inner tunnel virtual server then that should be called if the type is EAP and therefore you will shortcut any SQL stuff...thats with default configuration (i dont know what you've done to your server) alan
Alan, If not in "authorize" section, where do I put "sql" module call? We have to go and validate user in SQL and we need to return reply-attributes to the client. Thanks! Alan Buxey wrote:
Hi,
The documentation says that it was improved only for TTLS and PEAP, but not for TLS. EAPTLS module always returns "updated" in authorize section and only in the end it returns "ok" in authenticate section. We need to avoid calling SQL module in authorize section
do you need SQL in authorize section anyway? if you are using the inner tunnel virtual server then that should be called if the type is EAP and therefore you will shortcut any SQL stuff...thats with default configuration (i dont know what you've done to your server)
alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- View this message in context: http://www.nabble.com/EAP-TLS-performance-SQL-backend-bottleneck-tp25386668p... Sent from the FreeRadius - User mailing list archive at Nabble.com.
Hi,
If not in "authorize" section, where do I put "sql" module call? We have to go and validate user in SQL and we need to return reply-attributes to the client.
authorize is used solely to see if someone is able to use a service from a particular IP address..at a certain time etc etc. its got nothing to do with 'validation' of a user and it shouldnt be used for reply attributes. to 'validate' a user, use authentication to return reply-attributes, call sql in the post-auth section (you only want to call this function if they have validated etc) its just a case of semantics and understanding what each letter in AAA really means alan
OK thanks Alan. I moved sql module call from "authorize" to "post-auth", this improves performance, but the behavior is different. Inside policy.conf we have "do_not_respond" policy and if SQL server is down we need to force server not to respond in "post-auth" This do_not_respond policy works perfect only if we call it during "authorize" section. In authorize section we check if SQL module returns "failed" and do not respond in this case. However, in "post-auth" section do_not_respond policy does not have effect. Is there any limit where do_not_respond can be used? # # If you want the server to pretend that it is dead, # then use the "do_not_respond" policy. # do_not_respond { update control { Response-Packet-Type := Do-Not-Respond } handled } Alan Buxey wrote:
Hi,
If not in "authorize" section, where do I put "sql" module call? We have to go and validate user in SQL and we need to return reply-attributes to the client.
authorize is used solely to see if someone is able to use a service from a particular IP address..at a certain time etc etc. its got nothing to do with 'validation' of a user and it shouldnt be used for reply attributes.
to 'validate' a user, use authentication
to return reply-attributes, call sql in the post-auth section (you only want to call this function if they have validated etc)
its just a case of semantics and understanding what each letter in AAA really means
alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- View this message in context: http://www.nabble.com/EAP-TLS-performance-SQL-backend-bottleneck-tp25386668p... Sent from the FreeRadius - User mailing list archive at Nabble.com.
I moved sql module call from "authorize" to "post-auth"
What if you leave sql in authorize of the default virtual server, but wrap it with unlang that only calls it if you're not doing EAP. Then, always call it in the inner-tunnel virtual server's authorize section. The inner-tunnel authorize is after the TLS tunnel is formed so it seems that this would eliminate the redundant database calls that occur in the default virtual server while the tunnel is being setup.
Maybe I missing something , but I am using EAP-TLS with client certificate authentication and not PEAP or EAP-TTLS. Inside inner-tunnel comments it does not say anything about EAP-TLS This is a virtual server that handles *only* inner tunnel # requests for EAP-TTLS and PEAP types. Can this inner-tunnel handle EAP-TLS as well? Thanks! Garber, Neal wrote:
I moved sql module call from "authorize" to "post-auth"
What if you leave sql in authorize of the default virtual server, but wrap it with unlang that only calls it if you're not doing EAP. Then, always call it in the inner-tunnel virtual server's authorize section. The inner-tunnel authorize is after the TLS tunnel is formed so it seems that this would eliminate the redundant database calls that occur in the default virtual server while the tunnel is being setup.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- View this message in context: http://www.nabble.com/EAP-TLS-performance-SQL-backend-bottleneck-tp25386668p... Sent from the FreeRadius - User mailing list archive at Nabble.com.
leopold wrote:
OK thanks Alan. I moved sql module call from "authorize" to "post-auth", this improves performance, but the behavior is different.
List "sql.authorize" in the post-auth section. Not "sql".
Inside policy.conf we have "do_not_respond" policy and if SQL server is down we need to force server not to respond in "post-auth"
The code currently sets the response packet type (accept / reject), and THEN calls the post-auth methods.
Is there any limit where do_not_respond can be used?
Yes. It cannot be used in the post-auth section. It sounds like your requirements are somewhat contradictory. You DON'T want it to query SQL for the EAP-TLS traffic, but you DO want it to ignore EAP-TLS if the SQL database is down. If the SQL database is down, and you don't want the server to respond, then just bring the server down. Write a simple shell script to poke the SQL server, and to re-start FreeRADIUS once the SQL server comes back up. Alan DeKok.
Thank you very much Alan for your reply. Let me please clarify the requirements. EAP-TLS: - perform the needed SSL handshake, there are 11 messages exchanged and I do not want to query SQL each time and it degrades performance. - find the user/machine in SQL, compare check attributes and respond with reply attributes based on SQL data. If SQL is down or some other SQL connection failure then DO NOT RESPOND. If user/machine is not found in SQL DB or check attributes do not match reject, otherwise accept. Your suggestion with sql.authorize in post-auth section "almost" works, the only problem is we need not to respond when SQL is down. Because otherwise RADIUS might respond with Access-Accept and won't send the needed reply attributes when SQL is unavailable. Could you please change the code if there is not other neat way around to still use "do_not_respond" policy in post-auth section? Maybe in event.c you could check if control is set not to respond and then drop the packet? Thanks again Alan DeKok-2 wrote:
leopold wrote:
OK thanks Alan. I moved sql module call from "authorize" to "post-auth", this improves performance, but the behavior is different.
List "sql.authorize" in the post-auth section. Not "sql".
Inside policy.conf we have "do_not_respond" policy and if SQL server is down we need to force server not to respond in "post-auth"
The code currently sets the response packet type (accept / reject), and THEN calls the post-auth methods.
Is there any limit where do_not_respond can be used?
Yes. It cannot be used in the post-auth section.
It sounds like your requirements are somewhat contradictory. You DON'T want it to query SQL for the EAP-TLS traffic, but you DO want it to ignore EAP-TLS if the SQL database is down.
If the SQL database is down, and you don't want the server to respond, then just bring the server down. Write a simple shell script to poke the SQL server, and to re-start FreeRADIUS once the SQL server comes back up.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- View this message in context: http://www.nabble.com/EAP-TLS-performance-SQL-backend-bottleneck-tp25386668p... Sent from the FreeRadius - User mailing list archive at Nabble.com.
leopold wrote:
Thank you very much Alan for your reply. Let me please clarify the requirements. EAP-TLS: - perform the needed SSL handshake, there are 11 messages exchanged and I do not want to query SQL each time and it degrades performance.
You already said that.
- find the user/machine in SQL, compare check attributes and respond with reply attributes based on SQL data.
You already said that.
If SQL is down or some other SQL connection failure then DO NOT RESPOND.
You already said that. I already said that this pointless. If SQL is down, why the heck are you doing 10-11 EAP packets? It makes no sense.
If user/machine is not found in SQL DB or check attributes do not match reject, otherwise accept.
That's how the server works.
Your suggestion with sql.authorize in post-auth section "almost" works, the only problem is we need not to respond when SQL is down.
Did you bother to read the REST of my message, saying how you could accomplish this?
Because otherwise RADIUS might respond with Access-Accept and won't send the needed reply attributes when SQL is unavailable. Could you please change the code if there is not other neat way around to still use "do_not_respond" policy in post-auth section?
No.
Maybe in event.c you could check if control is set not to respond and then drop the packet?
No. Read my previous message again. There is a way to do this without modifying the server code. Alan DeKok.
Alan DeKok-2 wrote:
leopold wrote:
Thank you very much Alan for your reply. Let me please clarify the requirements. EAP-TLS: - perform the needed SSL handshake, there are 11 messages exchanged and I do not want to query SQL each time and it degrades performance.
You already said that.
- find the user/machine in SQL, compare check attributes and respond with reply attributes based on SQL data.
You already said that.
If SQL is down or some other SQL connection failure then DO NOT RESPOND.
You already said that.
I already said that this pointless. If SQL is down, why the heck are you doing 10-11 EAP packets? It makes no sense.
If user/machine is not found in SQL DB or check attributes do not match reject, otherwise accept.
That's how the server works.
Your suggestion with sql.authorize in post-auth section "almost" works, the only problem is we need not to respond when SQL is down.
Did you bother to read the REST of my message, saying how you could accomplish this?
Because otherwise RADIUS might respond with Access-Accept and won't send the needed reply attributes when SQL is unavailable. Could you please change the code if there is not other neat way around to still use "do_not_respond" policy in post-auth section?
No.
Maybe in event.c you could check if control is set not to respond and then drop the packet?
No.
Read my previous message again. There is a way to do this without modifying the server code.
The solution with a shell script that tests SQL server periodically and kills/restart RADIUS daemon is not very neat. Also if polling interval is too low we might miss DB failure if too high it will introduce unnessary load on DB If you already have the capability not to respond, why it can't be used in POST-AUTH? Why you can't just check something like this? vp = pairfind(request->config_items, PW_RESPONSE_PACKET_TYPE); if (vp && vp->vp_integer == 256) { request->reply->code = 0; }
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- View this message in context: http://www.nabble.com/EAP-TLS-performance-SQL-backend-bottleneck-tp25386668p... Sent from the FreeRadius - User mailing list archive at Nabble.com.
leopold wrote:
The solution with a shell script that tests SQL server periodically and kills/restart RADIUS daemon is not very neat. Also if polling interval is too low we might miss DB failure if too high it will introduce unnessary load on DB
Are you saying that: a) a one-second poll interval is too large? b) your DB can't handle one additional select per second? Really? Honestly?
If you already have the capability not to respond, why it can't be used in POST-AUTH? Why you can't just check something like this?
You have access to the source code. If you want to hack it, go ahead. Alan DeKok.
The documentation says that it was improved only for TTLS and PEAP, but not for TLS. EAPTLS module always returns "updated" in authorize section and only in the end it returns "ok" in authenticate section. We need to avoid calling SQL module in authorize section
So don't call it. Remove it from authorize and list sql.authorize in post-auth. That will add reply attributes from the database. Ivan Kalik Kalik Informatika ISP
It looks to me if authenticate section passes it sets request->reply->code=2 (Access-Accept) and then we cannot force server not to respond as it compares with 0 How can we force it not to respond in post-auth if control is set to not_respond (PW_RESPONSE_PACKET_TYPE is 256)? event.c case PW_AUTHENTICATION_REQUEST: gettimeofday(&request->next_when, NULL); if (request->reply->code == 0) { /* * Check if the lack of response is intentional. */ vp = pairfind(request->config_items, PW_RESPONSE_PACKET_TYPE); if (!vp) { RDEBUG2("There was no response configured: rejecting request %d", request->number); request->reply->code = PW_AUTHENTICATION_REJECT; } else if (vp->vp_integer == 256) { RDEBUG2("Not responding to request %d", request->number); } else { request->reply->code = vp->vp_integer; } } I looked in the code and inside event.c Ivan Kalik wrote:
The documentation says that it was improved only for TTLS and PEAP, but not for TLS. EAPTLS module always returns "updated" in authorize section and only in the end it returns "ok" in authenticate section. We need to avoid calling SQL module in authorize section
So don't call it. Remove it from authorize and list sql.authorize in post-auth. That will add reply attributes from the database.
Ivan Kalik Kalik Informatika ISP
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- View this message in context: http://www.nabble.com/EAP-TLS-performance-SQL-backend-bottleneck-tp25386668p... Sent from the FreeRadius - User mailing list archive at Nabble.com.
participants (5)
-
Alan Buxey -
Alan DeKok -
Garber, Neal -
Ivan Kalik -
leopold