Hi Alan, Thanks for the quick response and sorry for the delay in writing back. I've tested with the increased buffer sizes(in dhcp.relay server and also linux kernel) as below(25 MB) and still the result is same, couldn't go beyond 2000-2500 4 way transactions (CPU of all the cores on my relay server is fully occupied, which I've missed mentioning in the initial mail). # sysctl net.core.wmem_max net.core.wmem_max = 26214400 # sysctl net.core.wmem_default net.core.wmem_default = 26214400 # sysctl net.core.rmem_max net.core.rmem_max = 26214400 # sysctl net.core.rmem_default net.core.rmem_default = 26214400 server dhcp.eth1 { listen { ipaddr = * port = 67 type = dhcp interface = eth1 recv_buff = 26214400 Please advise on further steps/enhancements. Thanks in advance, Vikram. -----Original Message----- From: Freeradius-Users [mailto:freeradius-users-bounces+vikram.katuri=viasat.com@lists.freeradius.org] On Behalf Of Alan DeKok Sent: Thursday, March 28, 2019 4:56 PM To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Cc: Chinnapaiyan, Nagamani <Nagamani.Chinnapaiyan@viasat.com>; Munhall, Damon <Damon.Munhall@viasat.com> Subject: Re: seeking info on max.rate supported by dhcp.relay in v3.0.0.19 On Mar 28, 2019, at 7:19 AM, Katuri, Vikram <Vikram.Katuri@viasat.com> wrote:

May I please know the max.supported rate for dhcp.relay(with load balancing) in version 3.0.19.

There is no pre-set limit on the rate of DHCP relay. It depends on the OS, CPU, etc.

I see its getting capped at 5000 incoming discovers and only 2500 of them are able to complete the 4 way DORA(via dhcp.relay). 3700 with discover and request alone handled by the dhcp.relay and request and ack directly sent by the dhcp server to the client bypassing the relay(by not filling in the gateway address, server sends to the ciaddr). Setup details: 5 clients running perfdhcp each trying dhcp transactions at a rate of 1000/sec. Dhcp.relay on v3.0.19 running on c4.2xlarge instance (8 CPUs) on AWS cloud, 3 v4 dhcp servers behind it running on t2.medium instances on AWS cloud.

That seems a bit low. I've tested v3 at 20K packets/s for RADIUS proxying. One thing you may try changing is the "recv_buff" setting in the listener. See sites-available/default for an example. The same setting should work for DHCP, too. The default kernel receive buffer size is set very low. If you increase it, UDP performance can go up significantly. Alan DeKok. - List info/subscribe/unsubscribe? See https://urldefense.proofpoint.com/v2/url?u=http-3A__www.freeradius.org_list_...

Things to look at: You may find that you need to look at the network interface configuration ... Last time I was coding tests against DHCP the "dumb" NIC regularly dropped packets because the ring buffer filled faster than the kernel was fetching them. This is also strongly influenced by how the interrupts are being optimised for example. (For really bursty traffic this can happen at relatively low packet rates). Obviously don't run the test client on the same server. I'm also aware that you might be processing stuff too late when the ingest rate is beyond the processing speed per packet. If this happens then you almost always end up processing packets that will not be accepted by the client (it having timed out the request). This goes against tuning those queues too big. In practice if it's possible to drop old packets without processing further it can be surprisingly effective under extreme load. The assumption is that not processing allows more clients through the full DORA process thus the load is reduced. This improves load exponentially because less clients offline => less load => greater chance of processing the full set of packets. Best thing to do is what is always the way with slowness. (teaching to suck eggs I'm sure). Speed test with a slow ramp up of packets per second until you see some replies dropped or responses arriving after the normal client timeout. This is the fastest your server can cope without tuning. Now start the tuning game, change "one thing" then retest, repeat until you are sure there is no more to optimise or you reach your desired performance. Oh and remember to check all dependencies. Eg. You might be using a database and the problems really the database under load. A. On 01/04/2019, 08:29, "Freeradius-Users on behalf of Katuri, Vikram" <freeradius-users-bounces+alister.winfield=sky.uk@lists.freeradius.org on behalf of Vikram.Katuri@viasat.com> wrote: Hi Alan, Thanks for the quick response and sorry for the delay in writing back. I've tested with the increased buffer sizes(in dhcp.relay server and also linux kernel) as below(25 MB) and still the result is same, couldn't go beyond 2000-2500 4 way transactions (CPU of all the cores on my relay server is fully occupied, which I've missed mentioning in the initial mail). # sysctl net.core.wmem_max net.core.wmem_max = 26214400 # sysctl net.core.wmem_default net.core.wmem_default = 26214400 # sysctl net.core.rmem_max net.core.rmem_max = 26214400 # sysctl net.core.rmem_default net.core.rmem_default = 26214400 server dhcp.eth1 { listen { ipaddr = * port = 67 type = dhcp interface = eth1 recv_buff = 26214400 Please advise on further steps/enhancements. Thanks in advance, Vikram. -----Original Message----- From: Freeradius-Users [mailto:freeradius-users-bounces+vikram.katuri=viasat.com@lists.freeradius.org] On Behalf Of Alan DeKok Sent: Thursday, March 28, 2019 4:56 PM To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Cc: Chinnapaiyan, Nagamani <Nagamani.Chinnapaiyan@viasat.com>; Munhall, Damon <Damon.Munhall@viasat.com> Subject: Re: seeking info on max.rate supported by dhcp.relay in v3.0.0.19 On Mar 28, 2019, at 7:19 AM, Katuri, Vikram <Vikram.Katuri@viasat.com> wrote: > May I please know the max.supported rate for dhcp.relay(with load balancing) in version 3.0.19. There is no pre-set limit on the rate of DHCP relay. It depends on the OS, CPU, etc. > I see its getting capped at 5000 incoming discovers and only > 2500 of them are able to complete the 4 way DORA(via dhcp.relay). > 3700 with discover and request alone handled by the dhcp.relay and request and ack directly sent by the dhcp server to the client bypassing the relay(by not filling in the gateway address, server sends to the ciaddr). > Setup details: > 5 clients running perfdhcp each trying dhcp transactions at a rate of 1000/sec. > Dhcp.relay on v3.0.19 running on c4.2xlarge instance (8 CPUs) on AWS cloud, 3 v4 dhcp servers behind it running on t2.medium instances on AWS cloud. That seems a bit low. I've tested v3 at 20K packets/s for RADIUS proxying. One thing you may try changing is the "recv_buff" setting in the listener. See sites-available/default for an example. The same setting should work for DHCP, too. The default kernel receive buffer size is set very low. If you increase it, UDP performance can go up significantly. Alan DeKok. - List info/subscribe/unsubscribe? See https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-3A__www.freeradius.org_list_users.html%26d%3DDwIGaQ%26c%3Djcv3orpCsv7C4ly8-ubDoUfrxF5xIGWmptxGWP5vi5w%26r%3DErCz_gtvq5KYouGyGCP2IPAR_J5Yv1HfOlLSlxMEpHA%26m%3DLWo4HS3j5Wmc3KEupfElllAKCu_Rs_NzJZk6bPXAHXY%26s%3D4AtWAQQkoDHdzAV-8zYRp1ciw-cVEmyXl_nLObXEWpU%26e&data=02%7C01%7Calister.winfield%40sky.uk%7Cce1d12fbd06e418295c608d6b66b550f%7C68b865d5cf184b2b82a4a4eddb9c5237%7C0%7C1%7C636896969459816168&sdata=B1rbiTIjFgjdQEtXx4LysxImySxrAR94iUgS1zw4oqo%3D&reserved=0= - List info/subscribe/unsubscribe? See https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.freeradius.org%2Flist%2Fusers.html&data=02%7C01%7Calister.winfield%40sky.uk%7Cce1d12fbd06e418295c608d6b66b550f%7C68b865d5cf184b2b82a4a4eddb9c5237%7C0%7C1%7C636896969459816168&sdata=3q76J2nQkw%2B1i0Qwff0DeGkefYMLVHSZFUBQ0xe%2B6Ts%3D&reserved=0 -------------------------------------------------------------------- This email is from an external source. Please do not open attachments or click links from an unknown or suspicious origin. Phishing attempts can be reported by sending them to phishing@sky.uk as attachments. Thank you -------------------------------------------------------------------- Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of Sky Limited and Sky International AG and are used under licence. Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075), Sky Subscribers Services Limited (Registration No. 2340150) and Sky CP Limited (Registration No. 9513259) are direct or indirect subsidiaries of Sky Limited (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD

On Apr 2, 2019, at 9:32 AM, Andre Forigato <andre.forigato@rnp.br> wrote:

I need to share information about the safety of Eduroam.

The system has been built by people who know what they're doing.

If a hacker installs an access point with the name of Eduroam, and this access point points to a Freeradius server, it is possible that the malicious person sees all the logins and passwords in the Freeradius logs.

That's not true.

How to avoid this situation? Should user institutions force their students to use personal certificates? (certificate issued by the institution itself to its students)

You should read the specifications to see how the protocols actually work.

Reaffirming that the idea here is how to make users of university institutions not fall into the trap of malicious people. Anyone can set up an access point pointing to a fake freeradius server. And these malicious people can get the username and password from all the devices that connect to the Eduroam access point.

Again, that's not true.

How can we solve this problem?

Understand how things work before you claim that they're broken. Alan DeKok.

On Apr 2, 2019, at 9:58 AM, Sebastian Hagedorn <Hagedorn@uni-koeln.de> wrote:

Hm, are you familiar with this paper? My understanding of it is that (some) badly configured clients are vulnerable.

<https://www.sciencedirect.com/science/article/pii/S0167404817302808>

Well, if people misconfigure things, then anything can happen. I've seen similar things with FreeRADIUS. "Hi, we configured the system to not check passwords, and now anyone is let in! FreeRADIUS has a security issue" Security is hard. Which is why most people get it wrong. Alan DeKok.

On Tue, Apr 02, 2019 at 03:48:13PM +0200, Sebastian Hagedorn wrote: [...]

certificate the RADIUS server presents – especially Android devices don't usually do that.

Just as a sidenote, Android does support EAP-PWD, which works without certificates and uses some kind of zero knowledge proof to authenticate the parties (radius, wifi client) to each other, at the small drawback of transmitting the user name in plain text. Thus, EAP-PWD should always be safe to use with eduroam regardless of how the end user's device is configured. -HC

Andre Forigato <andre.forigato@rnp.br> wrote:

I need to share information about the safety of Eduroam.

Not just eduroam... an advanced attacker can target any SSID.

If a hacker installs an access point with the name of Eduroam, and this access point points to a Freeradius server, it is possible that the malicious person sees all the logins and passwords in the Freeradius logs.

Not just FreeRADIUS, though it is probably the tool of choice, attackers can use any RADIUS server for this. It does not have to be the same kind of RADIUS server that the attacked institution uses.

How to avoid this situation? Should user institutions force their students to use personal certificates? (certificate issued by the institution itself to its students)

If you can, the safest way to do it is to provision all clients with a trusted root certificate for a local CA, and when doing so, lock the clients to a particular DN, and if possible, to a particular set of CA roots. How you can configure a client... depends a lot on the client. Not all clients are as safe as others. Old Androids are especially bad. If you actually can install your own root on your clients, you can probably also use EAP-TLS without passwords. Many people prefer this system to MSCHAP or TTLS. The drawbacks are that usernames from the certificates will be easy to sniff out of the air (no privacy protection), and if a device is stolen, the user is unlikely to know how to revoke the certificate themselves, versus changing their password, which hopefully most of your users know how to do. The second best way to do this is with a public CA. In this case to be safe you need your clients to configure to only trust certificates ending in a domain name for which no responsible CA will issue certificates to anyone but you. This puts a lot of trust in the public CA system, and it is very hard to get users to properly configure their devices. You also have to pay attention to when the public CA roots expire and which clients have which public CA roots in their default operating store. The advantage to this system is it is possible to set up a client securely entirely by hand if you know what you are doing... there is no need to download and install extra configuration profiles (except on OSX and iOS because they took away the options to secure things by hand a couple of years ago). The problem, of course, is that most users do not know what they are doing and they will just type in their password when asked and the client will not have the correct settings.

hi,

And I am being questioned by several authorities about security, what would be the best security? For this reason I decided to consult our experts here in the list.

depends on what the institution is capable and willing to do. the best would be a local root CA with EAP-TLS, so there are no passwords being used - a MitM attack would just fail - they wouldnt have relevant server cert or root. if the site can work on good documentation/communication and ensure users are using provisioning client, then EAP-TTLS or EAP-PEAP with a local root CA (once again, to ensure that anyone attacking couldnt have a valid cert - as anyone can get a cert thats signed by public CA that a device just trusts). another option is to couple the deployment of eduroam with ANOTHER source of authentication - ie have a seperate/different password for eduroam so that even if the client was compromised or lost/stolen, those credentials dont give access to email/computing resources etc. - several sites in the UK do this method education is the main thing though - ensure users configure their device correctly, dont just click on 'okay/accept' whenever such a thing arises. it will never be perfect as these are end users...the same who do respond to phishing emails or use the same password on many 3rd party systems so when those get p0wned the user account gets abused globally :( if you search the mailing list archives you'll see this question and attack vector mentioned a couple of times a year alan

Hi Andre, I guess that this issue will be marginal at some point but all this years, and specially with Android, has been indeed a serious one. Apart from educating people and constantly remind them to use eduroam CAT, we take one step further and actively, periodically check that the devices don't automatically trust an "evil twin" / "rogue" RADIUS server. This is to ensure that every device configuration that passes the check, and thus is able to use eduroam, will not trust those "evil twins". Regards, Alberto

Brian, When I looked at doing this several years ago, I found it could really

confuse the client supplicants and force users to turn their WiFi off and on to reconnect. Have you not found the same?

Until now checks always end in either the device refusing to continue the EAP exchange (eg.: Windows 10, Apple devices), the device continuing only to fail establishing (Access-Reject) the TLS tunnel (eg.: Android), or the device really establishing the TLS tunnel and then sending authentication material, which we answer with an Access-Reject.

From our experience, supplicants always retry authentication just after an Access-Reject, even if they didn't trust the server cert! The exception is the native Windows 7 supplicant, that interprets an Access-Reject as a credentials error, does not retry even once and prompts for a new user/pass.

With FreeRADIUS 3.0.18 we will be able to do-not-respond on the Post-Auth Reject block if the check is ongoing. This should solve the Windows 7 issue and overall be a more elegant behaviour for devices like Android. Yours, Alberto

Are you using a different AP (BSSID) than one that would normally be used for access, or are you sending the bad cert on your production BSSIDs?

On regular BSSIDs, but I guess that if supplicants were to blacklist BSSIDs based on the RADIUS server cert we could dedicate an AP for this. -- Alberto Martínez Setién Comunicación y Sistemas Servicio Informático Universidad de Deusto Avda. de las Universidades, 24 48007 - Bilbao (SPAIN) Phone: +34 944 139 000 Ext. 2859