> On 10 Mar 2016, at 22:36, Curtis K. Larsen <curtis.k.lar...@utah.edu> wrote:
> 
> About a year and a half ago I did pretty exhaustive testing of RADIUS load 
> with the Spirent
> traffic generator and with the assistance of PacketFence developers.  
> (PacketFence is also based
> on FreeRADIUS).  They suggested we tweak the MaxConcurrentAPI setting on our 
> test AD server.  So
> we did, but unfortunately it seemed to make no difference at all in the 
> number of authentications
> per second we could process from the load generator.
> 
> One thing we found though was that if we ran the authentications against a 
> flat file on the RADIUS
> server itself we could process six times more authentications.  The bottom 
> line is that whether it
> is SAMBA, NTLM, AD, or network latency itself I can't say - but I do know 
> that if I eliminate all
> of them performance increases dramatically.
> 
> Bottom line:  Use EAP-TLS, and avoid checking LDAP/AD except when absolutely 
> necessary.  PEAP is
> vulnerable to fake AP/MITM attacks anyway.

PEAP and TTLS are both horrifically insecure. I have a presentation on it 
coming up, i'll post the video when it's complete.

The OSX/IOS/Windows supplicants are all vulnerable to bid down attacks when 
there's no wireless profile for the network.

The server can request EAP-TTLS and they'll happily oblige, meaning you don't 
even need to crack the DES keys in MSCHAPv2.

> 
> If you must check AD all the time - get a lot of servers, load balance them, 
> monitor and graph
> authentications down to the second.  That way you'll be more likely to 
> identify the cause of an
> issue.

It doesn't help that FreeRADIUS's processing model is synchronous.  We're 
looking at fixing that, but after considering all the options it really looks 
like the only model we can adopt is using our own stack. That means adapting 
the current unlang interpreter to provide coroutine like behaviour, and 
reworking function calls in any module that performs blocking I/O.

It's not trivial, not sponsored, and there's only two full time developers so 
it's going to take a while.

-Arran


Arran Cudbard-Bell <a.cudba...@freeradius.org>
FreeRADIUS development team

FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2


**********
Participation and subscription information for this EDUCAUSE Constituent Group 
discussion list can be found at http://www.educause.edu/groups/.

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

Reply via email to