Design problems

Now we will take a look at the various design problems which we are facing. Solutions to these problems will be discussed throughout the rest of this document. The solutions to these problems will be discussed in the next chapter, where the implementation of the system is discussed.

3.2.1. Where to put the functionality

The first thing we have to look at is the various hardware subsystems of the system, deciding where to put the intelligence of the system. Aspects such as performance and ownership of sources play a role in these decisions. This problem deals with where to implement the various pieces of function- ality of the system. We can do this either in the access points, which are located on the hotspots (hotels, restaurants, etc), or we can choose to implement as much as possible in the central Mobidot system. If we choose to implement everything in the access points this might have some negative implications. First of all, if the access points are going to be Linux based, then any additions to the firmware of the access points falls under the GPL (General Public License), just as the firmware it- self. As such, this means the sources of the additions have to be shared with the general public if the access point with the firmware is to be sold to other parties (as opposed to using it only internally). Second of all, the firmware might become heavy in terms of resource usage and this might negat-

ively affect performance. On the other hand, we cannot implement everything on the central Mo- bidot system, since we need to have some minimal running system on the access points. All in all, for all pieces of functionality individually, one must choose where to implement this.

3.2.2. Network of multiple access points

A different problem to look at is the structure of the wireless network at one hotspot location. In most cases, a hotspot will be small enough to be handled by one access point. It might however, be possible for a hotspot to need more than one access point in order to have coverage on the entire loc- ation, this might for example be the case with camp sites. The problem to solve here is how we des- ignate the various access points. Do we manage them all as stand alone units, or do we look at them from a master-slave point of view, i.e. do we designate one as a master and the rest as slave? In the latter case, we would manage the master access point from the central management system, and the rest from the master access point (preferably automatically while managing the master access point). In the former case, we would manage each access point as though it is the only access point for that hotspot. In this case, we need to implement less in the access point itself, which relates to a problem discussed earlier. Related to this problem is the choice of how to interconnect the various access points. It is possible to interconnect them using an UTP network, but this has a substantial disad- vantage: it needs a wired network. It would be much more elegant to interconnect the access points using a technology they have already on board: wireless IP technology a.k.a. 802.11. In this case the limiting factor is performance: can we use the wireless channels both for interconnection of access points, as well as transport of user data, and still provide a reasonable throughput for user data?

3.2.3. Security

Another problem, which had quite much coverage in the media, is security. It is quite well known by now that existing security measures for wireless 802.11 based networks are not sufficient or inef- fective all together. New approaches are undertaken to create new security measures for 802.11 based networks, and these approaches are described in the 802.11i standard. The standards describ- ing these approaches are however still not finalized, meaning we are currently in a sub-optimal situ- ation: we know existing security measures are ineffective, and we know that new solutions are avail- able, but aren't finalized yet, meaning that it's not incorporated into hardware on a large scale (changes to the draft standard would make that hardware unusable), especially in client hardware. If it is incorporated however, it is done so based on a certain version of the draft standard, and this could potentially make an access point of one brand incompatible with one of another brand. All in all, we can choose to apply 802.11i security measures, which means we exclude a group of clients from having access to our systems. On the other hand, we could choose to give only minimal native security support, but provide security add-ons, such as the ability to create a VPN (Virtual Private Network) between the client hardware and the access points.

3.2.4. Hardware and firmware

A different problem is the choice of certain hardware to use as access points, and the choice of using a build root from a specific distributor. A build root is a directory structure which is filled with all sources needed to create the firmware, i.e. sources for the build tools and sources for the software which needs to run on the firmware. At first, a build root is only available from the vendor of the particular hardware solution, but later on alternatives may arise, due to the fact that some hardware solutions are Linux (GPL) based. One needs to choose between various hardware based on specific

needs. Further, one needs to choose between possibly various build roots, usually based on which software tools are already available within the firmware. But the choice is also based on the flexibil- ity of the firmware. Is it easily extended? How easy is it to remove existing features in order to make room for new features? How easy is it to perform upgrades once the firmware is running in produc- tion? These questions need to be answered for available build roots, in order to make a well in- formed choice.

3.2.5. Configuration deployment

We also need to deal with another problem, namely the deployment of configurations on the various access points. Due to the fact that the access points run off-site, they need to be self-maintaining, and this means that configurations for various software tools need to be deployed automatically. Such configurations include firewall scripts, traffic shaping scripts, etc. Some of these configura- tions are globally the same, some are specific for each access point. We need a way to easily deploy these configurations at each access point, including the knowledge of which access point we are dealing with. Another question is whether all configurations can be deployed automatically. For some configurations it might be needed to get settings from the manager of the location hosting the hotspot, and this information might be privacy sensitive. One could choose to maintain such settings on a central server, and possibly encrypt it. But then it is still easily vulnerable to theft. One could also choose to have the manager of the hotspot location enter the information manually into the ac- cess point, while the access point is installing itself for the first time (on site).

3.2.6. Maintenance and monitoring

Reachability of the access point (the SNAT circumvention problem as discussed in the first chapter) is another problem to deal with. In most situations, the access point will be the device in the network which will connect to the Internet, making it directly reachable for outside devices. It is however possible for devices to be placed deeper inside an already existing network. In this case there are two possibilities: the first possibility is the device to have a non-private Internet IP address, in which case the access point is also directly accessible. The other possibility, which is much more common, is that the access point receives an IP address from a private range (which means these IP addresses are not usable for Internet traffic, but only for local IP traffic), and the device's address is translated (Network Address Translation) at the gateway. In this case our access point is not directly reachable. If we want to connect to the access point from our central management server, certain rules have to be setup on the gateway or some kind of permanent tunnel through the firewall should be setup in order to make the internal machine (in this case an access point) reachable from the Internet. This problem exists for various protocols, i.e. for remote command shells, such as SSH (Secure Shell), but also for the monitoring protocol SNMP (Simple Network Management Protocol). For the latter protocol, it is needed to run an agent on the device which is being monitored, this agent needs to be talked to by a central monitoring daemon, where the monitoring daemon initiates the conversation (as a client). These protocols could not be used if no special measures would be taken.

3.2.7. Interoperability

The last problem to address is the problem of interoperability with other WISPs. We want to allow customers of these WISPs access to our wireless networks, if we have a roaming agreement with such a WISP. The first problem is how to authenticate these users. In general for authentication pur- poses an AAA server (Authentication, Authorization and Accounting) is used. There are three types,

with several existing implementations in some cases: RADIUS, TACACS+ and Diameter. So the problem to solve here is which AAA server to use, and whether or not to maintain interoperability with other AAA server types, if it is even possible for that matter.