GTK and multiple VLANs on the same SSID

[Konstantin Kabassanov]

Hello,

One of the main issues when multiple VLANS share the same SSID (through AAA dynamic vlan assignment) is that multicast and broadcast packets from a given VLAN are received by every wireless client on the SSID. As far as I know, there are two kinds of WPA keys, one for unicast trafic with each client and a group key for multicast and broadcast.

I found a good presentation about this (unfortunately in German, but you can translate online):

( https://www.dfn.de/fileadmin/3Beratung/Betriebstagungen/bt62/Mobile-IT_Multiple_VLANs___Multicast-Probleme.pdf ).

So, I'd like to understand the GTK management in Wism2 products. I know that for some services like mDNS and IPv6, controllers implement some "proxy" workarounds, but I wonder if there is a "generic" solution in CIsco implementations for all multicast or broadcast packets. Are GTK WLAN related, or is there a way to make them more "VLAN" related, for a given WLAN?

Thanks. 

[ammahend]

Not sure if I fully understand the question, but I will try to answer some parts.

WISM2 support multicast in 2 modes:

multicast-multicast mode, this is preferred since WLC sends a single CAPWAP packet with source IP of WLC management and destination IP of multicast address you configure on WLC (to which APs requesting multicast traffic will subscribe to). Since destination is multicast, this will require the underlay infrastructure to support multicast.

multicast-unicast mode, this is where WLC creates a copy for each AP over CAPWAP tunnel where attached client has sent an IGMP join request, this is sent with source of WLC management IP and destination of AP management IP address (unicast packet). This is not a preferred way, not recommended when you have more than 50APs and not even supported on newer controllers. This does not require underlay to support multicast.

Broadcast is by default disabled on all WLCs and is recommended to leave it that way, you can potentially create very high airtime utilization and degrade performance if enabled.

For services like mDNS, since it has a TTL of 1, if the Bonjour SP is in different vlan (subnet) than the client than WLC can act as proxy (gateway) to build Bonjour SP database, forward traffic to clients, build policies etc.

GTK is for encrypting multicast traffic between AP and client, its calculated on AP and distribute to client (because the object of the group keys is only to protect messages and not provide authentication, there is no need to tie the key into the identity of any specific device).

GTK management in Wism2 products is no different than any other WLC, although its exchange can vary during roaming based on what kind of roaming methodology you deploy in your environment based on client support and WLC code version.

[Konstantin Kabassanov]

Hello,

This issue concerns wireless communication between clients and access point, not communication on the wired side between router, controller or access point.

If I'm not wrong (I have not recheck for longtime),  802.11 frames sent by APs usually contain at least 3 MAC addresses: destination, source and BSSID. BSSID address is different for each WLAN. So when a client receives a packet, it considers BSSID address for filtering before doing the same with destination address.

For multicast/broadcast packets, destination address is a particular address, mapped from upper layer ip mullticast address (or is the ethernet broadcast address). When a wireless client receives such a packet, it first checks for BSSID matching, then if it is listening to the related multicast group, forwards the packet to the IP layer.

From another point of view, when a client joins some wireless network, identified by its SSID, and dynamic vlan assignment is used by the controller through AAA, there is a kind of mapping client <--> vlan. In this situation, every multicast/broadcast packet coming from this vlan is expected to be forwarded to the client (yes, global multicasting has to be enabled in controller configs and so on…). Now, imagine that a second client joins the same SSID, but, after AAA authentication, controller attaches it to another vlan. Imagine also, that both clients listen to the same IP multicast address. They expect to receive packets coming from their vlan only.  In other words a multicast packet from vlan1 has to be transmitted to client1, but not to client2 and a multicast packet from vlan2 has to be transmitted to client2, but not to client1. 

Now, let's see what happens on the 802.11 frame layer. The packets have the same multicast destination MAC address and the same BSSID MAC address even if they come from 2 different VLANs. So how could client1 accept a packet from vlan1 and reject packets from vlan2? AFAIK, if there is no layer 2  encryption, this is impossible...

OK, let's consider some WPA(2) encryption. When using the so called "WPA2 Enterprise", the encryption keys are dynamically created. There are two kinds: these for unicast client-AP traffic, different for each client, and these for group communication, shared by all clients listening to a given group. Our issue is related to the second category, because, with this setup, we are in the same situation as if the traffic was not encrypted.

In addition, there is a known "Hole196" security vulnerability related to these group communication keys. So Cisco implemented a gtk-randomization option and it makes that group communication keys (GTK for Group Temporal Key) are no more group keys, but personalized  ones for each client. We should be very happy with this, but… Cisco claims: "Enabling gtk-randomize will prevent clients from decrypting broadcast and multicast packets". I can't understand what it means… A key for multicast communications that prevents from decrypting multicast packets… BTW there is an unanswered topic about this.

I'd expect that with this implementation every multicast packet is encrypted with a per user created key (so sent N times for N clients listening to this group). Did Cisco block such packets to avoid neighbor key cracking, as 2 clients receive the same data encrypted with 2 different keys and see the same encrypted packet for the other client, or is it anything else? I did not find any explanation yet.

From controller configuration manuals, I can see  that some mechanisms have been implemented to define separate multicast VLAN, IGMP/MLD snooping, mDNS proxying, IPv6 specific stuff. But I'm unable to image how this could be used to satisfy the following simple demand, when a unique SSID with multiple vlans assigned dynamically is set up: forward multicast/broadcast traffic from a given wired vlan to its related wireless clients and not to others.

Thanks.

[ammahend]

"forward multicast/broadcast traffic from a given wired vlan to its related wireless clients and not to others."

To my understanding I don't think that's possible but lets say somehow we implement this, won't there be a counter argument ? What about an SSID mapped to an interface Group with multiple VLANs (subnets)? In that case you would want multicast stream to be deliver to client irrespective of their their IP connected to the same SSID.

About "Hole196" since both attacker and victim need to be on network first to get the common GTK and perform any kind of
MIM ARP poisning etc, I think for most part this can simply be avoided by isolating L2 communication between clients
over wireless and reducing key rotation interval.

But I agree the wording can be more explanatory than what's shown on the controller about GTK-randomization (it does not make sense and does not add up)

[Konstantin Kabassanov]

"What about an SSID mapped to an interface Group with multiple VLANs (subnets)? In that case you would want multicast stream to be deliver to client irrespective of their their IP connected to the same SSID."

Isn't it the only way to activate dynamic vlan assignment? When you create an SSID, you have to attach a wired interface to it. So you need to use an interface group in order to switch to différents vlans after AAA overriding… I'm not sure to understand the idea of mixing multiple vlans subnets without isolation.

"But I agree the wording can be more explanatory than what's shown on the controller about GTK-randomization (it does not make sense and does not add up)"

So why shouldn't it work in my case? 

[Konstantin Kabassanov]

Hi,

I make some update to my last post: It is possible to activate dynamic wlan assignment without interface group. We just need to create a dummy interface. Not need to be forwarded outside of the controller. So, from this point of view, once authenticated, the client is attached to the vlan that AAA server sent for it. And there should not be mixing of the multicast/broadcast traffic at this point.

"For services like mDNS, since it has a TTL of 1, if the Bonjour SP is in different vlan (subnet) than the client than WLC can act as proxy (gateway) to build Bonjour SP database, forward traffic to clients, build policies etc."

My question is how to make distinction between mDNS packets (for instance) coming from vlan1 and send them only to clients attached to this vlan over the radio. Imagine you have different printer announces on each vlan and you don't want to send them to clients that don't belong to this vlan. If I'm not wrong, your proxying is made to aggregate this traffic from multiple source interfaces and not to maintain 1 to 1 wired-wireless mapping… I don't know if it is possible to implement it with policies...

I come back to the GTK-randomization. If enabled, I should expect that it isolates multicast traffic to each client, as it will be decrypted and it will be resent to all clients that have to receive it with the per client randomized key. Am I wrong?

Unfortunately it is not easy to test this from home, because we need 2 wireless clients on the same SSID, each of them attached to a different vlan, and both connected to the same access point (in order to have the same BSSID).