Although the details vary between installations, all hotspots have essentially the same architecture. The components are:
Subscribers
Access points to provide the wireless coverage
Hotspot controllers to provide access control
Authentication server to verify legitimate users
Local content intranet services
Public Internet services
Figure 14.1 shows how these components relate to each other. It is interesting that the use of the hotspot controller and authentication server is similar to the concept of the authenticator and authentication server in IEEE 802.1X. But note that most deployed hotspots do not use IEEE 802.1X today. In fact, most use no security measures at the Wi-Fi LAN level.
The following sections describe each of these components. The actual physical location of the various functions varies from system to system, as do the methods used to authenticate the user. However, the basic functions and requirements are more or less the same in each case.
In Figure 14.1, the subscriber and access point equipment are often completely standard IEEE 802.11 components?the same type you might buy to install in your office or even at home. The use of standard components is especially useful at the subscriber end. Ideally, you don't want customers to have to add any new software or hardware to their system to connect. For instance, they may want to subscribe to several services and they may use Wi-Fi LAN at the office. They will not want to have to purchase and carry around a special Wi-Fi LAN card for each hotspot they plan to use. In addition, people are very concerned about installing new software, especially drivers. They are understandably worried that, after they install the software for the hotspot, their Wi-Fi LAN will no longer work back at the office.
Requiring special hardware and software on the user's laptop computer also blocks the impulse purchase effect that is so powerful in this business. A classic example is when you are at an airport and your plane is delayed. You have several hours to kill, and you see a booth offering Internet access for $5 per hour. You sign up there and then. Hotspots can get lots of new customers this way, but many potential customers won't join if they first have to load special software.
The down side of the "no new hardware/software" approach is that it is very difficult to provide a seamless service. Seamless means that the system connects and registers automatically whenever the user moves into a hotspot. This is the sort of behavior you expect from a cellular phone, for example. By contrast, most hotspots require you to go through a login phase using a Web browser prior to getting access?not a great hassle until you forget your password, but an extra step nonetheless.
Currently, if you want to provide automatic registration to the network, you need to install special components onto the laptop. One interesting approach introduced by the mobile phone industry is to have a Wi-Fi LAN adapter with a slot to insert a GSM SIM card, which is the same type of smart card used in GSM cellular phones. In this case the system really can operate seamlessly and automatically identify and connect to hotspots without user intervention. One major vendor, Nokia, has introduced a combined cellular data/Wi-Fi LAN adapter so the system can switch back and forth between hotspot and cellular coverage, giving constant network access. However, approaches like this clearly need to be preconfigured and installed before you go on the road.
When IEEE 802.11i is deployed, there will be a new opportunity to provide seamless access through IEEE 802.1X. Popular operating systems will probably have built-in support for IEEE 802.1X, including operation over IEEE 802.11i. In the future, you can expect all the authentication software to be built into laptops at the factory. All you will need to do, when subscribing to a Wi-Fi LAN service, is to purchase a digital certificate for the service. After that, connection will be automatic.
For the most part, the access points used in wireless hotspots have the same features as those used at home or in the office. Typically, WEP encryption is not used and authentication is the responsibility of the hotspot controller. While conventional access points can be used "off the shelf," vendors have started to introduce access points customized for use in hotspots. The mechanical design of the unit needs to be more robust and more tamperproof if located in a public area. You don't want screw-in antennas sticking out, for example, or you are likely to find that some curious child will screw them out and wander off. Also, you don't want the unit festooned with flashing colored LEDs because this just attracts unwanted attention. Many sites solve these problems by mounting the access points in a closet or a locked box, but new streamlined access points with integrated antennas are now available for direct mounting on a wall. The radiation pattern of the antenna might be different from an access point designed for the home, radiating mostly in one direction, for example, so the access point can be mounted at the end of a room.
One area often overlooked by system designers is how the access point shares information between users. In a conventional Wi-Fi LAN, a broadcast message sent by one mobile device is transmitted by the access point to all the other mobile devices. This is the meaning of broadcast. But in a wireless hotspot, you may not want this to happen. For example, upper-layer networking protocols such as Microsoft's Network Neighborhood use multicasts to advertise network file systems to other devices on the same LAN. However, in an airport you don't want your file system to be advertised to a bunch of strangers sitting in the gate area. Of course, you can disable network sharing in your laptop, but most people forget or don't know how. Therefore, it is helpful if the access point in the hotspot is smart enough to block the redistribution of such broadcasts to the whole hotspot.
The access points must be connected to the hotspot controller. Usually, this is done using wired Ethernet. If there are multiple access points, they will typically be connected together on a shared LAN using a hub. These wired connections are a source of weakness from a security standpoint. Physical security of the wires and hubs connecting the access points might be low. It could be easy for an attacker to find the hub in a closet and connect a laptop to it using a spare port. Assuming it is a shared LAN hub, it would then be easy for them to intercept all the data flowing into the hotspot. Even if WEP or RSN were used to protect the transmission on the wireless side, it would not protect against this type of interception because it occurs after the access point has decrypted the data. The attacker could also record authentication transactions for later analysis or even forge messages from a subscriber who is authenticated. This weakness in wiring plant security is a major headache for hotspot security in general.
The hotspot controller is the key component that makes the hotspot possible. There are many functions it has to perform, including:
User authentication
Collection of billing information
Tracking usage time where subscription is time limited
Providing local IP addresses
Filtering requests to allow free access to certain servers and Web sites
Emulating e-mail services to allow mail forwarding
Emulating DNS name resolution
We have shown the hotspot controllers as independent boxes in Figure 14.1. However, while companies do sell self-contained hotspot controller units, hotspot controller functions can be implemented in other ways. For example, a small site may have only one access point, and the controller functions would be at a remote location connected by a frame relay link. In the case of such a small site, the access point itself could incorporate the controller functions as well. There are also solutions that make use of an ordinary PC to act as a controller. This section focuses on the functions rather than where they reside.
If the operator is charging for access, user authentication is obviously a key feature. The most common approach so far is to require login via a Web page. The idea is that when the subscriber connects and brings up a Web browser, she will always get the login screen presented, regardless of what URL she actually requested. For example, if she enters www.favoritefish.com in the browser, she will be diverted to the hotspot login screen. The controller has to do a bit of trickery to accomplish this redirect.
The access points are run in open mode without WEP encryption or authentication. Therefore, with a suitable wireless card, anybody can connect to the hotspot network. The controller will give any connected device an IP address upon request so the newly connected device can start sending packets to the Internet. However, all the packets go through the controller. And it will not forward them to the real Internet until you have logged in. The controller inspects your packets, looking for Web requests; and when it sees one, it diverts it to its own internal Web server, which presents the login screen instead. Your browser is unaware that this has happened and presents the login screen as if it came from the real Web site.
After you have entered your user name and password, or whatever is required, the controller stops intercepting your packets and forwards them to the Internet. Some controllers may store your original request and then forward it after the login so you get your requested Web site automatically after the login screen.
The use of Web login also allows security features in the browser to be used so the information for the login is protected. This results in the browser displaying "https://" in the URL address and gives you some guarantee that the hotspot is legitimate and not itself a bogus operation.
In many cases the controller will allow access to certain Web sites without having to log in. These are known as white-list sites. For example, an airport might allow access to the airlines' Web sites or a supermarket might allow access to their advertising sites.
In some circumstances, login via the browser might be a nuisance or a problem. If you are moving from one hotspot to another, you might be forced to log in each time because each has a separate controller. Worse, if your PC is configured to use virtual private networking (VPN), you might not be able to log in at all because the controller would be unable to decode your Web site requests. In such a case, you must turn off the VPN feature, log in, and then reenable VPN before proceeding. There are various proprietary schemes that allow the authentication process to occur automatically, avoiding the need to log in via the browser. As previously mentioned, these schemes generally need to be configured in advance or use some special hardware. The availability of RSN and IEEE 802.1X provides the opportunity for automatic authentication without using the browser. Imagine that your laptop has built-in support for IEEE 802.11i (RSN), IEEE 802.1X, and EAP/TLS authentication. If you were to purchase and install a client digital certificate for your laptop, you would be able to go to any hotspot and log in transparently. You could probably purchase the digital certificate over the Internet from a Web site that, naturally, would be on the controller's white list. This, of course, assumes that the hotspot has support for RSN, but it does show how hotspots in the future can become easier to access.
The credentials of each subscriber have to be stored in a central database for verification. As outlined in Chapter 8, EAP and IEEE 802.1X allow the subscriber to negotiate access directly with the central authentication server. However, in most existing hotspots the credentials are first collected by the hotspot controller and then verified in a separate transaction between the controller and the authentication server. From an architectural standpoint, those hotspots that require subscribers to log in with a user name and password look very similar to a dial-up modem pool. When you connect to the Internet via a dial-up modem, you (or you computer) transfer your user name and password to the modem pool controller, which then uses RADIUS to verify your access rights. In is natural, therefore, that the hotspot controller will also use RADIUS for this purpose. In fact, this is one advantage of the user name/password scenario for hotspots: Existing authentication server databases can be used. In principle, the same authentication server could support both dial-up and hotspot sites.
An interesting situation exists for the hotspots based on cellular phone authentication. When cell phones were first introduced, the cellular phone industry had the same problem to resolve for user authentication and billing of mobile users. It needed a system that would allow you to roam in and out of cell sites and be identified and connected automatically. The industry now has a huge installed network that, quite clearly, works well. The idea of using a GSM SIM card or U.S. cellular equivalent in the Wi-Fi LAN adapter is that you can tap into that huge existing customer authentication and billing system. In this case the hotspot controller needs to be able to interface with and talk to the cellular phone authentication server. These servers use their own protocols designed for the cellular industry and are not based on Internet protocols. To implement such a system, therefore, a special type of authentication gateway server is needed to bridge between the Internet network and the cellular network. The hotspot controllers may still use RADIUS to communicate with this gateway, and it will convert the RADIUS requests into the appropriate form for the cellular system. The cellular authentication server will see the Wi-Fi LAN user as if it were another cell phone.