Lacking WLAN Features (Private PSKs, Per Client Queueing)

  • 0
  • 2
  • Question
  • Updated 2 years ago
  • Answered
While trying to replace existing wireless infrastructure systems from other vendors, we get confronted with several particular features which not seem to exist in Extreme WiFi.


1. Private PSKs, local and with RADIUS backend.
Some vendors support individual WPA2 PSKs for each connecting MAC Address.
The wireless system has a list of allowed mac addresses together with a unique PSK for each address.
This way every client can have its own WPA PSK, i.e. when you want to lock out one specific client from your wireless system, you do not have to change the WPA PSK on all devices.
It also prevents users from connecting other end devices to the wireless network as every PSK is bound to a specific MAC.
This is very handy to improve management and security in wireless network with clients which do not support WPA enterprise. And it minimizes the administrative overhead for 802.1x in smaller environments.
Other vendors support private PSKs also with RADIUS backends for centralized management.
We often have Extreme WiFi together with NAC, so this would be a perfect combination.
In NAC one would have to maintain PSKs for end systems and WiFi AP must be able to derive actual PSK from RADIUS response.
Source: Workshop Slides from other vendor, cf. page 78.

Are there any ideas or plans how this could be implemented with Extreme WiFi?
For me the only way right now seems to establish WPA enterprise which is more complicated for system administrators.



2. Per Client Queueing
Especially for guest networks we have to ensure a fair traffic priorization between all connected clients. Most of the time we want to limit each client, have a defined total maximum bandwidth (for example internet uplink) and we want this bandwidth to be fairly distributed between all clients.
So let's say we have an asymmetric internet connection with 50 Mbps downstream and 10 Mbps upstream which we want to be fairly distributed to all connected clients.

The simpliest thing would be something like this:

Our aim is to share the bandwidth amongst all users, i.e. if only one user is connected he may consume all bandwidth, if two are connected each gets half the bandwidth and so on.

A more sophisticated approach would additionally limit each client to a specific bandwidth and further reduce that assigned bandwidth if more clients a requesting bandwidth than totally available.

Illustration Source: Wiki Page

Are there any possibilities to achieve a similiar guaranteed fairly bandwidth distribution with Extreme WiFi?
A simple fixed rate limit does not work in real life since the actual per user bandwidth will depend on the current traffic/user situation.

We would be happy to get some brainstorming from Extreme community how you would handle these requirements. Or to definitely get the answer that it's simply not possible. When designind networks it is also important to know your limits.

Best regards, and looking forward to your ideas
David
Photo of David Froehlich

David Froehlich

  • 252 Points 250 badge 2x thumb

Posted 2 years ago

  • 0
  • 2
Photo of Ronald Dvorak

Ronald Dvorak, Embassador

  • 47,414 Points 20k badge 2x thumb
1) I'd use 802.1X PEAP.
"We often have Extreme WiFi together with NAC, so this would be a perfect combination."
You'd create a NAC local user/pw repository for PEAP and also add the MACs to the database.
In that case you don't need any other external DB/devices and you'd do a lot more with NAC&roles.

The only difference is that the private key feature will allow also older clients that don't support 802.1X.


2) Doesn't work with the controller but I also like to see that function.
You'd search for "IAC box" - that is what I use in the meantime.
Photo of David Froehlich

David Froehlich

  • 252 Points 250 badge 2x thumb
You'd create a NAC local user/pw repository for PEAP and also add the MACs to the database.
In that case you don't need any other external DB/devices and you'd do a lot more with NAC&roles.
The only difference is that the private key feature will allow also older clients that don't support 802.1X.
Well, that implies the more complex setup of 802.1x in smaller environment. You need a server certificate signed by a trusted ca to avoid warnings on client side, or you have to enroll an own pki and deploy the root ca on all clients, or you have to disable server certificate check on clients. This actually is a show stopper for smaller customers, especially those who are used to have private PSKs. And of course it requires 802.1x configuration on client side.
And even if I'd go with 802.1x, how could I ensure that a particular user/password combination (which would be the equivalent to the PSK) can only be used on a certain end device (mac address)? As far as I know you cannot bind users in local password repository in nac to mac addresses. So for each end device you would have to create a end device group (containing the mac), a user group (containing the username) and a NAC rule joining them. That might be a nice theoretical proof of concept, but every sysadmin will chase you away if you demonstrate such a setup. :) Maintaining such a system would be impossible as you have to properly keep track of several objects for each single client.

Life is soo much easier with private PSKs.
You add a end system (mac address) in NAC and let's say as Custom1 attribute you assign an individual PSK to that particular end system. And when responding to a WiFi MAC authentication NAC simply returns a RADIUS attribute with Custom1 back to EWC which in turn uses this value as PSK for that client.
That's it. No need for any NAC rules or groups for every single client.
Don't be shocked, but this thread in MT forum is actually 8(!) years old.
Of course this isn't the right place for feature requests, but sometimes stepping 10 years behind can make you real headache when deploying WiFi in the field. :)

To sum it up the only maintanable "solution" would be sticking with 802.1x, local password repository and lacking real password-to-device binding. Could be okay for new setups, but obviously not for customers already knowing or even using private PSKs.
You'd search for "IAC box" - that is what I use in the meantime.
I've heard about it but did not actually use it yet. So it's more than just a RADIUS server, it can also act as a L3 device enforcing per-user traffic shaping? Simply returning a fixed traffic limit rate via RADIUS to EWC wouldn't be sufficient. Yep, could be a work around. But when thinking about setups with multiple sites, this would require placing a (hardware) IAC box as routing device to enforce shaping in every location? Hm, doesn't really scale.
Photo of M.Nees

M.Nees, Embassador

  • 9,264 Points 5k badge 2x thumb
