Very interesting looking research and examples. That at least as of their work they think VLANs can help mitigate it though is an important thing:

>We remark that our attack cannot bypass VLANs. In other words, based on current experiments, our attack cannot be used to exploit a device in another VLAN.

This is mostly how I've rolled things out, authorized users all get put on their own VLANs with the idea that traffic gets forced through the router and as another isolation layer. This applies to all authorized traffic. I say "mostly" though because at least two sites are run with a more generic "Guest" setup which is flat, and does indeed depend on client isolation. So while guest users would be unable to attack anything on all the other VLANs, they could attack each other. This then is another major motivation for:

>Note that when using multi-PSK (a.ka. per-station PSK or identity PSK), you can put clients in different VLANs depending on the password that they use. In other words, you can use a VLAN for each password. This prevents clients with different passwords from attacking each other.

MPSK (or "PPSK") was the final driving reason in beginning a switchover from UniFi to Omada for me, because it dramatically simplifies using VLANs even for completely unmanaged BYOD situations (a college for example). If everything under the sun supported 802.1x auth and the whole certificate situation was much better it wouldn't be an issue, but as it is getting huge numbers of devices (not just IOT, everything from TV appliances and consoles to a lot of new printers) onto the right VLAN was a pain requiring manual effort with MAC auth bypass which would be easily hoovered up too. MPSKs are a fairly elegant solution to that, you can just give people their own password or passwords, and then they can just use those as they would any typical WPA2-PSK network and everything ends up on the assigned VLANs without further IT assistance required. It's such a big feature that I think going forward I'm going to consider it essential. Also makes it easy to have even more IOT separation, every single last category of device (well, at least up to thousands) can be on its own VLAN no problem, and all the typical irritating """smarts""" of IOT stuff like where things of the same device manufacturer try to share WiFi password all is controlled and does as it should too.

One thing I would be curious about though was how this works with full virtual SDNs, which is now how all important stuff gets done, simply not trusting the physical network at all. They talk about traffic encrypted at a higher layer:

>We remark that intercepted traffic may be protected by higher-layer encryption, such as TLS and HTTPS. Nevertheless, even if higher-layer encryption is being used, our attack still reveals the IP address that a victim is communicating with. This in turn reveals the websites that a victim is visiting, which can be sensitive information on its own.

But I assume that if using WireGuard or Nebula or the like, particularly the former in a typical wheel/spoke setup, this leak would also be quelled? The VPN goes to either the router or other endpoint which can be isolated, and that then relays to the final destination, so being able to tell where the VPN traffic was going wouldn't reveal much. The mesh aspect of Nebula might reveal more, since it'd tell what other nodes were being communicated with, but as those are going to be internal and protected except via Nebula traffic I'm not sure if that's critical either, going out to websites would still mean getting proxied?

Anyway, guess another reminder that things lower down the stack can have surprises.