Temporary “client-isolation” override for trusted network client groups on public networks – how about it?

Most Wi-Fi hotspots that are properly set up are configured to isolate client devices on the network that is available for use by the general public. This function, commonly known as AP-isolation or client-isolation is seen as a security measure to stop network users trespassing on to the computers owned by fellow network users.

But there are times when it is desirable for network users to interlink devices using the hotspot’s network infrastructure. For example, a person may want to transfer data between a laptop and another device such as a smartphone or digital camera. Another example would be for two trusted users who want to transfer data between each other or simply to play a network game over that local network.  This kind of client-isolation would make it harder to set up these kind of mutually-trusted network interactions in public networks.

You may think that the only solution would be to use Wi-Fi Direct or similar Wi-Fi-based “personal-area-network” technology. The main limitation with this technology is that it requires the device or trusted computer to be close to the laptop that is the “hub” of the “personal-area-network” rather than be anywhere in the scope of the hotspot network. This can limit activities like photographers and videographers downloading each shot or take to a laptop computer as they complete their shots or takes; or simply the fun of peer-to-peer network gaming.

One way of going about this could be to establish a so-called “trusted-group” protocol for devices in the same logical network and this protocol could be managed at the public-network’s gateway device. The devices could be registered by MAC address or use of a session-driven “trusted-group” key and, once set up this way, inter-client data transfer can proceed through the hotspot network. This could be set up through a management protocol that permits the creation of a trusted group and the addition of client devices to that group.

The creation of the “trusted group” could be integrated at the provisioning stage of one’s hotspot session such as when the disclaimer contract is agreed on or the username and password is validated in a docket-based system. The user would then be pointed to a session-management page where they can log out, buy extra time or add computers and devices to the trusted group.

The main limitation with this is that there isn’t a way to provide for hotspot provisioning to devices like smartphones, PMPs or handheld games consoles. These devices typically have a small screen and use either “pick-n-choose”, SMS-style  or an awkward-to-operate “virtual QWERTY” on-screen keyboard as their text-entry means. This may be of concern if one of these devices is being used to instantiate a hotspot session at a pay-to-use or membership-driven hotspot. This limitation would also make it more difficult to use one of these devices to set up or add devices to a trusted group and it would make it increasingly difficult to establish a local-network gaming session between a group of friends that are using handheld gaming consoles at a fast-food joint for example.

The IT industry could look towards answering this problem through use of UPnP or similar technologies for managing the provisioning of hotspot sessions to end-users and establishment and management of trusted device groups that override hotspot client-isolation setups amongst only the members of those groups.

Send to Kindle

Leave a Reply