cancel
Showing results for 
Search instead for 
Did you mean: 

Lacking WLAN Features (Private PSKs, Per Client Queueing)

Lacking WLAN Features (Private PSKs, Per Client Queueing)

dfroe
New Contributor II
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:

177acd995e474cc79ad47ff601df73c4_RackMultipart20160517-104659-t3v0xh-320px-PCQ4_inline.png


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.

177acd995e474cc79ad47ff601df73c4_RackMultipart20160517-35011-13do9cq-320px-PCQ3_inline.png


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
6 REPLIES 6

dfroe
New Contributor II
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

James_A
Valued Contributor
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.

William_Aguilar
Extreme Employee
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

M_Nees
Contributor III
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
GTM-P2G8KFN