A city conference-center SSID will host vendor demos that sometimes need AirDrop-like peer-to-peer transfers. How should the security designer treat peer-to-peer policy?
Select an answer to reveal the explanation.
Short Explanation
Peer-to-peer is like letting strangers pass notes in the same room—fine in a demo hall when you mean to, risky on the open library SSID. Turn it on with intent for the conference SSID; leave isolation on for everyday public Wi-Fi.
Full Explanation
Permitting peer-to-peer communication only where the conference use case requires it, while maintaining client isolation on general public SSIDs, is the prudent security design for a city conference-center WLAN hosting vendor demos needing AirDrop-like transfers. Peer-to-peer traffic allows direct Layer 2 communication between clients, enabling features like file sharing but increasing risk of lateral attacks and data leakage. Restricting peer-to-peer to specific SSIDs or VLANs used for demos limits exposure, while client isolation on general public networks protects users from each other. Always enabling unrestricted peer-to-peer on all municipal SSIDs, including staff and SCADA, is dangerous as it could expose critical infrastructure to compromise. Blocking all Layer 2 traffic entirely can disrupt essential functions like captive portal redirection and device discovery, causing connectivity failures. Ignoring peer-to-peer risks based on assumptions about guest data sensitivity overlooks potential threats from malware or unauthorized access. A key consideration is that peer-to-peer controls should be granular and aligned with use cases. Administrators should test that peer-to-peer is enabled only on designated SSIDs and that client isolation is active elsewhere, ensuring appropriate balance between functionality and security.