Any statements or opinions from the extreme networks view regarding these 2 topics ??
Are there maybe any recent develpoment plans for that features ??

It would be nice if someone of extreme will take part of this discussion.

Regards,
Matthias
Photo of Aguilar, William

Aguilar, William, Employee

  • 2,664 Points 2k badge 2x thumb

David,

For the first request we have looked at it in the past but because it is a non-standard implementation of PSK we are concerned that it will not provide the security and interoperability customers would expect from an enterprise solution.  The solutions that are out there are proprietary and are designed for vendor lock in, which is counter to how we solve problems. Instead of describing a solution can you describe the problem that you are trying to solve?  This may help us in considering more standard-based options to try to address your pain point.  Keep in mind that most enterprise devices support 802.1x supplicants and for those that don't if you are intent is to provide protection of the data in transit, most enterprise and consumer applications provide transport level security.

For your second question we do have implementations in some stadiums today that implement bandwidth profiles per user.  The solution uses the WLAN to mark the traffic and traffic shaping with ExtremeSwitching (aka Summit) at the edge of the wired network.  If that is something that interests the community we can post more details on that solution.  Additionally we would like to understand in what vertical do you see the need for #2?

Thank you,


Will

Photo of David Froehlich

David Froehlich

  • 252 Points 250 badge 2x thumb
Hi Will,
thank you for your answer, and sorry for my deferred reply due to vacations.
However I definitely would not agree on the "non-standard"-excuse. Even the question how you actually define a standard wouldn't be easy. For example IEEE makes standards. But are RFCs "standards"? In my opinion yes, but one might argue that they are just recommendations for better interopability. In the end most customers are looking for working solutions. Whether a working solution is completely based on "standards" or also includes some "good" vendor-proprietary addons, doesn't really matter. Even in the Extreme world we have so many examples of proprietary implementations - good ones and bad ones. For example mLAG is a great thing; although it is prioprietary and not compatible with comparable technologies from other leading vendors. On the other hand there are also rather bad implementations like the way how Extreme implements simple spanning tree. I just want to have port-based RSTP (802.1w) and I want it to be enabled per default, and I want it to co-exist with other stuff like mLAG, Netlogin etc. Well, real life is a little bit different.

What I want to say: Our customers need solutions. And if they see that there are working solutions, they want to have it. Or in other words: If Netflix offers a series you want to see, at a reasonable price, and it works, you probably won't care whether they actually stream it by using a standard video codec. Most people wouldn't chose another more complicated to use service just because of the fact it's a standard.

To make a long story short: I myself still do not see a standard-based way how to address these requirements yet.
1) Some end systems may simply not 802.1x capable or configuring 802.1x would be to complicated for end users. That's a fact.
2) Relying only on L7 / transport-level security, really? Using one (probably public-known) PSK for all devices? That's not what we understand as secure networks.
3) Even if we could use 802.1x, binding one account (username/password) to one end-device is still not possible due to lacking NAC feature. For 100 MAC-to-Account bindings you would have to create 100 users, 100 user groups, 100 end-system groups and 100 nac rules for 1:1 bindings. Nobody want's to maintain this.

If the problem wasn't clear yet, let me describe it. Imagine a typical bring your own device environment. Devices end up in a VLAN which is routed by a firewall allowing certain services like HTTP to Web or RDP to Terminal Servers. You want to secure "the air", i.e. need a network-layer encryption. You do not want one shared "wifi password", i.e. no single PSK for all devices. Instead every user should get their own secret. And you want to ensure that the user can only connect the device you approved. Since end-systems can be anything (and end-user skills are limited) you cannot ensure that all devices would support 802.1x / WPA-enterprise.

With private PSKs like known from other vendors such a scenario can be addressed quite easily. And most important, it is easy to manage for the admin, and easy to use for the end user; connect to the Wi-Fi, enter your personalized PSK, that's it. End users could save their Wi-Fi profile together with their personalized key and are happy.

In theory I could image something with a public-known PSK combined with a captive portal doing the end-device registration. But it is more complicated to setup, and more complicated for the end users. That's a bit like mentioned before with RTSP: It's just to complicated to be usable. Most customers will most likely prefer the (proprietary) easy-to-use solutions instead of the more complicated based on standards. Of course might depend on the customer. Complicated implentations like the RTSP example lead to refusal by customer, i.e. they might simply leave it disabled if it is too complicated to configure. Of course, also just my experience, depending on the customer.

If something is simply not possible (in a usable way), that we are fine with that. No vendor has the "perfect product" in their portfolio addressing all kind of setups. I raised this discussion in the hope to inspire some brainstorming on how to address such a real-life scenario. My conclusion is that we simply cannot provide this functionality with Extreme Wireless, yet. But if that's the case, then please mention it as such, so we can be aware of it. Of course WPA-Enterprise should be the preferable way (and works for most setups) but there are situations where we simply need alternatives.

Regarding your second question, I agree with you that it is of course solvable if we do the actual traffic shaping on some other "more intelligent" device behind the access point. Whether it might be a switch, router, or firewall. Especially in more decentralized environments with smaller sites like for example retail stores having this functionality directly in the access point would be appreciated thus avoiding the need of additional (expensive) L2/L3 devices. If looking towards ideas like "cloud based" wi-fi infrastructures, it would be vital to have these functionality in the access point.

- David
Photo of James A

James A, Embassador

  • 6,762 Points 5k badge 2x thumb
It's not PPSK, but NAC can do per-user 802.1x account provisioning through the guest portal, it's called "Secure Guest Access". Client support of 802.1x remains an issue.

In general I agree that securing users on a guest WLAN from each other is quite hard, but really the industry should work together to find a common solution.