design hotspot with opensource tools

Design and implementation of ahotspot network

independent of Wi-Fi service providersE.E.J. Vonk

<[email protected]>

Table of Contents1. Introduction ...................................................................................................... 1

1.1. The assignment ....................................................................................... 11.1.1. Problem Description ...................................................................... 11.1.2. Project Description ........................................................................ 2

1.2. The problem domain ................................................................................ 21.2.1. What is Wireless-Fidelity? .............................................................. 21.2.2. History of Wi-Fi ........................................................................... 41.2.3. The problems that we are trying to solve ........................................... 6

1.3. Project goal ............................................................................................ 81.4. Project approach ..................................................................................... 91.5. Social and scientific relevance ..................................................................10

1.5.1. Social relevance ..........................................................................101.5.2. Scientific relevance ......................................................................10

1.6. Used terminology and conventions ............................................................101.6.1. Terminology ...............................................................................101.6.2. Conventions ...............................................................................11

1.7. Document outline ...................................................................................112. Analysis ..........................................................................................................13

2.1. Requirements elicitation ..........................................................................132.1.1. Purpose of the system ...................................................................132.1.2. Scope of the system ......................................................................132.1.3. Objectives and success criteria of the project .....................................132.1.4. Current System ............................................................................132.1.5. Proposed System .........................................................................14

2.2. Further analysis .....................................................................................162.2.1. Network topologies ......................................................................172.2.2. Defining the actors .......................................................................272.2.3. Defining the various uses of the system ............................................292.2.4. Defining the data model ................................................................42

3. Design ............................................................................................................453.1. Defining the design goals .........................................................................45

3.1.1. Design goals ...............................................................................453.2. Design problems ....................................................................................46

3.2.1. Where to put the functionality ........................................................463.2.2. Network of multiple access points ...................................................473.2.3. Security .....................................................................................473.2.4. Hardware and firmware ................................................................473.2.5. Configuration deployment .............................................................483.2.6. Maintenance and monitoring ..........................................................483.2.7. Interoperability ............................................................................48

3.3. Proposed software architecture ..................................................................493.3.1. Overview ...................................................................................493.3.2. Subsystem decomposition .............................................................493.3.3. Hardware/software mapping ..........................................................50

v

3.3.4. Persistent data management ...........................................................513.3.5. Global software control .................................................................52

3.4. Designing the subsystems ........................................................................523.4.1. UserManagement subsystem ..........................................................523.4.2. Storage subsystem .......................................................................56

4. Implementation ................................................................................................594.1. Solutions for the design problems ..............................................................59

4.1.1. Where to put the functionality ........................................................594.1.2. Network of multiple access points ...................................................594.1.3. Security .....................................................................................604.1.4. Hardware and firmware ................................................................674.1.5. Configuration deployment .............................................................744.1.6. Maintenance and monitoring ..........................................................744.1.7. Interoperability ............................................................................79

4.2. Implementation ......................................................................................824.2.1. Implementing the management system .............................................824.2.2. Implementing the firmware ............................................................84

5. Evaluation .......................................................................................................875.1. Test setup .............................................................................................875.2. Test procedure and approach ....................................................................87

5.2.1. Development tests ........................................................................875.2.2. Pilot tests ...................................................................................88

5.3. Test results ............................................................................................885.3.1. The firmware ..............................................................................885.3.2. The management system ...............................................................895.3.3. Results of system testing ...............................................................89

6. Conclusions .....................................................................................................916.1. Project specific conclusions ......................................................................916.2. General conclusions ................................................................................92

A. References ......................................................................................................95A.1. Books ..................................................................................................95A.2. Articles and other documents ...................................................................95A.3. Various references ............................................................................... 102

B. Used acronyms .............................................................................................. 105C. Extra project information ................................................................................. 111

C.1. Used tools .......................................................................................... 111C.2. Needed preliminary knowledge .............................................................. 112

C.2.1. Networking concepts ................................................................. 112C.2.2. Cryptographic concepts .............................................................. 115

D. Project supporting documentation ..................................................................... 121D.1. Globalplan for Mobidot thesis project ...................................................... 121D.2. Risk analysis for Mobidot thesis project ................................................... 122

vi

List of Figures1.1. WLAN with one access point ............................................................................ 31.2. Mobidot network with a centralized management system ........................................ 92.1. Centralized architecture [Webopedia1] ...............................................................172.2. Star architecture [Webopedia1] .........................................................................182.3. Bus architecture [Webopedia1] .........................................................................182.4. Decentralized architecture [Minar2002] ..............................................................182.5. Mesh architecture [Webopedia1] .......................................................................192.6. Hierarchical architecture [Minar2002] ................................................................192.7. Ring architecture [Minar2002] ..........................................................................192.8. Centralized+Ring architecture [Minar2002] .........................................................202.9. Centralized+Centralized architecture [Minar2002] ................................................202.10. Centralized+Decentralized architecture [Minar2002] ...........................................212.11. Tree architecture [Webopedia1] .......................................................................212.12. Mobidot Infrastructure Situation 1 ...................................................................252.13. Mobidot Infrastructure Situation 2 ...................................................................262.14. Mobidot Infrastructure Situation 3 ...................................................................272.15. Involved systems, their dependencies and responsible actors .................................282.16. Use case diagram group 1 ...............................................................................292.17. Use case diagram group 2 ...............................................................................302.18. Sequence diagram for use case: CreateNewAccount ............................................312.19. Sequence diagram for use case: CreateNewAccount (part 2) .................................322.20. Sequence diagram for use case: ManageFirmware (add) .......................................342.21. Sequence diagram for use case: ManageFirmware (add, part 2) .............................352.22. Sequence diagram for use case: ManageHotspotsAndAPs (view) ...........................362.23. Sequence diagram for use case: ManageHotspotsAndAPs (view, part 2) ..................362.24. Sequence diagram for use case: ManageConfigurations (edit) ................................372.25. Sequence diagram for use case: ManageConfigurations (edit, part 2) ......................372.26. Sequence diagram for use case: ManageAccounts (delete) ....................................382.27. Sequence diagram for use case: ManageAccounts (delete, part 2) ...........................392.28. The data model ............................................................................................433.1. Subsystem class diagram .................................................................................493.2. Deployment diagram .......................................................................................513.3. UserManagementModels class diagram ..............................................................533.4. UserManagementGUI class diagram ..................................................................553.5. UserManagementControllers class diagram .........................................................563.6. ConfigurationStoreSubsystem class diagram ........................................................564.1. 802.1X authentication process [Open1X1] ..........................................................654.2. Netgear WG602 access point [SeattleWireless1] ..................................................684.3. Netgear WG602 access point (internal view) [SeattleWireless1] ..............................684.4. Linksys WRT54G access point + router [SeattleWireless2] ....................................694.5. Linksys WRT54G access point + router (internal view) [SeattleWireless2] ................704.6. Soekris net4801 [Soekris3] ...............................................................................714.7. Soekris net4801 (internal view) [Soekris3] ..........................................................714.8. SSH tunneling ...............................................................................................79C.1. OSI reference model [Tanenbaum1996] ........................................................... 112

vii

C.2. TCP/IP and OSI network stacks [Tanenbaum1996] ............................................ 114

viii

List of Tables2.1. Evaluation properties for several network topologies .............................................242.2. Use case CreateNewAccount ............................................................................312.3. Use case Login ..............................................................................................322.4. Use case UseSystem .......................................................................................332.5. Use case ManageFirmware (add) .......................................................................342.6. Use case ManageHotspotsAndAPs (view) ...........................................................352.7. Use case ManageConfigurations (edit) ...............................................................372.8. Use case ManageAccounts (delete) ....................................................................382.9. Use case PutHotspotDownForMaintenance .........................................................392.10. Use case SendNetworkAnnouncement ..............................................................402.11. Use case SetupAP .........................................................................................412.12. Use case RetrieveUsageStatistics .....................................................................42

ix

Chapter 1. IntroductionThis project is called 'Design and implementation of a hotspot network' and forms the second part ofthe thesis project. It started with a research assignment named 'How to deploy a Wi-Fi service pro-vider independent hotspot network?'. This document will describe the second part of this thesisproject.

1.1. The assignmentSince a couple of years a lot of new developments have taken place in the field of IT. Two of these(relevant to this thesis assignment) are:

• The rise of Open Source Software (OSS).

• The rise of wireless Internet access at so-called 'hotspots'.

The first development, the rise of OSS, causes the increase of usage of OSS in commercial products.Due to the licensing conditions of OSS, the source code of the commercial software needs to befreely available. This offers interesting opportunities.

The second development (the development on which this assignment is based), is the introduction ofwireless Internet access. A so-called 'hotspot' is a location that offers wireless Internet access to any-one using a laptop, PDA, etc. The wireless Internet access is based on the 802.11 Wi-Fi standard.Devices conforming to this standard are used more and more in mobile devices such as laptops andPDAs. Public institutions are getting equipped with Wi-Fi (are being transformed to hotspots), suchas hotels, restaurants, airports, train stations, trains, but the technology is also available within com-panies. At these locations quick and easy access to the Internet is assured by Wi-Fi technology.

A few companies put up and maintain hotspots, such as T-Mobile, KPN and Swisscom. In generalthese hotspots are composed of a local network and a remote central server. The largest problem isthe fact that such systems differ for each Wi-Fi provider and thus are hard to interconnect. Each pro-vider uses its own methods of logging in and has different rules when it comes to the usage of thehotspots. The one might require downloading software in order to use the wireless network, the oth-er might only use readily available hardware and software and is insecure because of that.

Mobidot is a company which is run by Joost Hietbrink en Michele Nijhuis, the suppliers of this as-signment. The development of software which manages wireless networks is the core business ofMobidot. It is Mobidot's intention to put up a network of Wi-Fi hotspots, on which Wi-Fi providerscan offer Internet access to their customers.

1.1.1. Problem DescriptionProviding a continuous, fast and low cost Internet connection is what competitors are trying toachieve with the deployment of hotspots. To achieve this goal, several problems have to be solved: auser should be able to make use of the hotspot in the same way at each hotspot of each provider. Todeploy as much hotspots as possible, the costs for deployment and maintenance of hotspots shouldbe reduced.

1

1.1.2. Project DescriptionDesign an appropriate model for the network architecture of a hotspot. All problems describedabove should be solved with this model. In more detail this means using OSS and budget hardwareto achieve compatibility and cost reduction. Develop a prototype of the network architecture and ofa management system that will monitor and manage this architecture.

1.2. The problem domainAround 1995, connectivity (with connectivity in this document is meant: having the possibility toconnect to some public computing network such as the Internet) wasn't part of common life. Peopleused to communicate with one another by means of letters, telegraphy and telephone. With the intro-duction of computers this gradually changed. First some computers were connected to create a net-work called ArpaNet, initiated by American military and educational institutions. Later on, in thenineties, the Internet was formed out of the former ArpaNet, connecting computers to each otherworldwide, creating a huge network of computers. The Internet introduced connectivity to the home.Anyone with a desktop computer at home was able to connect to anyone else by the Internet, in amatter of minutes. Nowadays, there is again a shift in the field of connectivity. It's not just possiblefor anyone to connect to the worldwide network, it is possible for anyone to do this from anywhere,and at any time. With the introduction of technologies such as GPRS, UMTS, and Wi-Fi(Wireless-Fidelity), mobile access to the Internet has become possible. The last of these technolo-gies, Wi-Fi (also known as WLAN), will form the basis for this project.

1.2.1. What is Wireless-Fidelity?

"How many times have you needed network or Internet access at home andwished you could work in a different room, or even outside, without having to runa long Ethernet cable? How many times have you been in a public spot, such as anairport or hotel, and realized you needed to send a quick e-mail? How many hourshave you wasted sitting in conference rooms between meetings while your e-mailspile up?" [Roshan2003]

Wireless Fidelity is a relatively new technology which enables people to connect to IP networks(such as the Internet) without any network wires connected to their computer. Wireless digital com-munication is not new, other wireless technologies such as HAM-radio and Aloha have been aroundfor a long period. There were several reasons why these technologies didn't become popular: theywere expensive, they were not easy to use (mainly used by specialized individuals and enthusiasts)and they offered a much lower bandwidth compared to wired networks. This all changed with theintroduction of Wireless Fidelity (or Wi-Fi).

Wi-Fi can operate in two modes: infrastructure mode and ad hoc mode. Ad hoc mode (referred to asIBSS, or Independent Basic Service Set) refers to direct connections between exactly two com-puters, with the same possibilities as a serial cable. Infrastructure mode is the more interesting modeof Wi-Fi: it basically works the same as an ethernet, without using network wires. This mode iswhat the name WLAN (Wireless Local Area Network) refers to.

2

Figure 1.1. WLAN with one access point

In this mode, several computers can be interconnected, in order to exchange information and data,just like you would on a wired network. One computer in the network could even be designated tobe a gateway machine, enabling any computer on the network to access an outside network such asthe Internet. In the infrastructure mode, there is a central component, called the access point. Infra-structure mode is also referred to as BSS (Basic Service Set). When multiple access points are usedto create one WLAN, this mode is called ESS (Extended Service Set). All computers that wish tohave a wireless network connection (from now on called wireless clients), associate (make a con-nection and authenticate) with this access point. This can only be done when the device with Wi-Ficapable hardware is in the range of the access point, which is limited to 300 meters outdoors, and atmost 100 meters indoors (depending on the amount of walls that are in between the wireless clientand the access point). Once a connection with the access point is established, the wireless client canbegin performing network operations, just like in a wired network. And just like on a wired network,clients of wireless networks will have to share the available bandwidth. Wi-Fi introduces advant-ages, some of which include the fact that wires are no longer needed to interconnect all computers ofa network. Furthermore, anyone with a portable computer with Wi-Fi capable hardware can connectbe part anywhere in the coverage area of the access point and access the local network and possiblyalso external networks.

Wi-Fi is defined in one of IEEE's standards: 802.11.

"802.11 refers to a family of specifications developed by the IEEE for wirelessLAN technology. 802.11 specifies an over-the-air interface between a wireless cli-ent and a base station or between two wireless clients. The IEEE accepted the spe-cification in 1997." [Webopedia2]

3

Wi-Fi is known by many different names. Each of the following names refer to the same base tech-nology, without referring to any particular implementation or specification: Wireless-Fidelity, Wi-Fi, 802.11, WLAN. Further, there are specifications under 802.11 whose names are usually used inorder to denote any implementation of such a specification. At this moment there are the followingspecifications:

• 802.11: The original specification of 1997. This specification defines a transmission speed of 1or 2 MBps and an operation frequency of 2.4 GHz. In most cases, when 802.11 is referred tonowadays, any of the specifications discussed below is meant instead of this original specifica-tion.

• 802.11b: This specification was approved by the IEEE in 1999 and defines a transmission speedof 11 MBps and the same operation frequency as 802.11, 2.4 GHz. Originally the term Wireless-Fidelity (or Wi-Fi) denoted this specification, but with the introduction of even newer specifica-tions, this changed. Wi-Fi now refers to the implementation of any of the specifications of the802.11 standard.

• 802.11a: This specification was added in order to achieve a much higher speed than 802.11b: 54MBps. But in order to achieve this speed, it was chosen to use another frequency band: 5 GHz.This decision meant that existing hardware would be incompatible, and couldn't be used toachieve this speed.

• 802.11g: Finally, this specification was added as it was realized that 802.11a wasn't gaining pop-ularity, mainly due to the fact that new hardware was needed. Especially access points offeringpublic access were equipped with hardware implementing the 802.11b standard, and as suchweren't able to handle client hardware that implemented the 802.11a standard. To overcome this,the 802.11g standard was devised. This specification defined a speed of 54 MBps in the 2.4 GHzband, which made this standard backward compatible with 802.11b. With hardware implement-ing this specification people were able to both connect to newer access points implementing the802.11g standards (supporting the 54 MBps transmission speed) and to older access pointswhich only supported 802.11b.

1.2.2. History of Wi-FiWhen Wi-Fi was first introduced, it wasn't foreseen it could gain such a popularity it has now. Prob-ably one of the main reasons why Wi-Fi was introduced was its ease of installation and use. It couldact as a replacement for wired networks, making it a lot easier to install home networks and(probably even more important) corporate networks. Not having to lay down wires in order to con-nect all computers in a home or office together would mean the installation and maintenance of sucha network is much easier, a new network could be installed in a matter of minutes.

Sharing an existing Internet connection with several people was an advantage that initiated the pop-ularity of Wi-Fi. People would have the ability, for example, to share their Internet connection withtheir neighbors. Since the Wi-Fi radio signal has a range of 100 meters and sometimes even up to300 meters, this could easily be done. The only thing needed is an access point that covers all neigh-bors that want to participate, and having those neighbors acquire a wireless network card for theircomputer. This setup would give the involved parties one great advantage: since there is one Internetconnection used by several parties, the costs for that connection would also be divided among theparties.

4

This way of Internet connection sharing more or less lead to another new approach, which was im-plemented mostly by students in some student cities, including Leiden in the Netherlands (see[WirelessLeiden1]) and Seattle in the United States (see [SeattleWireless3]). In this case, access to acertain access point would be freely and publicly available. To denote an area which had coverageof a publicly accessible access point, the term hotspot was introduced (in most cases, a spot is con-sidered to be an infinitely small dot, or at least too small to be a circle or oval. In this case, a hotspotrefers to the coverage area of an access point which has a radius of 100 up to 300 meters. Normallythis would be called a circle, but in comparison to the size of the already existing Internet, this cov-erage area is indeed very small, and thus called a spot). But this wasn't all, all these hotspots wouldbe interconnected using the same air-to-air interface or possibly some using wires. This would cre-ate a giant LAN (Local Area Network) which introduced the possibility of creating a socialist-typeof network: sharing data (music, movies, games, etc) free of charge. This would be very interesting,as it wouldn't be needed to connect to the Internet to find any music or movies. And it would lead tosome advantages, such as not incurring high bandwidth costs of normal Internet connections andhaving a smaller possibility of the file sharing connections being tapped by authorities, risking pen-alties for copyright infringement, etc. Anyone with a laptop would be able to make sure he would bein the coverage area of a hotspot, connect to the network and start sharing data.

Like with all good ideas, it didn't take long before a commercial implementation was given birth. Itwas soon realized that there was a need for Internet access (for business people, students, etc) out-side home, business or university. Some time after a failed start up by Mobistar in the 90's (using theoriginal 802.11 standard), some small parties, called WISPs (Wireless Internet Service Providers),started installing access points (using the 802.11b standard) at public meeting places, such as cafes,restaurants, hotels, libraries, etc. The term hotspot would from then on refer to a public place thatimplemented a publicly accessible wireless network. The access point would be connected to the In-ternet using either an existing Internet connection, or a new Internet connection would be acquired.Furthermore, the access to the wireless network wouldn't be free of charge, but would be chargedfor, by the hotel, restaurant, etc. in question. With the introduction of such commercially accessiblehotspots, interesting opportunities became possible. It would be possible to place hotspots in restaur-ants along highways which are used a lot by business people. These business people would then beable to make a stop over between one appointment and another at such a restaurant, and be able tocheck their email, enter information into a corporate system about the last appointment, etc. Or itwould be possible to equip hotels with publicly accessible access points, and enable business peoplestaying over at that hotel for a conference to perform tasks that otherwise would have to wait untilthese people would return from the conference.

This commercial approach started small. Most large companies are usually hesitant to take the firststeps in a completely new market, in which successful involvement is uncertain. This meant thatseveral small parties first started initiatives, slowly implementing more and more public places withhotspots. Once the business gains were recognized by large corporations (mostly telecommunicationproviders), these corporations would buy out the small WISPs, to take over their market share, andstart expanding from that point on. A good example of this in the Netherlands was Hubhop, whichwas initiated in May 2002, and by May 2003 was bought by KPN, the largest telecommunicationprovider of the Netherlands.

The buyout of small WISPs by large corporations meant the initiation of a widespread implementa-tion of public hotspots. At this moment, there are three major parties (and some minor parties) in theNetherlands offering Internet access over public hotspots: KPN Hubhop, T-Mobile and SwisscomEurospot, and each of these parties is independently implementing public hotspots.

5

1.2.3. The problems that we are trying to solveWe observe that the Wi-Fi world is fragmented, possibly because Wi-Fi is still an immature techno-logy. We see home user systems being backed by large corporations such as Linksys (daughter com-pany of Cisco). For public hotspot systems we however see no systems from large corporations. No-madix, which is rather expensive (in terms of investments for managers of public institutions whichhouse the public hotspots), is not backed by some large corporation. It has such a dangerous marketposition, perhaps even more because their systems are quite expensive. In short, there's little tochoose from in the world of public hotspot systems. It would be nice to see a more diverse set ofsystems available, of which this project perhaps could be one. For example, when we look at sys-tems for cellular communication, why do Motorola, Siemens, Nokia and Ericsson all develop mo-bile phones? The technology they provide is not renewing (compared amongst each other), the com-ponents used for the transmissions are quite standard. Their approach to certain usability problemsor features however differs greatly. This is where they've got something to gain. The same goes forthe world of systems for public hotspots. While the core technology doesn't differ at all between sys-tems (we do want to maintain interoperability, at least the end user expects this), there are possibilit-ies for new systems by focusing on different features and problems. This however is only a market-ing problem/observation.

We will now go into more depth as to which technical (and sometimes technical and economical)problems exist. Basically, the problem that we observe is that there's no system that's extensible to alarge degree, that supports SNAT circumvention (i.e. adjustments needed in existing infrastructurein order to support management and monitoring of devices), supports zero configuration and whichis low cost.

SNAT circumventionThis plays a role with networking hardware, in the IP layer of the TCP/IP stack, where hardwareused in a network is placed behind a NAT-gateway. Before we can fully understand what the prob-lem is, we first need to look at what NAT actually is.

"Network Address Translation (NAT) allows computers on a private network toaccess the Internet without requiring their own global (public) Internet address.NAT modifies outgoing network packets so that the return address is a valid Inter-net host. Return (incoming) packets have their destination address changed back,and are relayed to the client host, thereby protecting the private addresses frompublic view." [MLIP1]

Network Address Translation is usually applied in order to perform Internet Connection Sharing:sharing one Internet connection with multiple clients on an internal network. Since normally eachnetwork client should be configured with its own unique IP address, we would run into a problem:the number of external IP addresses that are in possession of a certain person are usually less thanthe amount of network clients. In order to solve this, the network clients get a private IP address as-signed, an IP address that is not recognized on public networks such as the Internet, it has to betranslated to the public IP address of the network gateway (the gateway between the local networkand the Internet). When replies of traffic (initiated by a local network client) arrive at the gateway,the destination IP address of the reply is translated back to the private IP address of the respectivelocal network client, and the packet is forwarded to that network client. Two forms of address trans-lation exist:

6

• S(ource) NAT: the Network Address Translation process that was previously described, it cre-ates the possibility for internal hosts to access an outside network. Furthermore, it makes thesehosts unreachable for network devices on any outside network, since the internal hosts are notknown by a public IP address, this can either be an increase of security or a problem.

• D(estination) NAT: is the process of translating the IP address of traffic that arrives at the gate-way to the IP address of some internal host, and forwarding the traffic to that host. This is inher-ently different from SNAT, since in this case the network traffic doesn't get initiated by the in-ternal host but the external host. DNAT can occur on the transport layer, in which case one ormore TCP or UDP ports get forwarded to an internal host. DNAT can also occur at the networklayer, in which case all traffic for a certain external IP gets forwarded to an internal host. DNATcan be useful in situations where one might want to place servers behind a NAT-enabled fire-wall, either to decrease the number of needed IP addresses (DNAT on network layer), or to becertain that traffic to such a server is only possible on specified ports (DNAT on transport layer).

SNAT only has to be set up for outgoing traffic, replies to such traffic are automatically handled bya NAT daemon which maintains state tables in which logs are kept of all translated traffic. Theproblem usually plays a role on non-enterprise networks (i.e. home or small to middle sized businessnetworks), where SNAT is applied in order to give several machines access to the Internet. SNAT initself increases the security of the internal hosts and because the internal machines don't need to al-low incoming connections, they only setup outgoing connections. In most cases no DNAT has beensetup in order to make the internal machines reachable, as it is normally desired to have these ma-chines to be unreachable from the Internet. This however is a problem for Mobidot, as Mobidotneeds to monitor and access its access points, which it does by consulting certain daemons runningon the access points. In other words, we want to circumvent SNAT and make these daemons reach-able from the Internet (but without modifying the configuration of an existing infrastructure).

Zero configuration (Plug 'N Play)The problem of zero configuration is one particularly important problem to deal with. It is related tothe problem of SNAT circumvention: we don't want to bother the managers of public institutions. Itshouldn't be needed for them to do all kinds of configurations, ideally the system would be a zeroconfiguration: the manager places the access point, connects it to the Internet, and the access pointthen configures itself. Further, due to the fact that we need to connect to the Internet, we might needuser credentials if the access point is to be the main gateway. We need to get this information fromthe manager of the public institution and into the access point.

Low cost solutionThe last problem, with current systems, that should be mentioned is the costs for creating and main-taining a hotspot. Each WISP uses its own hardware, but current systems for such purposes are ex-pensive in three aspects. First, the hardware needed is quite expensive, and leads to a large invest-ment, for the owner of a public location (such as a hotel). The second and third cost aspects are theinstallation and maintenance costs. Due to the fact that current systems aren't flexible in local net-work layout (the previously discussed problem) and the fact they need to be configured locally forsome specific settings, introduces the need for a mechanic, which means extra investment costs. Be-cause hardware is not 'plug 'n play' means a mechanic will be needed for maintenance (read: supportcontract) also, in the case of problems or in the case of firmware updates of the access point hard-ware. This results into costs much too high for local businesses that want to add Wi-Fi as an extraservice beside their core business. Current systems allow for example hotels with rankings of threestars or more to invest in a current Wi-Fi solution. For hotels in the low end of the market there is nosuch possibility, while the visitors of such hotels (for example backpackers), might just as well (or

7

even more) be interested in wireless access. The situation even gets worse due to the fact of the ex-istence of multiple, non-interoperable, WISPs, as will be discussed below. All these costs might leadto a too uncertain return-on-investment, meaning businesses won't invest.

Furthermore, there are two problems which in itself don't make the project renewing, but do need tobe addressed in this project:

ExtensibilityThis isn't a problem that plays a role in competitive systems such as Nomadix, but it does need to betaken into account if a system is to be created which can last. Even though performance is sacri-ficed, extensibility is needed to keep up with the fast development in the world of Wi-Fi. It basicallymeans the entire system should be extensible, i.e. all different parts of the system. Even extensibilityin other directions have to be taken into account, for example: can the system that is created be runon different hardware? If the Nomadix system would only run on the current selected set of hard-ware, they would have a problem when that certain piece of hardware is not available anymore.

RoamingEach WISP implements the authentication of its users (checking whether a certain user is allowed touse the services of the network) in its own way, which makes roaming difficult. "Roaming is a gen-eral term in wireless telecommunications that refers to the extending of connectivity service in a net-work that is different from the network with which a station is registered. The canonical example of'roaming' is for cellular phones, when you take your phone to an area where your service providerdoes not have coverage (e.g., another country). In order for a mobile device to roam to another net-work, a number of processes need to be performed. The first necessity for inter-network roaming isthat your service provider must have a roaming agreement with the network to which you havemoved. In 802.11 roaming can also mean subscriber mobility or handover within the same network"[Wikipedia9]. This means that users are unable to roam to the networks of other WISPs. When, forexample, some hotels are equipped with T-Mobile hotspots and some others with KPN hotspots,then a client who has a KPN Wi-Fi subscription will be forced to find a hotel room in a hotel whichequips a KPN hotspot, while his preference for a certain hotel might force him into a hotel whichequips T-Mobile hotspots. This might be a problem for certain businesses, which already have apublic hotspot, but not with multiple WISPs. Since roaming in many cases is not possible, it wouldbe needed to pay for wireless access more than once, i.e. getting a Wi-Fi subscription with morethan one WISP. This is a inconvenience for the user. Clients of for example hotels and restaurantswill be more selective. Previously they would select a hotel by its ranking and perhaps its location.Now they will also take into account if they can have access to the network of their WISP. Thismight result into a drop of clients for certain hotels. The problem with roaming is mainly in combin-ation with the large investment costs. Roaming partnerships, such as Picopoint and Boingo do exist,but these equip expensive hardware and partnership costs as discussed above, and as such the roam-ing problem is not solved.

1.3. Project goalThe goal is to design and implement a prototype of the mentioned network architecture, in order tofacilitate a solution to the mentioned problem. This will be done using OSS and budget hardware.Some important requirements of this network include user friendliness, scalability, flexibility, com-patibility, robustness and low production costs.

8

Figure 1.2. Mobidot network with a centralized management system

The network architecture needs to be augmented with a management system from which the varioushotspots of the network can be monitored and managed.

In other words, the goal is to create a prototype of the two parts of the system (firmware that runs onthe access points and a management system that runs on the central server) and implement as muchrequirements as possible. A minimal running system should be delivered, while at the same timedesigning the system in such a way that enhancements can be implemented easily.

The main personal goal in this project is to learn many new things (both in terms of technology andin terms of project approach) as well as to look at various different approaches in solving problems,and try several approaches if the problem occurs multiple time. This relates not so much to the actu-al project contents, but it does relate to the project approach as will be discussed further on.

1.4. Project approachThis document describes the thesis project from inception to completion in chronological order. Theproject is divided into a number of phases. The first phase, the analysis, will look at the system. Inthis phase the problem domain is identified. The actors which play a role in the system are identi-

9

fied. An identification of the use of the system takes place. In the second phase, the design phase,the system is designed on an abstract level. The involved hardware is defined and described. The de-composition of the system into subsystems is described. The assignment of the various subsystemsto certain hardware is given. Further, choices regarding persistent storage are also decided upon inthe design phase. The design phase is followed by the implementation phase, in which the objectdesign and the actual implementation of the system is performed. Finally the evaluation phase fol-lows, in which the system is tested to see if it meets expectations.

Besides the creation of the system, the thesis project consists of the creation of a report documentingthe project. The basis for this report (notes, pieces of text, images) is created in-line with the project.The actual creation and finalization of the report takes place at the end of the thesis project.

1.5. Social and scientific relevance1.5.1. Social relevance

Being connected using wireless technologies is becoming more popular every day. More and morepeople are using wireless technologies every day. Wireless technologies are becoming a part ofpeople's lives, either personally or professionally or both. People are counting on wireless technolo-gies to be able to do their work more efficiently, resulting in a great dependence on these technolo-gies. The fact that the society is becoming wireless connected makes it socially relevant.

1.5.2. Scientific relevanceThe scientific relevance of this research lies in the same realization as stated before: being connec-ted using wireless technologies is becoming more popular. This popularity can result in a downfallof such a technology if no good structure is thought of to fit it all in. A scientific approach (as op-posed to the economic approaches taken by the various telecom providers) is needed in order to cre-ate a well-structured architecture. The structured approach using academic techniques, the use ofOSS and the new way of approaching the problem (top-down: from a general abstract overview to adetailed implementation; as opposed to the bottom-up approach applied by telecom providers: func-tionality is needed somewhere and later on at other places, eventually leading to an integrated,though not well designed, whole) is what makes this project scientifically relevant.

1.6. Used terminology and conventions1.6.1. Terminology

A lot of terms exist in the world of wireless networks, hereby is stated what is meant by each term.First of all a clear distinction needs to be made between access point and hotspot. Access pointrefers to the hardware device providing wireless access to other networks or to other wireless cli-ents. Hotspot refers to the coverage area of the access point, which usually has a radius of 100 or upto 300 meters. In this area or 'spot' one can get wireless access, but not outside it, i.e. the spot inwhich one can get access is 'hot'. Furthermore, companies providing Internet services using wirelesstechnologies are called WISPs (Wireless Internet Service Provider), by analogy to ISP (Internet Ser-vice Provider). There is also something which is called 'hotzone'. This refers to another type of ser-vice (which will not be discussed in this document) provided by WISPs. In this case the coverage

10

area of the hotspot has a radius of several kilometers.

1.6.2. ConventionsIn this document, references made to other documentation and quotations from other documentationwill be denoted by square brackets ('[' and ']') with an identification tag inside that is formed of theauthor's name, the year in which the document was published (if known) and possibly an integer todenote a sequence if multiple documents exist of the same author and publishing year. Further, notyet defined terms will be defined in-line in the respective document section (as opposed to the use offootnotes, which are unfortunately not supported fully, as described in appendix C.1). Lastly,whenever references in third person are made, the word 'he' is used, in each of these cases 'she' couldbe meant just as well, unless stated otherwise.

1.7. Document outlineThis document discusses the thesis project 'Design and implementation of a hotspot network' frominception to completion. It starts with an introduction, in which the problem domain is discussed,followed by a discussion of the project's goal and approach.

The document then discusses the various phases of the project, namely the analysis, design, imple-mentation and testing phases. Each chapter will tell about the approach taken to finish a phase. Fur-thermore it discusses the choices that were made as multiple options appeared. There are fourchapters discussing the various phases, the analysis chapter (chapter 2), which discusses the require-ments elicitation and the determination of the actors and use cases, the design chapter (chapter 3) theimplementation chapter (chapter 4) and finally the evaluation chapter (chapter 5).

Finally, in the conclusions the results of the project and some interpretations of these results will begiven. The conclusions will also include a general discussion of the study as it was provided by theTU Delft and how it was perceived by the writer of this document.

11

Chapter 2. AnalysisIn this chapter the analysis of the Mobidot project is discussed. The requirements elicitation is dis-cussed, in particular, requirements of the project and product. Further, the translation of the problemdomain and defined requirements to the definition of a data model and definition of use cases andactors is described.

2.1. Requirements elicitation2.1.1. Purpose of the system

The purpose of the system is to provide public Wi-Fi access to Internet under a user friendly envir-onment. Users have to share bandwidth, and this happens in a fair way. Sign-ups and payments foraccounts is made easy. Furthermore, the system will require minimal adjustments to a client's sys-tem, using the system to access the Internet is practically plug and play. Finally, security is providedas much as possible without interfering with the mentioned features. The system will support easyroaming to and from other Wi-Fi networks. It is possible for users from other Wi-Fi networks to useour system, and vice versa.

2.1.2. Scope of the systemThe scope of the system is quite complex, four parties are involved, each having one or more re-sponsibilities. The main party involved is Mobidot itself. It is responsible for three systems: thecentral management system, the support department and the development department. Furthermore,zero or more telecommunication providers are involved, either as technology partners or as roamingpartners. They supply NAS or VPN servers in order to support roaming. Further, they supply the In-ternet connections needed for the various hotspots and the central management system. The thirdparty that's involved is the group of managers of the public institutions (hotels, etc) housing the hot-spots. They are responsible for housing the Mobidot access points and for a reception desk that canfunction as a 1st line helpdesk. Finally, there are the clients who visit the public institutions and thatuse the system. They are responsible for the hardware used to access the system. Further, they areresponsible for retrieving an account needed to access the system.

2.1.3. Objectives and success criteria of the project

2.1.3.1. ObjectivesThe objective of the project is to create a working prototype of the system, which will completelyimplement a small set of important features. The system should be developed in such a way that itcan be used in production environments but also can easily be extended with additional features.

2.1.3.2. Success criteriaThe project is a success when the mentioned set of important features has been implemented withinthe time constraints described in the global plan (see appendix A) and when the system is designed,implemented in such a way that it can already be deployed successfully in production environments.

2.1.4. Current System

13

The system to be developed doesn't replace any existing system, as it introduces new technology tocreate new possibilities.

2.1.5. Proposed System

2.1.5.1. OverviewThe system's main function will be the deliverance of paid wireless Internet access to visitors ofpublic places (such as hotels and restaurants). It will do this by means of the 802.11 wireless fidelityprotocol. The system will consist of multiple hotspots, which are constituted themselves of one ormore APs. These APs will be connected to a central server in a centralized topology (purely central-ized or centralized+ring, etc).

The APs will offer the wireless Internet access to the visitors of the hotspots. The central Mobidotsystem will manage the network of APs by monitoring, by configuring and keeping it up-to-date.Wireless users will need to authenticate themselves before they can use the network, unless theywant to visit some particular websites, which can be accessed for free.

2.1.5.2. Functional Requirements

• Free websites : The user can visit certain websites (a small amount of informational sites, suchas yellow pages, etc) without being authenticated.

• Mobidot Wi-Fi accounts : The client creates a Wi-Fi account at the Mobidot login website, anduses a simple pay system such as paid SMS or a 0900 service number to pay for the account andactivate it.

• Live roaming : Client moves around with his mobile equipment within the hotspot from the cov-erage area of one AP to the coverage area of another, while the Internet connection is kept alive.

• Inter-network roaming : A client of another public Wi-Fi provider connects to the Internet usingthe Mobidot Wi-Fi network by selecting his provider on the central Mobidot system login web-site.

• Manager to user communication (one way) : Manager notifies client of an upcoming event bymeans of a message, sent from the central management system.

• Bandwidth adjustment per hotspot : Manager activates a different (as compared to the standardsetup) bandwidth sharing setup on one or more APs of a certain hotspot.

• Easy new configuration deployment :Manager sets up a new configuration for all or some of theMobidot hotspots. The new configuration is then automatically applied by all hotspots in ques-tion.

• Status overview : Manager visits the 'status overview' page of the central Mobidot system man-agement website where the central Mobidot system shows status and statistical information ofall Mobidot hotspots.

• Easy firmware updates : Manager uploads new firmware to the central Mobidot system fromwhere it is distributed automatically to all hotspots.

14

• Account management : Manager manages clients' accounts, such as editing of user information,resetting passwords and deleting accounts.

• AP status/statistical information supply : At regular intervals, APs gather status and statisticalinformation (about the network, users, hardware status, etc) and send this information to thecentral Mobidot system.

• Usage statistics logging : The central Mobidot system keeps logs of the usage of the system byusers, both in terms of usage duration and data traffic.

• Monitoring : The central Mobidot system monitors the Mobidot network by retrieving certainSNMP (Simple Network Management Protocol) information from the APs from time to time.

• Web redirection : Users are redirected to the login screen of the system if they try to visit a web-site with their web browser, while they are not authenticated yet.

• Mail redirection : The mail agents of users are redirected to the mail server running on the cent-ral Mobidot system, but only if these users have authenticated successfully.

• Manageability from central point :Manager manages the Mobidot network from the central Mo-bidot system, using the central Mobidot system management website.

• Easy hotspot setup : APs of a certain hotspot configure themselves automatically such that newhotspots can be deployed or existing hotspots extended in a plug and play manner.

2.1.5.3. Non-functional requirements

2.1.5.3.1. User interface and human factors

• User friendly access to the system : It should be possible for clients to use the system without(too many) adjustments to their computer system. The user can use the infrastructure withoutmodifying his IP settings.

2.1.5.3.2. Hardware consideration

• AP hardware : Hardware is needed for the access points. The APs should support running Linuxfirmware.

• Thin AP hardware : As much functionality as possible should be implemented in the centralMobidot system, instead of in the APs.

2.1.5.3.3. Error handling and extreme conditions

• Monitoring alerts : When the central Mobidot system notices that an AP is not announcing itspresence anymore and is being non-responsive, the central Mobidot system sends an alert to themanager(s).

15

2.1.5.3.4. Quality issues

• Fair use : Bandwidth as made available by the APs on a certain hotspot is divided (roughly)evenly among all connected users, i.e. it shouldn't be possible for one user to block out anotherby means of heavy downloads or uploads.

• Basic bandwidth availability : A bandwidth of 256 Kbps is made available for the manager ofthe location (i.e. a hotel) where the hotspot is hosted.

2.1.5.3.5. System modifications

• On the fly firmware updates : APs upgrade their firmware automatically by regularly checkingin with the central Mobidot system to check for new versions of the firmware. If an upgrade isavailable, the firmware is automatically downloaded, installed and activated.

• Traffic tapping : The system should provide hooks such that tapping network traffic can be setupeasily.

2.1.5.3.6. Security issues

• Host-to-network layer isolation : Laptops should operate isolated on the wireless network, itshouldn't be possible for laptops to contact each other circumventing the AP and it shouldn't bepossible for laptops to contact machines on a possibly existing wired network (to which the APmight be connected).

• Optional extra security for users : Privacy of users is protected as much as possible, withouthaving the user friendly access to the system suffer degradation. Either 802.11i should be sup-ported (if it can be supported without requiring users to use it; some hardware might not supportit), or optional VPN connections of any type should be supported.

• Authentication before system use : Unauthenticated users cannot use the wireless network, be-sides browsing some free websites.

• Rogue APs : Rogue APs are detected and (if possible) locked out.

2.1.5.4. Pseudo requirementsThe system will be written in at least two programming languages, one for the management systemand one for the firmware additions. The management system will be programmed in PHP, the firm-ware additions in shell script.

2.2. Further analysisIn this section, the second part of the analysis is discussed. Since it's clear we are dealing with a cli-ent-server type of system, we need to choose an appropriate network topology. This will be dis-cussed first, starting with a theoretical discussion about various possible topologies. After this, the

16

identification of the various actors and uses of the system (in terms of scenarios and use cases) fromthe requirements is discussed, followed by a discussion of the inception of the data model from theuse cases.

2.2.1. Network topologiesThe theory of network topologies is actually based on graph theory of mathematics. Many similarit-ies can be found, and also many algorithms from graph theory are used in network applications thatapply a particular topology.

When we are talking about network structures and topologies in relation to the objective of thisproject, there are actually two distinct network structures to talk about. The first one is the networkthat is formed by the various hotspots and a central Mobidot system, in this document this networkwill be referred to as Mobidot network. The other one is the network that is formed between mul-tiple access points at one location (a hotel, a train station, etc), this network type will be referred toas 'Mobidot WLAN'. Multiple access points are used when the coverage area of one access point istoo small, or when the bandwidth offered by one access point is too small for the amount of custom-ers that want access to the network.

Before having an in-depth look at each of the network topologies, first lets have a look a what kindsof network topologies there are in general. [Webopedia1] states:

"Topology refers to the shape of a network, or the network's layout. How differentnodes in a network are connected to each other and how they communicate is de-termined by the network's topology. Topologies are either physical or logical."

According to [Minar2002] there are four basic topologies: centralized, decentralized, hierarchicaland ring systems. These topologies can be used by themselves or they can be combined in one wayor another to create hybrid networks. [Minar2002] considers topology in terms of the informationflow. This means that the information flow that occurs between nodes more or less defines withwhat kind of network topology we are dealing. Because of this fact we will later on have a look atwhat kinds of information flows exist within the Mobidot network, in order to be able to choose anetwork structure.

Centralized architectureIn a centralized architecture, client machineshave to contact a central server in order to getsomething done.

Figure 2.1. Centralized architecture

17

[Webopedia1]

Figure 2.2. Star architecture[Webopedia1]

Star architectureThe star architecture is a member of the central-ized architectures group, and is realized as a net-work which contains a central hub and severalnodes. All nodes (can only) communicate toeach other through the central hub.

Bus architectureIn the bus architecture, nodes are connected toone another through a common bus. This archi-tecture is a special kind of centralized architec-ture, since it's not merely the fact that there canbe nodes that play a centralized role in the net-work, but more the fact that the backbonethrough which the nodes communicate is thecentralized part of the network.

Figure 2.3. Bus architecture[Webopedia1]

Figure 2.4. Decentralized architecture[Minar2002]

Decentralized architectureDecentralized systems are essentially pure peer-to-peer systems, thus there is symmetrical com-munication (one node can request somethingfrom another and get a response, that other nodecan also request something from the formernode, and get a response also), and all nodeshave equal roles. There is no central part in thenetwork, and as such, the availability of the net-work is not dependent on one single machine,while this is an advantage, pure decentralizedsystems also introduce the problem that there isno central authority.

18

Mesh architectureThe mesh architecture is a concept that comesfrom graph theory, and denotes a network inwhich all nodes are connected to all other nodes.

Figure 2.5. Mesh architecture[Webopedia1]

Figure 2.6. Hierarchical architecture[Minar2002]

Hierarchical architectureOne of the systems that made the Internet ac-cessible to humans is the Domain Name Service(accessible in the meaning that it is relativelyeasy to operate). The Domain Name Service (orDNS) is a hierarchical system "where authorityflows from the root name-servers to the serverfor the registered name and often down to third-level servers" [Minar2002].

Ring architecture

"A single centralized servercannot handle high client load,so a common solution is to usea cluster of machines arrangedin a ring to act as a distributedserver. Communicationbetween the nodes coordinatesstate-sharing, producing agroup of nodes that provideidentical function but have

19

fail-over and load-balancingcapabilities." [Minar2002]

Figure 2.7. Ring architecture[Minar2002]

Figure 2.8. Centralized+Ringarchitecture [Minar2002]

Hybrid: centralized+ring architecture

"Serious web server applica-tions often have a ring of serv-ers for load balancing and fail-over. The server system itselfis a ring, but the system as awhole (including the clients) isa hybrid: a centralized systemwhere the server is itself aring. The result is the simpli-city of a centralized system(from the client's point ofview) with the robustness of aring." [Minar2002]

Hybrid: centralized+centralized architectureIn situations where servers themselves are clientsto other servers, we are talking about a central-ized+centralized architecture. For instance 2-tierand multi-tier applications work this way.

Figure 2.9. Centralized+Centralizedarchitecture [Minar2002]

Hybrid: centralized+decentralized architec-ture

"A new wave of peer-to-peersystems is advancing an archi-

20

Figure 2.10. Centralized+Decentralizedarchitecture [Minar2002]

tecture of centralized systemsembedded in decentralizedsystems. This hybrid topologyis realized with hundreds ofthousands of peers in theFastTrack file-sharing systemused in KaZaA and Morpheus.Most peers have a centralizedrelationship to a "super node,"forwarding all file queries tothis server (much like a Nap-ster client sends queries to theNapster server). But instead ofsuper nodes being standaloneservers, they band themselvestogether in a Gnutella-like de-centralized network, propagat-ing queries. Internet email alsoshows this kind of hybrid topo-logy. Mail clients have a cent-ralized relationship with a spe-cific mail server, but mail serv-ers themselves share email in adecentralized fashion."[Minar2002]

Hybrid: tree architecture

"A hybrid topology. Groups ofstar-configured networks areconnected to a linear bus back-bone." [Webopedia1]

Figure 2.11. Tree architecture[Webopedia1]

2.2.1.1. Evaluation properties for choosing network topologies

21

[Minar2002] presents seven properties which can influence decisions in choosing a certain networktopology. Whenever a new application is designed, one of the design steps includes the choice of asuitable topology, based on the requirements of the application that is to be developed. These sevenproperties (as presented by [Minar2002]) are:

• Manageability

Manageability defines if it is easy to manage the system. Management activities could includeupdating, repairing and logging.

• Information coherence

Coherence is defined by Dictionary.com as:

"The quality or state of cohering, especially a logical, orderly, and aestheticallyconsistent relationship of parts."

So when we are talking about information coherence, we are talking about pieces of informationthroughout the system, which have to be or naturally are consistent with each other. In this docu-ment, when a system is said to be coherent, it means information coherence exists in the system,or can be enforced without problems. When talking about information coherence, three aspectsplay a role: non-repudiation, auditability and consistency. Non-repudiation means that it is notpossible for people to send information through the system and later on deny that they sent it.Auditability means that transactions through the system are traceable to an origin. Consistencydeals with the fact that certain pieces of information shouldn't contradict with certain otherpieces of information in the system. When these aspects are either enforced or readily availableby nature within the system, then we are dealing with a system in which information is coherent.Information in a system is said to be not coherent when it is impossible to enforce informationcoherence without changing the network topology used.

• Extensibility

Extensibility deals with the fact how well a certain system can be extended with resources (as ininformation or other data). For example, how easy is it to add a host sharing some files to an ex-isting file sharing network?

• Fault tolerance

Fault tolerance concerns the immunity of the system to erroneous situations or faults. The morefault tolerant a system is, the more a system can continue to operate without having the user no-tice a fault occurred.

• Security

Security deals with how easy it is to hack the system, or seen from the other viewpoint, howhard it is to secure the system.

• Resistance to lawsuits and politics

Is the system easy to shutdown by authorities, for example in media sharing applications? Beinglawsuit proof mainly plays a role in popular peer-to-peer file sharing applications, which are un-der pressure of large music and movie production companies.

22

• Scalability

Scalability is about being able to enlarge a system to meet demands. It deals with how well thenetwork scales when resources are actually being added to the network. For example can a cer-tain network handle 2000 clients or hosts, or can it only handle 10 clients?

Of these seven properties, resistance to lawsuits, extensibility and information coherence will not bereviewed. Resistance to lawsuits doesn't play any role in the choice of network topologies for a cer-tain business application. And since the Mobidot network is not destined to be an information sys-tem, but rather a network access providing system, it won't be dealing with information and as suchextensibility and information coherence don't play a role in this case.

2.2.1.2. Evaluation of the various network topologiesIn order to ease the choice of a network topology, these properties are valued against each networktopology set forth by [Minar2002] and [Webopedia1] with a 'good', 'average' or 'bad' designation.Each network topology will be discussed individually, all properties will get a grade depending onthe results of the discussion and a summarizing table will be provided at the end of this section.

2.2.1.2.1. Centralized architectures

In centralized architectures, there is one central server to which many clients connect. The fact thatthere is only one server in the system, means that the system is easily manageable, all data is con-centrated at one host and as such only one host needs to be managed. Securing a centralized systemis very easy, there is only one host that needs to be protected. Fault tolerance is not achieved in anyway in a centralized system. If the central Mobidot system goes down, the network is down, causingthe entire system to be unusable. When talking about scalability there are little growing possibilitiesof the system (hardware might be added, but only a limited amount) without changing the networktopology used, thus the scalability of centralized systems is bad.

2.2.1.2.2. Ring architectures

Ring architectures are architectures which consist of multiple servers. Since these servers usuallyhave a single owner, these networks act the same as centralized architectures when it comes to man-ageability and security. One of the added advantages of ring architectures over centralized architec-tures is the fact that there is fault tolerance, since multiple servers are doing exactly the same thing.This first of all achieves load balancing, but it also creates the possibility of letting other serverstake over the work of a certain server if it goes down, resulting in fault tolerance. Lastly, contrary tocentralized architectures, ring architectures scale quite well if well-designed, any number of hostscan be inserted into the ring.

2.2.1.2.3. Hierarchical architectures

Hierarchical systems have a clear chain of actions, but usually are owned by various people, makingit hard to manage individual hosts of the network. Since nodes in the network usually are owned bymultiple individuals, incorporating security into the system is hard. Contrary to centralized architec-tures, hierarchical architectures provide good scalability. On any level of the tree below the root, anynumber of servers can be added in order to handle the system load. Finally, hierarchical systems aremore fault tolerant than centralized systems, but the root of the hierarchical architecture is still asingle point of failure.

23

2.2.1.2.4. Decentralized architectures

Decentralized systems consist of multiple systems, which all form an active part of the network.Usually the various hosts in the network are owned by various individuals, making the system hardto manage. Further, for the same reason, a decentralized system is hard to secure. Any host couldconnect and start to inject bad information or data into the system, because of the fact that there isno central authority. But contrary to centralized systems, decentralized systems are very fault toler-ant, since in essence all nodes are equals, it won't be noticed if one node goes down, since others cantake over. Lastly, a decentralized system scales quite well when information coherence is not con-sidered, any number of hosts can be connected without performance degradation (any node that con-nects to the network can from then on provide the same services to the network to again other nodes,and these nodes in turn can do the same) If it would be necessary to keep the information in the sys-tem coherent, algorithms would be needed to achieve this, causing a lot of overhead. "If that over-head grows with the size of the system, then the system may not scale well." [Minar2002]. Since in-formation doesn't play a role in the Mobidot network, information coherence doesn't have to be con-sidered, causing decentralized architectures to scale quite well in that particular situation.

2.2.1.2.5. Hybrid architectures

It is impossible to discuss the properties of all possible combinations of architectures, so only a gen-eral overview will be presented here.

Combining different architectures, creating hybrid architectures, is usually done to add the advant-ages of one architecture to those of another, trying to get the best of both worlds. For example filesharing applications like Kazaa utilize a hybrid centralized + decentralized architecture. Having acouple of super nodes form a decentralized network, and having this network of super nodes actingas a centralized system to many clients. This gives advantages like manageability of the system,ability to keep the system secure (in essence the super nodes are central and in control of one party),but still the system has the very good fault tolerance of decentralized systems.

2.2.1.2.6. Summary of the evaluation properties

Below are presented the evaluation properties as defined and discussed for the various topologiesabove.

Name Manageability Fault tolerance Security Scalability

Centralized good bad good bad

Decentralized bad good bad good

Hierarchical average average bad good

Ring good average good average

Table 2.1. Evaluation properties for several network topologies

2.2.1.3. The appropriate topologyA problem with the system that is to be designed is the fact that the system has a distributed nature,which makes things more complex. On one hand there are the access points which have to be mon-

24

itored and managed, on the other hand there is the system that manages and monitors the infrastruc-ture. There are three information flows active in the infrastructure: an authentication flow (user try-ing to get access), a user data flow (user making use of the Internet) and a management flow(between the access points and the central managing system). In all situations, the management flowis centralized, since the information is needed centrally in order to manage the system. The othertwo information flows can however be centralized or decentralized. Before we can make a well-weighed decision in choosing a network topology, we must first know which options there are anddiscuss the pros and cons of each option.

Figure 2.12. Mobidot Infrastructure Situation 1

In the first situation, both the authentication flows and user data flows are decentralized and directlysent to the roaming partner of which the current user is a client. This situation imposes a serious lim-itation: we have no control over the authentication flow. As such we don't know who is active onour networks and we cannot manage these users nor monitor them. For example, we cannot sendnetwork announcements to these users in order to inform them about upcoming downtime of thenetwork, due to the maintenance.

25


In the second situation, both the authentication flows and user data flows are proxied through thecentral Mobidot system, before they are sent to a roaming partner, if any. Having the user data flowcentrally imposes a very large problem: the central server becomes a bottleneck and a single point offailure. Unless the central server is heavily invested in, it will lead to performance problems. Fur-thermore, the central server might need to be setup redundantly on geographically separated net-

26

works, possibly leading to high costs.


In the third situation, the authentication flow is setup centrally, i.e. it is proxied through the centralMobidot system before it is sent to the roaming partner in question. The user data flow is howeverdecentralized. In this situation we have combined the pros of the first two options and filtered outthe cons of these options. As such, this situation seems to be the best choice.

2.2.2. Defining the actorsHaving a good look at the system and the environment in which it operates leads to the identifica-tion of four actors. First of all there's the end user, the visitor of for example a hotel who wishes tobrowse the Internet with his laptop wirelessly (HotspotVisitor). There's the manager of the institu-tion (hotel, restaurant, etc) housing the public hotspot (HotspotLocationManager). This actor is in-volved with the system in two ways. First as an unlimited user (that is, only on his hotspot). Furtherhe manages everything that is needed to operate his hotspot, i.e. the investments for the necessaryhardware and the necessary network connections (externally to the Internet, and internally). And intime, he might be responsible for maintaining the portal site (using specialized Mobidot tools) forhis specific hotspot. The third actor which is identified is the manager of a WISP with which Mo-bidot has a roaming agreement (RoamingPartner). This actor needs information about the use of theMobidot infrastructure by its users, in order to be able to bill its users. Finally, there's the technicalstaff of Mobidot, the Mobidot network managers, who manage and monitor the infrastructure(MobidotNetworkManager).

Now let's have a look at the system and its environment. Each involved actor is responsible for acertain piece of the system.

27

Figure 2.15. Involved systems, their dependencies and responsible actors

Basically, the HotspotVisitor's hardware (i.e. laptop) depends on the presence of Mobidot accesspoints. The APs together with the needed Internet connection to connect the AP to are the responsib-ility of the HotspotLocationManager. The HotspotLocationManager orders an AP from Mobidotand places it in a strategic location (considering the coverage area of the access point), making sure

28

it can connect to the Internet. The APs in turn depend on the central Mobidot system, which the Mo-bidotNetworkManager is responsible for. This system is, like the other systems, composed of sever-al parts. One of these is the AAA server. This AAA server (which, amongst other things, performsauthentication of users) is in turn dependent on the AAA server of RoamingPartners, wheneverusers from such roaming partners roam onto the Mobidot network. Both the central Mobidot systemand the AAA servers of RoamingPartners depend on an Internet connection, just as the MobidotAPs. Finally, the diagram above also shows a little about the assignment, it shows two parts of thesystem which are to be developed for this assignment: The Mobidot AP system and the Mobidotmanagement system.

2.2.3. Defining the various uses of the systemTaking a good look at the requirements, we can find that most use cases are similar, but not exactlythe same. The fact that most use cases are similar means we can quickly design and implement thesystem, as the same design philosophy that is used for one use case can be used for the others. Inthis case, there are two groups of use cases.

Figure 2.16. Use case diagram group 1

29

Figure 2.17. Use case diagram group 2

2.2.3.1. HotspotVisitor use casesThe tables below describe the CreateNewAccount use case, the Login use case and the UseSystemuse case in detail. The CreateNewAccount use case describes how one retrieves an activation codeand uses this code to create a new account. The Login use case describes how one logs in into thesystem to be able to use the system. The UseSystem use case, finally, describes how one uses thesystem. For CreateNewAccount a translation into a sequence diagram is provided too.

Use case name CreateNewAccount

Participating actor(s)Initiated by HotspotVisitor

Entry condition

1. The HotspotVisitor starts his laptop andruns his favorite web browser, trying to vis-it a website.

Flow of events

2. The AP contacts the AAA server on thecentral Mobidot system to find out whetherthe user has logged in successfully.

3. The AAA server returns a false value andthe AP redirects the HotspotVisitor to thecentral Mobidot system login website.

4. The HotspotVisitor activates the "Create anew HotspotVisitor account" function ofthe central Mobidot system login website.

5. The HotspotVisitor is asked to use a phone/cellular payment system in order to get an

30

activation code.

6. [The HotspotVisitor uses the external pay-ment system, which generates and stores anactivation code and announces this code tothe HotspotVisitor. The activation code(including some extra information, such asthe amount that was paid for) is stored inthe Mobidot database by the external pay-ment system.]

7. The HotspotVisitor enters personal inform-ation (name, postal address and email ad-dress), a new user name and password, andthe activation code into the input form onthe "create new account" web page and hitsthe "Create Account" button.

8. The central Mobidot system checks in theMobidot database whether this user name isavailable.

9. The central Mobidot system receives the re-quest, checks whether the activation code iscorrect by contacting the Mobidot database.When it is, the central Mobidot system re-trieves some additional information fromthe same table in the Mobidot database (i.e.the amount that was paid for).

Exit condition

10. The HotspotVisitor's account is created inthe Mobidot database. The HotspotVisitorreceives a message confirming the success-ful creation of the account.

Table 2.2. Use case CreateNewAccount

Figure 2.18. Sequence diagram for use case: CreateNewAccount

31

Figure 2.19. Sequence diagram for use case: CreateNewAccount (part 2)

Use case name Login


Entry condition

1. The HotspotVisitor starts his laptop andruns his web browser, in order to visit thecentral Mobidot system login website.

Flow of events

2. The HotspotVisitor enters his login creden-tials in the input form that is presented, andhits the Login button.

3. The AP intercepts the request, interprets thequery and queries the AAA server on thecentral Mobidot system with the providedinformation.

4. The central Mobidot system AAA serverchecks whether the login credentials arecorrect, and if so returns a success messageto the AP, else it sends a failure message. Itrecords several details about the login(login status, login time) in the Mobidotdatabase.

5. The AP forwards the response detailingsuccess or failure to the HotspotVisitor. TheAP adjusts its firewall tables such that net-work traffic from the HotspotVisitor is al-lowed.

Exit condition

6. The HotspotVisitor receives either a failureor success message. In case of a successmessage, the HotspotVisitor is then authen-ticated and can then initiate the UseSystemand Logout use cases.

32

Table 2.3. Use case Login

Use case name UseSystem


Entry condition

1. The HotspotVisitor was successfully au-thenticated as described in the Login usecase and starts his web browser to visit awebsite.

Flow of events

2. The HotspotVisitor's laptop sends the web-site request to the nearest AP.

3. The AP checks whether this user is authen-ticated (by checking with the AAA server inthe central Mobidot system), if so, it allowsthe query to pass.

4. The central Mobidot system forwards thewebsite request to the intended server andthe central Mobidot system returns its re-sponse to the AP.

5. The AP forwards the response to the Hot-spotVisitor's laptop.

Exit condition

6. The HotspotVisitor receives the websitethat was requested. The use case keeps re-peating from step 2, unless the HotspotVis-itor logs out from the system.

Table 2.4. Use case UseSystem

2.2.3.2. MobidotNetworkManager use casesIn this section we will look at various management use cases. These use cases basically describehow one manages a certain type of information. Management of information (in this system) in-volves four basic actions: add, view, edit and delete. Each of these actions are described in the tablesbelow, followed by a translation into sequence diagrams. We will discuss the add action of the Man-ageFirmware use case, the view action of the ManageHotspotsAndAPs use case, the edit action ofthe ManageConfigurations use case and the delete action of the ManageAccounts use case. Further-

33

more, we will look at the use case descriptions of the use cases PutHotspotDownForMaintenanceand SendNetworkAnnouncement.

Use case name ManageFirmware (add)

Participating actor(s)Initiated by MobidotNetworkManager

Entry condition

1. The MobidotNetworkManager activates the"Firmware Management" function of thecentral Mobidot system management web-site.

Flow of events

2. The central Mobidot system queries the filesystem and shows a list of all previouslyuploaded firmware images to the Mobidot-NetworkManager.

3. The MobidotNetworkManager clicks theAdd button and browses to and selects thefirmware on his PC he wants to upload. Hehits the Submit button.

4. The central Mobidot system then stores thefirmware image in a previously configuredlocation in the file system of the centralMobidot system.

Exit condition

5. The firmware image is added to the file sys-tem of the central Mobidot system. APs willnotice the new firmware within the nexthour and update themselves.

Table 2.5. Use case ManageFirmware (add)

Figure 2.20. Sequence diagram for use case: ManageFirmware (add)

34

Figure 2.21. Sequence diagram for use case: ManageFirmware (add, part 2)

Use case name ManageHotspotsAndAPs (view)


Entry condition

1. The MobidotNetworkManager activates the"Manage Hotspots" function of the centralMobidot system.

Flow of events

2. The central Mobidot system queries theMobidot database and shows a list with allhotspots to the MobidotNetworkManager.

3. The MobidotNetworkManager clicks on ahotspot he wants to view.

4. The central Mobidot system then fetches allrelated hotspot information of the selectedhotspot from the Mobidot database andshows it to the MobidotNetworkManager.

Exit condition

5. The MobidotNetworkManager gets an over-view of all information related to the selec-ted Hotspot, including the collection of APswhich are located at that hotspot.

Table 2.6. Use case ManageHotspotsAndAPs (view)

35

Figure 2.22. Sequence diagram for use case: ManageHotspotsAndAPs (view)

Figure 2.23. Sequence diagram for use case: ManageHotspotsAndAPs (view,part 2)

Use case name ManageConfigurations (edit)


Entry condition

1. The MobidotNetworkManager activates the"Manage Configurations" function of thecentral Mobidot system.

Flow of events

2. The central Mobidot system queries theMobidot database and shows a list with allconfigurations to the MobidotNetworkMan-ager.

3. The MobidotNetworkManager selects someconfigurations he wants to edit, he then hitsthe Edit button.

36

4. The MobidotNetworkManager changes thepreferred firewall and traffic shaping con-figurations of the selected hotspot configur-ation and hits the Save button.

Exit condition

5. The hotspot configuration is updated withthe new information.

Table 2.7. Use case ManageConfigurations (edit)

Figure 2.24. Sequence diagram for use case: ManageConfigurations (edit)

Figure 2.25. Sequence diagram for use case: ManageConfigurations (edit, part2)

Use case name ManageAccounts (delete)


Entry condition

1. The MobidotNetworkManager activates the

37

"Account Management" function of thecentral Mobidot system management web-site.

Flow of events

2. The central Mobidot system queries theMobidot database and shows a list with allusers to the MobidotNetworkManager.

3. The MobidotNetworkManager selects someusers to delete and hits the Delete button.

4. The central Mobidot system asks the Mo-bidotNetworkManager whether he is sure,the MobidotNetworkManager hits the Yesbutton.

5. The central Mobidot system then instructsthe Mobidot database to delete the selectedaccounts.

Exit condition

6. The selected accounts are deleted from theMobidot database.

Table 2.8. Use case ManageAccounts (delete)

Figure 2.26. Sequence diagram for use case: ManageAccounts (delete)

38

Figure 2.27. Sequence diagram for use case: ManageAccounts (delete, part 2)

Use case name PutHotspotDownForMaintenance


Entry condition

1. The MobidotNetworkManager uploads anew firmware according to the Manage-Firmware (add) use case.

Flow of events

2. The AP checks in with the central Mobidotsystem once every hour in order to checkfor updated packages and new firmware. Itfinds a new version of the firmware.

3. The AP puts itself in offline mode in orderto prepare for the firmware upgrade.

Exit condition

4. All APs are put offline for maintenance.

Table 2.9. Use case PutHotspotDownForMaintenance

Use case name SendNetworkAnnouncement

Participating actor(s)Initiated by MobidotNetworkManagerCommunicates to/with HotspotVisitor

Entry condition

1. The MobidotNetworkManager uploads anew firmware according to the Manage-Firmware (add) use case.

39

Flow of events

2. The central Mobidot system stores a generalmessage concerning downtime of the sys-tem in the Mobidot database, for each userseparately.

3. The browser on the laptop of the Hot-spotVisitor regularly polls the AP for newinfo. In this case it will find a NetworkAn-nouncement is available, at which point itwill download and delete the message andshow it to the HotspotVisitor.

Exit condition

4. The network announcement is broadcast toall HotspotVisitors.

Table 2.10. Use case SendNetworkAnnouncement

2.2.3.3. HotspotLocationManager use casesThe table below describes the SetupAP use case in detail. It describes the actions the HotspotLoca-tionManager performs in order to get his Mobidot hotspot working.

Use case name SetupAP

Participating actor(s)Initiated by HotspotLocationManager

Entry condition

1. The HotspotLocationManager has investedin AP hardware from Mobidot.

Flow of events

2. The HotspotLocationManager receives theAP hardware and places it in a strategic loc-ation.

3. The HotspotLocationManager intends toconnect the AP to the Internet. He turns onthe AP, which immediately starts installingitself.

4. The AP checks whether it can get an IP ad-dress by DHCP (automatic configuration).

5. The previous step failed and the AP bringsan Internet connection configuration web-

40

site online.

6. The HotspotLocationManager connects hislaptop to the Mobidot AP and starts his webbrowser to visit this configuration website.

7. The HotspotLocationManager enters hisuser credentials, which he received from hisISP, which are needed to get an Internetconnection.

8. The HotspotLocationManager presses theSave button to store the user credentials.

9. The AP then checks, using the new inform-ation, whether it can get an Internet connec-tion.

10. The AP can successfully connect to the In-ternet. It connects to the central Mobidotsystem in order to download an installation/configuration script.

11. The AP runs this script, which then startsinstalling several needed packages. Afterthe installation phase has finished, the APstarts configuring itself according to set-tings which are stored in the central Mo-bidot system.

Exit condition

12. The AP is setup and ready for servicing Wi-Fi users.

Table 2.11. Use case SetupAP

2.2.3.4. RoamingPartner use casesThe table below describes the RetrieveUsageStatistics use case in detail. It describes how a roamingpartner retrieves the usage statistics of its users, who have roamed onto the networks of other Wi-Fiproviders.

Use case name RetrieveUsageStatistics

Participating actor(s)Initiated by RoamingPartner

41

Entry condition

1. The RoamingPartner activates the "RetrieveUsage Statistics" function of the centralMobidot system.

Flow of events

2. The central Mobidot system queries theMobidot database for usage statistics for allusers which belong to the RoamingPartner.

Exit condition

3. The central Mobidot system returns the us-age information to the RoamingPartner.

Table 2.12. Use case RetrieveUsageStatistics

2.2.4. Defining the data modelThe previous discussion dealt with various use cases which play a role in the system. These usecases are the basis for the creation of the data model.

The use cases describe the system modifying or accessing certain information based on user input. Amodel is a collection of such information which represents data about a part of the system that is be-ing managed. The essence of the Mobidot infrastructure management system is to manage the vari-ous parts of the system, which means to add, view, edit and delete information. From the use caseswe can find which models to manage: user accounts, roaming partners, hotspots, hotspot configura-tions, firewall configurations, traffic shaping configurations, access points and firmware. Each ofthese objects can be translated directly to a class in the class diagram. Another model also plays arole in the management of the system, which is however not fully managed, but only read and de-leted: the activation code. From the new account creation use case we can find that there is an ex-ternal system used by customers in order to pay for their accounts. This external system adds thesepayments in the form of activation codes in the Mobidot database, for the users to be able to activatetheir accounts.

Besides the various classes, relations between these classes need to be expressed in the data model.For example each hotspot has one or more access points and exactly one hotspot configuration. Eachhotspot configuration has exactly one firewall configuration and exactly one traffic shaping config-uration.

From all this information, the data model (the class diagram of the models) can be defined and de-signed, of which the result is shown below.

42

Figure 2.28. The data model

43

Chapter 3. DesignIn this chapter the system design is discussed. Which design problems are we facing? Which designgoals are we trying to achieve? What hardware and software are available, and which is chosen andwhy? Further, how is the system decomposed into subsystems and how are they mapped to the vari-ous hardware systems? How are certain problems solved, such as persistent storage of data? Afterthat, a closer look is taken at some subsystems: how are they constructed and why are they construc-ted the way they are? Not everything of the design phase will be discussed, rather, the discussionwill focus on choices and decisions, and how these decisions impact the development of the system.

3.1. Defining the design goalsFor the design goals there were three important considerations to make. First, the thesis project onlyruns for a limited amount of time. In the case of possible pilot projects, the system preferably wouldhave a minimal working base, as opposed to a complete set of features, but no really working sys-tem. Second, due to the fact the thesis time is limited, the system should be made extensible, in or-der to be able to easily expand the system after the finalization of the thesis project, i.e. to transformthe prototype into a production ready system. Third, the requirements as defined during analysishave to be kept in mind.

All in all, this results in an extensive set of design goals. In general when it comes to delivery time,functionality can be traded in if needed, in order to have an early delivery time. On the other hand,quality cannot be sacrificed, i.e. the minimal base should do its work well, if it is to be launched as apilot.

Another design goal is usability. One of the most important parts of an infrastructure such as the onebeing developed now, is that it should be easy to use for the end user, no difficult maneuvers shouldbe needed in order to use it. This notion has some side effects for security. Because native Wi-Fi se-curity is not mature at the moment, in this project it is favorable to drop native security and provideadd on security measures (such as VPN possibility) instead.

Finally, it was noted that the system needs to be extensible. This means it should be possible tochange a current implemented subsystem in order to support another external system (or back-endsystem) for example. It also means it should be possible to extend the system with new functional-ity. Think for example of the possibility for hotel owners (or hotspot owners in general) to modifythe portal web page, which is shown to the hotspot visitor. The hotspot owner could provide inform-ation about his hotel or local information of the town of residence on this portal web page.

3.1.1. Design goals

• Usability: It is easy for users to use the Mobidot infrastructure's services. When a non-authenticated user tries to use the system, the system informs the user about the need to loginfirst (unless a free website was requested).

• Utility: Bandwidth is divided evenly among active users, and a minimum amount of bandwidth(256 Kbps) is dedicated to the manager of the institution which is housing the hotspot.

45

• Delivery time vs. functionality: Due to pilot setups of the Mobidot infrastructure, it might beneeded to sacrifice functionality in favor of early delivery time. In order to be able to do this, aminimal functional implementation will be focused at, such that a minimal running system is ac-quired (users can login and use the system).

• Delivery time vs. quality: Since the pilot setups have to get a working implementation, qualitywill not be sacrificed in favor of early delivery time, testing is performed as usual.

• Security: The system supports the authentication of users, and supports the protection of the pri-vacy of users without sacrificing usability. This means that 802.11i (in particular 802.1X) willnot be enabled at this time, as it requires users to use this technology (an AP can only supportone Wi-Fi security measure, such as 802.11i, WEP or Open System Authentication at a time).802.11i is however not supported well yet in some client hardware. Security can be obtained byusing VPN technology between supplicant and authenticator.

• Robustness: All operations performed by the system which require user input achieve robustnessby checking the input of the user and by checking the progress of the operation (rolling back anypartial results in case of an overall failed operation).

• Availability: The central Mobidot system performs active and passive monitoring in order to beable to keep the availability of the Mobidot infrastructure at a high level.

• Fault tolerance: The central management system can run on multiple servers in order to providefault tolerance.

• Extensibility: The system provides hooks so the system can support traffic tapping if needed.

• Modifiability: The system is designed in such a way that specific subsystems can be replaced byothers without affecting the rest of the system.

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

3.2.1. Where to put the functionalityThe first thing we have to look at is the various hardware subsystems of the system, deciding whereto put the intelligence of the system. Aspects such as performance and ownership of sources play arole 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 Mobidotsystem. If we choose to implement everything in the access points this might have some negativeimplications. First of all, if the access points are going to be Linux based, then any additions to thefirmware 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 theaccess 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-

46

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 pointsA different problem to look at is the structure of the wireless network at one hotspot location. Inmost cases, a hotspot will be small enough to be handled by one access point. It might however, bepossible 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 themfrom a master-slave point of view, i.e. do we designate one as a master and the rest as slave? In thelatter case, we would manage the master access point from the central management system, and therest 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 thathotspot. In this case, we need to implement less in the access point itself, which relates to a problemdiscussed earlier. Related to this problem is the choice of how to interconnect the various accesspoints. 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 pointsusing a technology they have already on board: wireless IP technology a.k.a. 802.11. In this case thelimiting factor is performance: can we use the wireless channels both for interconnection of accesspoints, as well as transport of user data, and still provide a reasonable throughput for user data?

3.2.3. SecurityAnother problem, which had quite much coverage in the media, is security. It is quite well knownby 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.11based 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. Ifit is incorporated however, it is done so based on a certain version of the draft standard, and thiscould potentially make an access point of one brand incompatible with one of another brand. All inall, we can choose to apply 802.11i security measures, which means we exclude a group of clientsfrom having access to our systems. On the other hand, we could choose to give only minimal nativesecurity support, but provide security add-ons, such as the ability to create a VPN (Virtual PrivateNetwork) between the client hardware and the access points.

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

47

needs. Further, one needs to choose between possibly various build roots, usually based on whichsoftware 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 makeroom 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 deploymentWe also need to deal with another problem, namely the deployment of configurations on the variousaccess 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 deploythese configurations at each access point, including the knowledge of which access point we aredealing with. Another question is whether all configurations can be deployed automatically. Forsome configurations it might be needed to get settings from the manager of the location hosting thehotspot, and this information might be privacy sensitive. One could choose to maintain such settingson a central server, and possibly encrypt it. But then it is still easily vulnerable to theft. One couldalso 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 monitoringReachability 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 networkwhich will connect to the Internet, making it directly reachable for outside devices. It is howeverpossible for devices to be placed deeper inside an already existing network. In this case there aretwo possibilities: the first possibility is the device to have a non-private Internet IP address, in whichcase 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 addressesare 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 tobe setup on the gateway or some kind of permanent tunnel through the firewall should be setup inorder to make the internal machine (in this case an access point) reachable from the Internet. Thisproblem 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 latterprotocol, it is needed to run an agent on the device which is being monitored, this agent needs to betalked 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. InteroperabilityThe last problem to address is the problem of interoperability with other WISPs. We want to allowcustomers of these WISPs access to our wireless networks, if we have a roaming agreement withsuch 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,

48

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

3.3. Proposed software architecture3.3.1. Overview

The system's architecture is basically composed of two components: the central Mobidot system andthe AP. There's one central Mobidot system and there are one or more hotspots containing one ormore APs.

3.3.2. Subsystem decompositionThe subsystem decomposition is aimed at a split in three parts of the functionality of the manage-ment system. The first part, StorageSubsystem, takes care of storing information. The second andthird parts, the UserManagementSubsystem and HotspotManagementSubsystem, take care of thecore functionality of the system: dealing with user related tasks respectively dealing with hotspot re-lated tasks. The remaining subsystems aren't modeled in UML since they are either external fromthe system (but important enough to mentioned), or they cannot be modeled in UML (due to thenature of the subsystem; i.e. the chosen programming language). They will be discussed in the hard-ware/software mapping section.

Figure 3.1. Subsystem class diagram

StorageSubsystem The StorageSubsystem is responsible for all stor-age related tasks. It stores all information thatneeds to be stored, to be retrieved, or both: activ-ation codes, configurations, firmwares, hotspotand access points, roaming partners and users.

49

UserManagementSubsystem The UserManagementSubsystem is responsiblefor user-oriented tasks: logging users in and out,automatic re-authentication when a user roams,sending network announcements to users, usageadministration for both Mobidot users and ex-ternal users, management of accounts by the ad-ministrator, creation of new accounts by the user,increments of the account balance by the userand finally checking whether the user is loggedin, in the case of normal system use.

HotspotManagementSubsystem The HotspotSubsystem is responsible for bring-ing the hotspots up and down on demand,providing status overviews to the MobidotNet-workManager and performing configuration up-dates and firmware upgrades.

3.3.3. Hardware/software mappingAll subsystems defined above will be part of the central management system, and as such will bemapped to the central Mobidot system. There are some remaining subsystems, which will be dis-cussed below:

FirmwareSubsystem This subsystem is the base subsystem of the APs.It is the OS that runs on the APs. It takes care ofall of the AP's activities (such as routing traffic,authenticating users, letting users roam, loggingoff users). To perform Mobidot specific tasks itdepends on the SNATCircumventionSubsystem,the AutoConfigurationSubsystem, and theAutoInstallationSubsystem.

SNATCircumventionSubsystem This subsystem takes care of the SNAT circum-vention problem, by setting up everything that isnecessary for it.

AutoConfigurationSubsystem This subsystem is responsible for the configura-tion of the AP. This includes firewall configura-tions, traffic shaping configurations and somegeneral configuration settings. To achieve a zeroconfiguration setup, these configurations are per-formed automatically in coordination with thecentral Mobidot system.

AutoInstallationSubsystem This subsystem is responsible for installing theneeded software packages on the AP in order tosupport the other subsystems on the AP. It alsoresponsible for keeping these software packagesup to date.

CaptivePortalSubsystem This subsystem is responsible for providing fa-

50

cilities for the user to identify himself to the sys-tem.

ExternalCommSubsystem The ExternalCommSubsystem is responsible forcommunication with external systems, such as anexternal payment system which generates activa-tion codes. This subsystem will be used both bythe subsystems of the central management sys-tem and of the AP. It will be part of the centralMobidot system, as that eases the implementa-tion of the system.

Figure 3.2. Deployment diagram

Note: subsystems denoted with square brackets ('[' and ']') will be implemented in this project, butcannot be modeled in UML. Subsystems denoted with angle brackets ('<' and '>') will be implemen-ted using existing software packages.

3.3.4. Persistent data managementFor the persistent data management it was necessary to choose an appropriate storage back end forstoring several types of information. For most types of information the MySQL database is found tobe the best choice, mainly due to its speed, its ease of implementation (no custom storage structurehas to be defined, only a set of attributes per information type has to be defined), its ability to easilyexecute complex queries and finally its ability to easily support concurrent accesses.

UserStoreSubsystem The UserStoreSubsystem is responsible for stor-ing user related data (i.e. the list of UserAc-counts which are collected in the UserAccount-Collection).

RoamingPartnerStoreSubsystem The RoamingPartnerStoreSubsystem is respons-ible for storing the list of ExternalWifiProviders(RoamingPartnersCollection) with which Mo-bidot has a roaming agreement.

HotspotStoreSubsystem The HotspotStoreSubsystem is responsible forstoring hotspot related data (the list of Hotspotsand APs in HotspotCollection).

51

ConfigurationStoreSubsystem The ConfigurationStoreSubsystem is responsiblefor storing configuration data which is used byhotspots. The configuration data is composed ofgeneral configuration data, firewall configurationdata and traffic shaping configuration data (thelist of HotspotConfigurations in HotspotConfig-urationCollection, the list of FirewallConfigura-tions in FirewallConfigurationCollection, and thelist of TrafficShapingConfigurations in Traffic-ShapingConfigurationCollection).

ActivationCodeStoreSubsystem The ActivationCodeStoreSubsystem is respons-ible for retrieving activation codes which weregenerated by some external payment system. Itdeals with ActivationCodeInfos which are partof the ActivationCodeCollection.

FirmwareStoreSubsystem The FirmwareStoreSubsystem is responsible forstoring new firmware, which will be retrieved bythe access points by means of some file transferprotocol. Due to the fact we are dealing herewith mostly files and no structural information, itwas chosen to store the firmware in a plain filesystem, using the file names of the firmware forstoring any extra information (such as versionnumbers, etc). The subsystem deals with AP-Firmwares which are part of the APFirmware-Collection.

3.3.5. Global software controlThe server software for the Mobidot infrastructure will be implemented as a web service provider,meaning that each request for information instantiates a new instance of the server software. Thismeans that two distinct requests are serviced by two separate processes which cannot (at least at thismoment) share anything (such as memory, control flow, etc).

3.4. Designing the subsystemsIn this section the design of the subsystems will be discussed. We will take a look at the partitioningof the base subsystems into packages and we have a look at the basic functionality of each package.Due to the fact that the HotspotManagementSubsystem is practically designed the same way as theUserManagementSubsystem, we will only take a look at the UserManagementSubsystem. Further,due to the fact the partitioning of the StorageSubsystem has already been discussed above(Persistent data management), we will only discuss the design for the StorageSubsystem.

3.4.1. UserManagement subsystemWe will now have a look at the design of the UserManagement subsystem. As said before, the User-

52

ManagementSubsystem and HotspotManagementSubsystem have been designed with the same reas-oning. The first thing to discuss is the partitioning of the subsystem in packages. The subsystem hasbeen partitioned in three packages: Controllers, GUI and Models. The Model-View-Controller ar-chitecture forms the basis for this partitioning. For this project this architecture has been slightlymodified. One of the reasons for this is the fact that the application is not a normal GUI application.Instead it is a web application which is initiated upon an incoming request from a web browser.After this sole request is handled, the instance of the application is terminated and the applicationserver will wait for new requests. This means that no event handling takes place and that a sequenceof interactions with the user is handled by as many instances of the application. For the MVC archi-tecture this means that there's no subscribe/notify protocol. Further, since there's no active instanceof the application, each request is initiated by a Dispatcher class, which in turn calls the GUI. ThisGUI in turn calls the Controller. From this point on the MVC is the same as usual. For the sake ofsimplicity, the View is implemented by the GUI also, which actually means that when the GUI callsthe controller it waits for the output as delivered by the controller. When the GUI receives this out-put, it sends it to the user.

3.4.1.1. UserManagementModels package

Figure 3.3. UserManagementModels class diagram

53

The models have been designed with especially one goal in mind: easy expandability. It is preferredthat models are as autonomous as possible. One well known way of abstracting the internals of amodel is by the use of get/set methods (in the diagram above denoted by the general names getAT-TRIBUTE() and setATTRIBUTE(), as there are quite a few attributes to get and set). In addition tothis, check methods have been created. These methods perform various checks on the contents of aparticular attribute, perhaps to check whether it has a valid value, whether the value is within a cer-tain range or whether it contains valid characters. Each model has a global check() method, which inturn calls all defined check methods of the model. When, for example, the data of the model has tobe stored in a database, this method can be called first to check upon validity of the data.

Furthermore, each model has an update() method and a toDataArray() method. The update methodupdates several attributes of the model at once. It accepts a well-formed associative array (array in-dexed by strings), of which the indexes are taken to be the attribute names, and the values are takento be the new contents of the attributes. This method actually calls the set method for each named at-tribute. The toDataArray() method acts like the toString() method which is regularly used in Java.But instead of creating a string representation of the object, it creates the well-formed associative ar-ray that is needed by update(). All this has been done to ease the handling of the models and thestorage of the data of the models. This is because the database functions of PHP in fact accept well-formed associative arrays when doing an insert or update query. Furthermore, doing a select queryreturns a well-formed associative array. In other words, when we want to store a model, we onlyhave to call the toDataArray of a method, and pass the resulting array to the respective databasefunction. When we retrieve data from the database, we can just create a new model and pass the re-turned array to the constructor (which in turn calls update).

Besides the models themselves, collection classes are contained within the Models packages. Basic-ally the collections provide methods in order to keep the collections current: add, set (used to updatean already existing instance of an item in the collection), get and delete. Besides the basic function-ality, a collection can expose more methods for extra functionality. For example methods which canget an item based on different criteria (getAccountByName), or methods which can set a particularattribute of the models contained in the collection which are not supposed to be manipulated directly(storeNetworkAnnouncement).

3.4.1.2. UserManagementGUI package

54

Figure 3.4. UserManagementGUI class diagram

As discussed above, the GUI classes perform two functions: getting input from the user, passing iton to the controllers and showing the data of a model to the user. For these purposes the GUI classesexpose basically two types of methods: process- and show-methods. For simple use cases a GUIonly contains one show and one process method. For management use cases, a GUI contains processand show methods for each basic operation (add, view, edit, delete) if applicable. Furthermore, eachGUI contains an init() method which is always called in order to do some preprocessing of the en-vironment as offered by the application server. Based on the situation either only the GUI is shown(when the respective GUI wasn't loaded yet) by init(), or init() first calls the respective processmethod, followed by a call to the respective show method. When init() finishes, it returns controland its output to the Dispatcher that called him. The Dispatcher then sends the output to the user.

3.4.1.3. UserManagementControllers package

55

Figure 3.5. UserManagementControllers class diagram

The controllers are the classes which instantiate changes in the state of models. They keep instancesof the collections which they maintain, and perform manipulations on the methods contained withinthese collections.

3.4.2. Storage subsystem

56

Figure 3.6. ConfigurationStoreSubsystem class diagram

The final subsystem to discuss is the StorageSubsystem. Since all storage packages in the Storagesubsystem have been designed with the same philosophy, only the ConfigurationStoreSubsystemwill be discussed. The main focus here is the same as for the UserManagementSubsystem: expand-ability. In order to achieve this, it was chosen to implement the storage subsystems using the Bridgepattern. The bridge pattern allows for the storage back end to be reimplemented, for example in or-der to support a new database system, without having to change the front end. This is done by defin-ing an interface in the DatabaseConnector, which is implemented by, in this case, the MySQLCon-nector. Subsequently, the front end can be changed without the need for changing the back end, un-less of course the back end interface appears to lack certain functionality.

The functionality exposed by the DatabaseConnector interface is quite basic: it supports the basicoperations of a database: get, insert, update and delete. Further, it supports getting the identifiers ofall items of the type of information stored by the respective subsystem, in this case configurations.The functionality exposed by the AbstractDatabaseConnectors is the same for most storage subsys-tems: getting, inserting, updating and deleting data in terms of models, instead of in terms of data-base table items. Furthermore, more complex functionality is provided in single functions, for ex-ample for the addition of one configuration, three inserts of DatabaseConnector are performed: onefor the HotspotConfiguration, one for the FirewallConfiguration and one for the TrafficShapingCon-figuration.

57

Chapter 4. ImplementationIn this chapter the implementation phase of the Mobidot thesis project are discussed. We will look atit in three steps. First we will look at the chosen solutions for the various design problems. Furtherwe will look at the implementation of the management system. Finally, we will look at the imple-mentation of the firmware. The discussion focuses on the choices that were made during implement-ation, especially in the design domain, as changes in the design are needed due to inefficienciesfound during implementation.

4.1. Solutions for the design problemsIn this section solutions for the design problems are discussed. After a discussion about the possiblesolutions for a problem, one particular solution is chosen and supporting argumentation is provided.

4.1.1. Where to put the functionalityThe solution to the problem of where to put the functionality or intelligence of the system has beengiven largely already in the hardware/software mapping paragraph of the design chapter. Due to li-censing issues (the firmware is Linux based, which is available only under a GPL license), it hasbeen chosen to implement as much as possible in the central Mobidot system. A nice side effect ofthis (if done right) is however also a performance increase. For example proxying web server re-quests for the Wi-Fi login page to the central Mobidot system instead of running a web server on theaccess point itself eases the load on the CPU of the access points. The main tasks of the accesspoints will include tasks such as providing wireless access and securing the WLAN that they create.Additional tasks such as providing a login page, logging in/out users and maintaining usage datawill be performed by the central Mobidot system, having the access points relay such requests to thecentral Mobidot system (standard software solutions exist for this purpose, i.e. chillispot).

4.1.2. Network of multiple access pointsWhen it comes to networks with multiple access points, it has been chosen to designate the accesspoints as stand alone units, instead of using master/slave designations. First of all this eases thedesign. Second, we only need to create one firmware that fits all purposes. Finally, the result of thischoice means networks of multiple access points are readily possible. No additional precautionshave to be taken in order to let access points know of each other's presence and to let them cooperatein a master/slave fashion. The only restriction at this point in time is the fact that all access pointshave to be plugged into an existing wired network, having each serving its own coverage area. Pos-sible future extensions include the use of WDS. WDS stands for Wireless Distribution System. In-creasingly more wireless access point drivers include this technology. WDS creates the possibilityof easily setting up an access point as a real wireless router. This means an access point can acceptwireless traffic from client hardware (i.e. laptops), and again use the wireless network to transportthis traffic to another access point. The last access point in line then hands over the traffic to a routerwhich is connected to the Internet. WDS is also easily configured: only the MAC addresses of theaccess point peers of a certain access point have to be configured, due to the fact that the rest of thesettings have already been configured on the access point while creating the wireless network.

59

4.1.3. Security

"It's depressing how often we see that those who don't remember history aredoomed to repeat it. When cordless phones and the first analog cell phones hit themarket, anybody with a scanner that operated at the right frequency could easilylisten to calls not intended for them. The same cycle played out with 802.11equipment." [Gast2002]

The above quotation already gives some clue about the problems with security in wireless networks.At first it turned out that wireless networks weren't secure at all, no thought had ever been given tosecurity while the IEEE 802.11 standard was being devised.

"While the current access points provide several security mechanisms, our workcombined with the work of others show that ALL of these mechanisms are com-pletely in-effective." [Arbaugh2001]

A lot of security mechanisms exist for 802.11 networks, but, as pointed out above, most fail in ac-complishing their goal. Some of the security mechanisms have no or little effect or have a hugemanagement overhead, some of them make the network more insecure then before deployment ofthe security mechanism, and some of them might only be usable to a certain degree.

There are several tasks that have to/can be performed on a wireless network in order to make it(more) secure:

• Authentication:

"Authentication is any process by which you verify that someone is who theyclaim they to be. This usually involves a user name and a password, but can in-clude any other method of demonstrating identity, such as a smart card, retinascan, voice recognition, or fingerprints. Authentication is equivalent to showingyour drivers license at the ticket counter at the airport." [Apache1]

• Authorization:

"Authorization is finding out if the person, once identified, is permitted to havethe resource. This is usually determined by finding out if that person is a part of aparticular group, if that person has paid admission, or has a particular level of se-curity clearance. Authorization is equivalent to checking the guest list at an ex-clusive party, or checking for your ticket when you go to the opera." [Apache1]

• Access control:

"Access control is a much more general way of talking about controlling access toa web resource. Access can be granted or denied based on a wide variety of criter-ia, such as the network address of the client, the time of day, the phase of themoon, or the browser which the visitor is using. Access control is analogous tolocking the gate at closing time, or only letting people onto the ride who are morethan 48 inches tall - it's controlling entrance by some arbitrary condition whichmay or may not have anything to do with the attributes of the particular visitor."

60

[Apache1]

• Key management: Key management relates to the ease of the management of keys used in cryp-tographic algorithms. The easier it is to change any keys that are in use, the better the key man-agement is.

• Data integrity and confidentiality: Data integrity and confidentiality relates to the protection ofdata that travels across the network. It has to be protected from tampering (integrity protection)and from eavesdropping (confidentiality).

These concepts will play an important role in determining whether a certain security measure is ap-propriate or not. The distinction between authentication and access control is not always very clear,but for the sake of this project we will refer to authentication as the process whereby a user gets ac-cepted/rejected by a certain system on the basis of personal non-shared information, such as a username-password combination. When a shared secret is involved, we will refer to it as access control.

The goal of this discussion is not to go into implementation details of the security mechanisms, butmerely to give an overview of what is available to secure the Mobidot WLAN, present weaknessesof each and find the best candidate to do the job.

4.1.3.1. Service Set Identifier (Closed Network Access Control)Initially, the Service Set Identifier was meant to identify a network. The access point would broad-cast its name to the surrounding area using beacon frames. A beacon frame is similar to the beaconsignals used in aviation, by which a pilot can determine whether he is close to an airport, and whichone that would be. The same goes for beacon frames in Wi-Fi: a beacon frame is transmitted by anaccess point and carries information about that access point such as the name of the network (SSID),a time stamp, supported transfer rates, etc. Such a beacon frame is periodically sent by the accesspoint (by default the interval is set to 100ms), in order to make it possible for wireless clients to findthe access point and associate with it. In other words: the beacon frame is the heartbeat of a wirelessLAN. Similar as in aviation where a airport would seem to have disappeared if there would be apower outage, an access point would be offline (and thus invisible for radio receivers) if such abeacon frame would not be broadcast for one reason or another. (See [Geier2002] for more informa-tion on beacon frames.) The use of beacon frames makes it easy for people to select the right net-work by just scanning for them. Lucent came up with a security mechanism called Closed NetworkAccess Control which changed the network name into a shared secret, by not having the accesspoint broadcast its network name. This means that only people who know the SSID are able to con-nect. It is false to assume this approach makes the network safe. In order for a client to connect to anaccess point, he still has to connect to the access point of the network he intends to connect to,meaning he should send along the SSID of the network he wishes to connect to, and this means thatthe SSID is still sent in clear text. People with the right equipment will be able to sniff such packetsfrom the air, and find out the SSID. This security measure should be treated as stated by[Dismukes2002]:

"SSID settings on your network should be considered the first level security, andshould be treated as such. In its standards-adherent state, SSID may not offer anyprotection to who gains access to your network, but configuring your SSID tosomething not easily guessable can make it harder for intruders to know what ex-actly they are looking at."

61

For Mobidot it's not a good choice to implement Closed Network Access Control as it makes itharder for people to connect to the Mobidot WLAN, while one of the main goals of the system is theease of making connections.

4.1.3.2. Access control lists (MAC address filtering)Each network card (both wireless and wired) is configured with a MAC address. A MAC address isan address in the form of 6 bytes which identifies a specific network card on a network. All MACaddresses are unique, this is accomplished by dividing the MAC address space into several chunks,each chunk getting assigned to a specific vendor. MAC address filtering is based on the identifica-tion by their MAC address. A list of MAC addresses of allowed clients makes it possible to provideaccess only to those hosts that are mentioned on the list. This would seem like a good securitymechanism, if it wouldn't be the case that MAC addresses can be overridden ('spoofed') by software.This means that one could sniff wireless traffic for accepted MAC addresses, and spoof traffic withany valid MAC address found. Another problem of MAC address filtering is the fact that it incurs alarge management overhead, since the list of MAC addresses has to be managed by hand. For smallnetworks this might be no problem, but for large networks (such as the Mobidot infrastructure aimsto be) this is not feasible.

4.1.3.3. Open system authenticationOpen system authentication actually is a situation in which there is no authentication, it is the de-fault authentication protocol for 802.11. Simply any client that connects to the access point is al-lowed access. This might seem a strange sort of security, but it enables the possibility of disablingfaulty simple authentication systems, and then, for example, enabling more sophisticated authentica-tion schemes such as 802.1X.

4.1.3.4. WEP/WEP+/128-bit WEP and shared key authenticationWEP (Wired Equivalent Privacy) is a security mechanism that was devised in order to make wire-less networks more secure (in a wired-equivalent way). WEP has three security goals[Borisov2001]:

• Confidentiality: The fundamental goal of WEP is to prevent casual eavesdropping.

• Access control: A second goal of the protocol is to protect access to a wireless network infra-structure. The 802.11 standard includes an optional feature to discard all packets that are notproperly encrypted using WEP, and manufacturers advertise the ability of WEP to provide ac-cess control.

• Data integrity: A related goal is to prevent tampering with transmitted messages; the integritychecksum field is included for this purpose.

[Borisov2001] has shown that WEP fails to achieve all three goals. WEP encryption is achieved bycombining a shared secret key with an initialization vector. The first problem lies in the fact that thesize of the initialization is limited in size to 24 bits, making brute force attacks (attacks in which allpossible combinations are tried) feasible (the entire space of 24 bits can be used up in less than halfa day with average traffic, resulting in a wrap around of the initialization vectors), this problem isreferred to as key stream reuse. [Borisov2001] notes that this problem of key stream reuse is inevit-able. The 802.11 specification recommends against initialization vector reuse, but doesn't prohibit it.

62

This means hardware implementations should accept reused initialization vectors, or risk non-interoperability with 802.11 standard compliant devices.

Furthermore, there are certain vectors which are cryptographically weak, which means that the WEPkey can be cracked more easily when such initialization vectors are used. Another problem with theinitialization vectors is that some hardware always initializes to 0 when being reset, resulting a high-er frequency of certain initialization vectors than others. Lucent has designed in reaction to these ini-tialization vector problems WEP+, or 128-bit WEP as they call it, as an enhancement of standardWEP which uses only 40 bit keys. But this doesn't solve the problem, since the problem is not thekey that was used, but the initialization vector. The use of larger keys only makes the amount ofbandwidth that can be used smaller, since it takes more CPU cycles to encrypt the traffic, and thusless traffic can be sent or received per second.

4.1.3.5. Broadcast key rotationThis is an idea introduced by Cisco, and it is related to WEP. Normally, all traffic on the networkwould be encrypted using the same key. With broadcast key rotation, the access point utilizes a dif-ferent key for broadcast packets, such as DHCP. These broadcast keys are also short lived, typically10 minutes or so. The effect of this is that an attacker cannot collect enough packets to crack theWEP key, but the security mechanism is only applicable to broadcast traffic, and not to specific userdata traffic. Since this is an idea that was introduced by Cisco, it is proprietary and not widely im-plemented and used, and as such it is not quite usable.

4.1.3.6. 802.1X (EAP, or Extensible Authentication Protocol)In the new standard 802.11i (which will be discussed later on), 802.1X plays an important role, as ittakes care of the authentication of users. The new standard 802.11i has not been finalized yet, but802.1X has already been implemented into 802.11 products in order to already take advantage of it.802.1X is:

"Port-based network access control that makes use of the physical access charac-teristics of IEEE 802 LAN infrastructures in order to provide a means of authen-ticating and authorizing devices attached to a LAN port that has point-to-pointconnection characteristics, and of preventing access to that port in cases in whichthe authentication and authorization fails. A port in this context is a single point ofattachment to the LAN infrastructure." [802.1X-2001]

802.1X uses EAP (Extensible Authentication Protocol), which is a transport protocol, which is op-timized for authentication purposes. As the name already shows, it is an extensible protocol, in fact,no authentication methods are defined by EAP, such methods still have to be defined. Many of suchEAP methods exist:

• EAP-MD5: authentication mechanism which uses an MD5 (Message Digest version 5) hash ofuser name and password in order to authenticate the user. According to [Dismukes2002] EAP-MD5 offers no key management, requiring the use of static WEP keys. This completely disablesthe enhanced security possibilities of EAP.

• L(ightweight)EAP: LEAP or EAP-Cisco Wireless uses the same approach as EAP-MD5 exceptfor the fact that it uses dynamic WEP keys, which are rotated quite often (making it near to im-possible to crack the WEP key). Furthermore it adds the possibility of mutual authentication, in

63

which the client is able to know if a certain access point is authentic. This prevents people fromplacing rogue access points into the wireless network. Two problems exist with LEAP, one ofthem being the fact that LEAP is designed by Cisco, resulting in only Cisco hardware being ableto use LEAP. The other problem is the fact that MS-CHAPv1 is used for authentication (bothways), which has known vulnerabilities.

• EAP-TLS: EAP-TLS utilizes Transport Layer Security (IETF's standardization of SSL or SecureSocket Layers) for authentication. Instead of user name/password combinations, this system usesX.509 certificates to handle authentication. The difference between the two is that the formermethod sends personal secret information (a password), while the latter method is able to identi-fy an entity (a user or a system) without sending private information. This is achieved by havinga trusted third party sign such a certificate. The entity checking the identity of his peer can thencheck if the signature of the trusted third party is real. If this is the case, then the trusted thirdparty certifies that the public personal information really identifies the entity that owns the certi-ficate. Several problems exist with this approach. The first problem is the fact that Microsoft de-veloped this security mechanism, resulting in a situation where this mechanism only works onMicrosoft products. Replacing any software in the tool chain by another equivalent software willresult in a non-working system (For example if you use OpenLDAP as directory service insteadof Active Directory). Another problem is the fact that a public key infrastructure is used, whichis a concept that is quite unknown to most companies, resulting in either a steep learning curve,or giving up upon EAP-TLS. Yet another problem is the fact that Microsoft utilizes custom at-tributes in the certificates that are used by EAP-TLS, while those fields are not added to certific-ates which are issued by Verisign or Thawte. This means that only certificates issued by Mi-crosoft can be used.

• EAP-T(unneled)TLS: EAP-TTLS was design by Funk Software in response to EAP-TLS. EAP-TTLS provides for mutual authentication, but only for AP to client authentication certificates areused. For client to AP authentication, user credentials (user name/password) are used. EAP-TTLS can pass the user credentials using any challenge-response mechanism specified by theadministrator. (PAP (PPP Authentication Protocol), CHAP (Challenge Handshake Authentica-tion Protocol), MS-CHAPv1 (Microsoft CHAP version 1), MS-CHAPv2 (Microsoft CHAP ver-sion 2), PAP/Token Card, EAP)

• P(rotected)EAP: according to [Dismukes2002], PEAP has the same characteristics as EAP-TTLS, except for the fact that it is designed by Microsoft and Cisco instead of Funk Software.

There are lots more implementations of methods for EAP, for a complete list, refer to [IANA1].

64

Figure 4.1. 802.1X authentication process [Open1X1]

"IEEE 802.1x is a port based authentication protocol. It can be used in *any*scenario where one can abstract out the notion of a port. It requires entities to playthree roles in the authentication process: that of a supplicant, an authenticator andan authentication server. A Port Access Entity (PAE) is an entity that has accessor is capable of gaining or controlling access to some port which offers some ser-vices. When applied to IEEE 802.11, the access point acts as an authenticator,while a wireless station (laptop etc) is the supplicant which is authenticated by theauthentication server (for example a certain RADIUS implementation)."[Open1X1]

802.1X wasn't specifically designed for use on wireless networks, but for wired networks. It hasbeen ported to wireless networks because of the fact it is extensible, easing the process of addingmore authentication mechanisms (based on EAP) later on to wireless products. The use of EAP onwireless networks does however introduce a problem: since it was designed for wired networks, noreal thought has been given to the possibility of people sniffing the EAP traffic. In the case of wirednetworks it is quite hard to sniff such traffic, it involves having access to the network devices of ma-chines involved (the server in question, or routers in between). In the case of wireless networks it ismuch easier to sniff network traffic, it can be achieved by just putting up a wireless receiver, and seeall network traffic flow by. But, as [Gast2002] states, EAP is still a far better solution to the current802.11 security problems than WEP ever was. According to [Airespace1] 802.1X introduces thepossibility of having a master key sent to the user in encrypted form (after the user has been authen-ticated, the key will be sent along with the message that tells the user the authentication process wasa success), which from then on will be used for communication purposes. When 802.1X is used byitself, this means that the master key will be the key that will be used for the WEP protocol.

4.1.3.7. 802.11i, WPA (TSN, TKIP) and WPA2 (RSN, CCMP, AES-CCM)

802.11i is the new security standard for 802.11 networks devised by IEEE. As already stated before,802.1X will play an important role in 802.11i, as it takes care of the authentication. The 802.11istandard has not been finalized yet. 802.11i will provide for an authentication framework

65

(802.1X/EAP) combined with any authentication algorithm (which doesn't get mandated by the802.11i standard). Further, 802.11i will provide for enhanced key management, dynamic keys, mu-tual authentication and for data privacy and integrity. Data privacy and data integrity will beprovided for in two ways:

• TKIP: this will use per-frame keying (changing keys after every frame sent) and MIC (messageintegrity check). TKIP will be compatible with old hardware, since it uses the same encryptionprotocol as WEP (RC4), but as stated before, it will use a new key for every packet. Further, itwill encrypt the initialization vector, which in case of WEP is sent in the clear (which is a secur-ity hole in the WEP case).

• AES-CCM: the approach for new hardware will be based on the AES algorithm. The AdvancedEncryption Standard is the new American government's encryption standard of choice. AES isbased on the Rijndael algorithm which was developed by the Belgian researchers Vincent Rij-men and Joan Daemen. Details of the Rijndael algorithm aren't needed here, except for the factthat AES replaces DES because of its greater strength and speed (that is, AES is faster thanTriple DES. Triple DES is basically DES, but run three times. This was done to achieve astronger encryption while no better alternative was available yet. See [AESLounge1] for moreinformation).

Because industry couldn't wait for the release of 802.11i, the Wi-Fi Alliance (which is a non-profitinternational association formed in 1999 to certify interoperability of wireless Local Area Networkproducts based on IEEE 802.11 specification) felt obliged to release a "snapshot" of the 802.11istandard, based on draft 3 of the 802.11i standard [Strand2004]. As stated by [Strand2004], the Wi-Fi Alliance released the snapshot as WPA (Wi-Fi Protected Access) or TSN or "Transition SecurityNetwork". TSN is based on TKIP + 802.1X. The final version of the 802.11i standard will be calledWPA2 by the Wi-Fi Alliance or RSN ("Robust Secure Network"). RSN will be based on CCMP +802.1X. According to [Airespace1], WPA2 will introduce some advanced features, including keymanagement, by having a pairwise master key (PMK) which is exchanged using 802.1X or in a pre-shared way, which will be used to generate/retrieve a pairwise transient key (PTK), which in turnwill be used to generate three other keys for respectively key exchange and transport of data: keyconfirmation key (KCK), key encryption key (KEK) and the temporal key (TK). Other advancedfeatures include pre authentication, which authenticates a wireless client to other access points towhich the user might move in the future, thus enabling roaming.

4.1.3.8. VPNA VPN, or Virtual Private Network is:

"A private network that utilizes parts of the public telecommunications network.VPNs send encrypted data through the public network to ensure the security oftransactions" [hp1]

VPNs make it possible to circumvent certain security problems of wireless networks, even thoughthey weren't designed for that purpose. With VPNs, as stated above, one can create a virtual networkon top of an existing network structure, such as the Internet, and usually this is done in a secure wayusing an encryption algorithm. While using VPNs for authentication, data integrity and confidential-ity protection is quite secure, it still doesn't address all security problems. A problem that remains toexist is the fact that two illegitimate persons can still abuse the wireless network, though not for ac-

66

cess to the Internet, but they can contact each other and steal away bandwidth. This is because aVPN can only be setup on an IP-layer of a network, which means that before systems can be authen-ticated through a VPN, they first have to acquire an IP address, usually by means of a DHCP server.This means that anyone can at least connect to the network to get an IP, also people with wrong in-tentions. Another problem that gets introduced here is that such illegitimate users can also contactother wireless clients, possibly abusing their machines to access networks outside the wireless net-work. These security issues have to be addressed when a VPN is to be used in a wireless network.

4.1.3.9. The chosen solutionIt has been chosen to apply the Open System Authentication security measure, or in other words us-ing no existing Wi-Fi specific security measure. It has been shown the existing security measuresdon't supply the needed security, sometimes incur large management overheads and further, theywill be replaced by new security measures anyway. Instead it has been chosen to support VPN con-nections over the Mobidot WLAN and to warn the users about the security risk. Finally, the choiceof the firmware to be used on the access points has also to do with upcoming security measures, aswill be discussed later on.

4.1.4. Hardware and firmwareIn this section we will have a look at various hardware solutions and various firmware that can berun on these hardware solutions.

4.1.4.1. Hardware

4.1.4.1.1. Customizable access points

Customizable access points are hardware devices, which are already completely integrated and be-ing sold by large companies, which already deliver some basic access point services, to be used instandard situations. Such companies make use of an open source kernel such as the Linux kernel.Because of the license that is attached to the Linux kernel, these companies are forced to supply thesource code of any of their additions to the standard kernel. Such source code can then be used toimplement extra features for such an access point, which is exactly what is needed by Mobidot.

Solutions of several companies have been researched: Linksys, Netgear, D-Link, SMC and Belkin.Of these companies, only Linksys and Netgear seem to support the open source community. In thediscussion that follows, several hardware terms will be mentioned:

• wireless access point: an access point which (usually) has one socket for a wired network cable,in order to be able to connect the access point to an already existing internal network.

• wireless gateway: an access point which (usually) has one socket for a wired network cable andwhich has specific software (PPPoE) in order to be able to connect the access point to some ex-ternal network such as the Internet.

• wireless router: an access point which is a combination of a wired network switch, and a wire-less access point or a wireless gateway.

• wireless ethernet bridge: an access point which is used to interconnect remote LANs without acable.

67

4.1.4.1.1.1. Netgear

Figure 4.2. Netgear WG602 access point [SeattleWireless1]

Netgear is one of very few companies to supply the source code of the software used in their hard-ware products. Since the software used by Netgear is GPL licensed, they are forced to publish thesource code of the modifications they made to the original GPL software.

Specifications of the WG602 model include, according to [SeattleWireless1]: 16 megabytes ofRAM, 4 megabytes of flash memory, an Intersil 54g miniPCI (PCI with small slots) card with Pris-mGT chipset, a RTL8139 chipset, and a processor operating at 100 up to 150 MHz.

Figure 4.3. Netgear WG602 access point (internal view) [SeattleWireless1]

68

The first version of the WG602 has a miniPCI slot, which makes it possible to apply hardware up-grades to the WG602 in order to support new Wi-Fi standards such as 802.11i. It is, however, un-known if new versions and other models also have a miniPCI slot (it seems to be a trend to integratethe Wi-Fi chipset into the used motherboard, in order to force the user into buying new hardwarewhen he desires to use new technologies). The operating system kernel in use is Linux 2.2.14, whichis quite old, but seems to do the job. Furthermore, several other operating system tools, utilities anddaemons are used: busybox 0.50, uClibc 0.9.08, vsftpd 1.1.3. When considering finances, Netgear isquite interesting, with prices ranging from 60 to 200 euros. [Tweakers1]

4.1.4.1.1.2. Linksys

Figure 4.4. Linksys WRT54G access point + router [SeattleWireless2]

Linksys is one of the other few companies that uses GPL'ed software in its products, and as suchprovides the used source code on its website. The specifications, according to [SeattleWireless2], ofthe Linksys WRT54G seem to be better than the WG602 model of Netgear in several aspects.

69

Figure 4.5. Linksys WRT54G access point + router (internal view)[SeattleWireless2]

While the amount of memory and flash memory are the same (16 MB respectively 4 MB), the pro-cessor operates at a speed of 200 MHz, and uses Broadcom chipsets for both wired and Wi-Fi net-working. Old versions of the WRT54G had a miniPCI slot, which made it possible to apply hard-ware upgrades to the WRT54G in order to support new Wi-Fi standards such as 802.11i. In thelatest versions however, this miniPCI slot has been removed and replaced with a chipset which hasbeen integrated into the motherboard, as such disabling the possibility of easy future upgrades. TheLinksys WRT54G also uses a Linux kernel, but a slightly newer (but not quite up to date) one, ver-sion 2.4.20. A lot more tools and libraries are used by the WRT54G than the WG602. They both useuClibc and busybox, but WRT54G also uses other tools and libraries such as: iproute2, openssl,pppd, pptp-client, rp-pppoe, rp-l2tp, udhcpd (which are all popular Linux tools) and even a smallsized HTTP daemon. Linksys, like Netgear, has quite interesting solutions when looking at theprices, which range from 50 to 200 euros. [Tweakers1]

4.1.4.1.2. Solution using separate hardware parts

Another solution for the hardware implementation is to make use of several separate computer parts,such as a motherboard, CPU, memory and networking devices, in order to create an access pointfrom the ground up.

4.1.4.1.2.1. Soekris board with additional hardware

70

Figure 4.6. Soekris net4801 [Soekris3]

"Soekris Engineering, Inc. is a small company specializing in the design of em-bedded computer and communication devices." [Soekris1]

As stated, Soekris Engineering specializes in the design of embedded systems.

Figure 4.7. Soekris net4801 (internal view) [Soekris3]

The embedded systems are composed of a motherboard with CPU (486-class or 586-class), ethernetports for wired network connectivity, a miniPCI slot and up to two PCMCIA (small credit card-sized devices) adapters which might enable the embedded system to be expanded with a wirelessnetwork card or any other device, some other hardware chipsets and some specific amount ofmemory and flash memory (the amount depends on the model chosen).

71

The reasons that make this solution very interesting are the following:

• The motherboard has a hardware watchdog integrated. "A watchdog is a device used to protect asystem from specific software or hardware failures that may cause the system to stop respond-ing. The application is first registered with the watchdog device. Once the watchdog is runningon your system the application must periodically send information to the watchdog device. If thedevice doesn't receive this signal within the set period of time it would execute the proper key-strokes to reboot the machine or restart the application." [Webopedia7]

• The motherboard has lots of expansion options, it supports up to three expansion slots (miniPCIand 2 PC-Card/Cardbus slots). As such the embedded system can be expanded with hardwarethat increases the high availability even further. Further, when new Wi-Fi standards get devised,the old Wi-Fi miniPCI card can simply be replaced with a new one.

What might make this system less interesting is its price. The base embedded system costs between130 and 280 dollars (without discounts), depending on what is needed for processing power andamount of expansion slots, etc. [Soekris2] In order to make this into an access point, at least oneminiPCI Wi-Fi card is needed, and the choice is quite limited due to the limited availability ofdrivers in Linux. An Atheros based card which is 802.11i ready is available for around 80 dollars.[Netgate1]

4.1.4.1.3. The chosen hardware solution

The Linksys customizable access point has been chosen as the hardware device of preference. TheLinksys seems to offer a quite good price/capabilities ratio. Furthermore, there seem to be quitesome firmware available for the Linksys, which seems to show that a lot of people are already modi-fying their access points. This could mean that a lot of documentation is already available, whichcould ease the implementation quite a lot.

4.1.4.2. Firmware / Build rootIn this section we will look at the firmware that is available for the Linksys WRT54G access point.

4.1.4.2.1. The original Linksys firmware

It was quickly found that the original Linksys firmware build root is poorly designed. The mostprobable reason for this is probably that Linksys has nothing to gain from a well-designed buildroot, they only have man hours to lose. Firmware for future hardware will contain the same softwareprograms, only the drivers will differ, as new ones will be added in order to support new hardware.There are several problems with the Linksys build root, one of them being the lack of in-depth docu-mentation. Only a simple README file could be found, which only describes how to make a binaryfirmware. Furthermore, this description isn't even accurate, since the procedure as it is explainedgives errors and the commands entered should be adjusted. On of the largest problems with thisfirmware however, is the fact that it is not aimed at extensibility. The build root contains some soft-ware packages by default, but it doesn't provide easy means for extending the firmware with newsoftware packages. And even if you would take the time to add (or hack in) these packages, you stillhave no mechanism of selecting which packages you want to install, since sometimes you perhapswant to include different packages than usual, or perhaps leave out some packages of the originalfirmware. Lastly, this firmware doesn't include support for a file system that supports persistent stor-age. The firmware contents are stored in a read only file system, and furthermore only the RAM can

72

be used for writing (which obviously isn't persistent).

4.1.4.2.2. HyperWRT / Sveasoft / DD-WRT

About the HyperWRT, Sveasoft and DD-WRT firmware we can be short: they are based on the ori-ginal firmware with extra features hacked in. Further, as stated before, there's no selection mechan-ism, and this means sometimes everything possible is crammed in until there's no space left. Whileparticularly Sveasoft and DD-WRT do include some nice features (such as a SSH daemon and theChillispot captive portal), they are not a good choice. Would Mobidot ever need to add some pack-age, then it would first be needed to remove (hack out) software packages before new ones could beadded. Furthermore, the exact size of the packages is unknown, as such it would needed to performsome trial and error in order to create as much free space as needed (the access points have limitedstorage on a flash chip).

4.1.4.2.3. OpenWRT

Unlike the other build roots, the OpenWRT appears to be a very appropriate candidate to do the job.OpenWRT has two aspects which make it a quite strong competitor: support for multiple hardwaredevices and extensibility. OpenWRT has one problem though, it is not in final version yet, new re-lease candidates are still coming out.

It has been found that OpenWRT supports multiple hardware devices. By including modular devicedrivers, the appropriate drivers can be selected for the right hardware. That means that at this mo-ment already some five or six different brands of access points are supported. Would any of thesebrands drop support for customized firmware, then it would easily be possible to just use anotherone. Or perhaps that some brands offer other possibilities than others. For example access pointsfrom Asus have built in USB ports, which Linksys access points don't. Such a feature could be usedfor example for storage of certain data, for which the internal flash storage doesn't suffice.

But probably the strongest feature of OpenWRT is the fact that it is extensible. In OpenWRT,everything is contained in *.ipkg package files. Of each package it is exactly known how much stor-age space the files contained inside use. Installing these packages in the firmware can be done atfirmware creation time or at run time. When done at run time, one needs only to download the pack-age to the access point and run 'ipkg install'. Further, the build root has an excellent package selec-tion tool, in which the packages that are to be installed at firmware creation time can be selected.Here, it is possible to include or exclude the various packages that are included in the build root, butalso various kernel features which have been defined as modules. This means that support for cer-tain features (such as support for various kinds of file systems, support for networking protocols,etc) can be traded in, in exchange for free space. When the firmware is created, a read-only file sys-tem is created on which all initial packages are extracted. The remaining free space however, in thiscase, is designated to a separate partition on which a writable file system is created. This way, evenat run time packages can be installed or data can be written persistently. This last fact basicallymeans the firmware can be upgraded through packages instead of through dangerous firmware up-grades, when the entire firmware is overwritten with a new firmware image. Such operations are al-ways dangerous, since loss of power results in a defective access point. When only a certain packagecan be upgraded, the rest of the firmware will remain working, even if the package upgrade fails.

At this moment there's one problem though: OpenWRT is not final yet. Release candidates are stillbeing released, which means the candidates are not mature enough yet. Later on we will see whatimpact this has on this project. Even though this problem exists, OpenWRT has been chosen as the

73

firmware of preference. This is particularly because of the well design (which was developed withthe future in mind, i.e. upcoming modifications, new hardware, etc), and because of the bad designof the other solutions.

4.1.5. Configuration deploymentIt has been chosen to create a set of scripts which can configure the access point to the settings as re-corded in the management system. These scripts run on first installation of the access point and eachhour to check and possibly perform updates. It has been chosen to have the manager of a public in-stitution enter the credentials of his Internet connection (user name/password) manually on-site. Dueto the security sensitivity of this information, it is not very wise to store such information centrally(although taking that approach would reach a full plug-and-play solution). An additional script hasbeen created that asks for and tests Internet settings using a simple website on a simple web serverwhich temporarily runs on the access point. The manager of a public institution will use his browserto visit this website to enter his credentials.

4.1.6. Maintenance and monitoringOne particularly difficult problem to deal with is making the access points manageable from any-where. This means it should be possible to place the access point at any node in some network, butstill be able to manage and monitor this access point from an external network, such as the Internet.The particular problem which we are dealing with was described in the design problems, section'Maintenance and monitoring', namely the fact that most networks use Network Address Translation(NAT). In such cases we can modify firewalling rules at an already existing firewall, this is howevernot what we want. We want to solve the problem in such a way that at most only a very minimalchange to existing systems and configurations is needed. About the only way of achieving this is bythe use of a VPN (Virtual Private Network) solution. VPNs are essentially tunnels through existingnetworks which connect nodes logically which are by far not directly physically connected. Withsome solutions this can be done with encryption. Before discussing the chosen solution for thisproblem, we'll first look at some well known VPN solutions.

4.1.6.1. Network layer

4.1.6.1.1. IP-in-IP tunnels

In some cases, it might be needed to encapsulate IP packets inside other IP packets. In this situationwe are tunneling a network layer network inside another network layer. The most obvious situationin which this would be applied is a situation where there are two private network layer (IP) net-works, which are both connected to some public network (the Internet) and which should be connec-ted together in such a way that it seems to be one private network. This can be achieved using IP-in-IP tunnels, but the interconnection of networks is also the only thing that is achieved, i.e. there'sno encryption.

4.1.6.1.2. GRE tunnels

GRE stands for Generic Routing Encapsulation and is quite similar to IP-in-IP tunnels, though withsome differences. The first difference is that GRE is a more general approach to network layer innetwork layer encapsulation, meaning the encapsulation is not limited to IP, both for the originalpacket, and for the packet that encapsulates the original packet. As stated by [RFC1701]:

74

"In the most general case, a system has a packet that needs to be encapsulated androuted. We will call this the payload packet. The payload is first encapsulated in aGRE packet, which possibly also includes a route. The resulting GRE packet canthen be encapsulated in some other protocol and then forwarded. We will call thisouter protocol the delivery protocol."

This more general approach to network layer in network layer encapsulation also creates anotherpossibility, the transport of special IP packets such as multicast traffic, or even IPv6 packets, butlike IP-in-IP, it also doesn't support encryption.

4.1.6.1.3. Microsoft's PPTP

"PPTP is implemented as a PPP session over Generic Routing Encapsulation(GRE). Authentication is usually by MSCHAP-v2 (Microsoft Challenge Hand-shake Authentication Protocol) , and supplies key material for the subsequent Mi-crosoft Point-to-Point Encryption (MPPE) applied to data packets." [Wikipedia2]

As stated here, PPTP is the encapsulation of PPP in GRE. Recall that GRE is a network layer pro-tocol and PPP is a data link layer protocol. PPTP is implemented, as already stated earlier, by theuse of the GRE protocol. But in addition to this, a TCP connection from client to server, usually onport 1723, is used to control the PPTP connection. According to [Hardin2000] and [Wikipedia2]PPTP suffers security vulnerabilities and as such should not be used.

4.1.6.1.4. L2TP

"L2TP can crudely be described as "PPP over IP", although it has many more fea-tures than this simple description would imply." [Wikipedia1]

L2TP is based on the older PPTP protocol and the older proprietary L2F (Layer 2 Forwarding) pro-tocol by Cisco.

"L2TP acts as a data link layer (layer 2 of the OSI model) protocol for tunnelingnetwork traffic between two peers over an existing network (i.e. the Internet). It isan extension of the Point-to-Point Protocol (PPP). It is still common to use PPPsessions within an L2TP tunnel. L2TP does not provide confidentiality or strongauthentication itself." [Wikipedia1]

According to [Wikipedia1], L2TP packets can be categorized as two types: control packets and datapackets. Reliability is provided for control packets by the L2TP, but not for the data packets, whichhas to be taken care of by higher layer protocols.

4.1.6.1.5. IPSec

All the tunneling protocols discussed up until now don't provide data confidentiality. IPSec on theother hand is a protocol that does provide confidentiality, and even more. IPSec, as the name alreadysays, secures IP traffic, and it works on the network layer. The IPSec protocol provides four func-tions:

• Confidentiality. Confidentiality is achieved by means of encryption. IPSec is a framework of

75

open standards, which means that it is not bound to any particular encryption algorithm.

• Data integrity. In order to provide data integrity, a hashing algorithm is applied on the messagesthat have to be sent out. IPSec uses the Hashed Message Authentication Codes in order toachieve this, and the most commonly used flavors are HMAC-MD5 and HMAC-SHA1. It is im-portant to understand that a certain message (of any length) can be converted to a fixed-lengthhash, but the reverse, retrieving the message from the hash, isn't possible.

• Origin authentication. Origin authentication is provided and used to make sure the communica-tion channel is secure. Before any communication can take place, mutual authentication has totake place.

• Anti replay protection. Anti replay protection works in a similar way to the use of sequencenumbers in TCP. A sequence number gets added to each IPSec packet, and the sequence numberof each packet gets compared to a sliding window. Packages with illegal sequence numbers getdiscarded. This prevents illegal uses of IPSec networks, such as rerunning an authentication pro-cess using sniffed traffic, in order for the hacker to get illegitimate access to the IPSec network,for example.

Two terms play an important role in IPSec:

• Security Association: A Security Association (SA) is a set of security information that describesa particular kind of secure connection between one device and another. You can consider it a"contract", if you will, that specifies the particular security mechanisms that are used for securecommunications between the two. A device's security associations are contained in its SecurityAssociation Database (SAD). [TCPIPGuide2] The to be used security association is identifiedby the Security Parameter Index (SPI).

• Security Parameter Index (SPI): A 32-bit number that is chosen to uniquely identify a particularSA for any connected device. The SPI is placed in AH or ESP datagrams and thus links each se-cure datagram to the security association. It is used by the recipient of a transmission so it knowswhat SA governs the datagram. [TCPIPGuide3]

4.1.6.2. Transport layer

4.1.6.2.1. SSL based VPNs

SSL (Secure Socket Layer; an algorithm with a public-key encryption-based key exchange, certific-ate-based authentication and symmetric cipher-based traffic encryption) is a technology that adds se-curity to protocols on the transport layer (mainly TCP). Nowadays it's most commonly used for ser-vices like HTTP and FTP, in order to make the data transfers secure. The only thing that SSL addsto an already existing protocol is confidentiality (encryption), it only secures one connectionbetween two hosts. SSL cannot be used to secure connections between various networks, unlesssome custom application is written which implements tunneling of a layer 2 or layer 3 protocol us-ing SSL for confidentiality. A simple kind of VPN might be implemented by creating a website us-ing SSL and user logins. After being logged in, the user can access all kinds of data and perform ac-tions, the only problem with this setup is the fact that it's a remote access based VPN, i.e. it cannotbe used to interconnect networks.

76

4.1.6.2.2. CIPE

CIPE, which stands for Crypto IP encapsulation, is a custom designed tunneling protocol using en-cryption.

"CIPE encapsulates encrypted IP datagrams in UDP datagrams and sends them viathe normal UDP mechanism. This is different from standard IP-in-IP encapsula-tion. UDP was chosen because this way many different endpoints can easily bedistinguished by port numbers; because an IP protocol number would warrant aformal registration; and because handling of UDP datagrams is easier than using aseparate IP protocol number, especially in firewalled setups. Specifically, UDPcan be handled by user-level applications such as a SOCKS5 relayer. A CIPE linkalways connects exactly two endpoints." [Titz2004]

As we can read in the above description, CIPE implements the tunnel using UDP, and such a tunnelcan only exist between two end points. As already stated in the description above, the advantage isthat it should be able to pass through the firewall (note: if the firewall doesn't restrict UDP traffic)without problems, unlike packets using a custom IP protocol, which might be discarded by the fire-wall with a greater possibility. This advantage only plays a role in networks where a tunnel shouldbe set up without consent of a security officer. A problem of this approach is the added overheadand the inability to check for authentication of packets before they are decrypted, which results in aperformance loss in case of denial-of-service attacks. Would it be possible to authenticate packetsbefore they were decrypted, a denial-of-service attack wouldn't have such a great impact, since thedecryption wouldn't have to take place, which is CPU intensive. Furthermore, a lot of overhead isadded. An IP packet, which already consists of 40 bytes of headers (TCP and IP), gets wrapped inanother UDP/IP packet, which again adds 40 bytes. (UDP, TCP and IP packets all have headers of atleast 40 bytes; there are optional extensions which can make the headers larger)

4.1.6.3. Application layer

4.1.6.3.1. SSH based VPNs

SSH stands for Secure Shell. A shell is a command line user interface which is generally used inUnix type systems. The secure shell is a secure (and cryptographically strong) implementation of theold remote shell protocol in UNIX, which enables remote access to UNIX systems. Besides provid-ing a remote command line interface and authenticate users against a UNIX user database, SSH isable to perform much more functions, such as forwarding traffic through its encrypted channel. Thismakes SSH a popular choice for adding authentication to protocols which natively don't provide au-thentication or for adding encryption to protocols which natively don't encrypt traffic.

In the case of SSH based VPNs, one protocol or another is tunneled through an existing SSH con-nection. A popular approach to this is the tunneling of PPP traffic through a SSH connection. It isactually quite similar to the situation described for SSL VPNs, except for the fact that SSH bynature is capable of carrying any traffic, i.e. no custom protocol has to be written anymore. Someproblems exist for this approach. First of all, this approach has the same problems when it comes tooverhead and performance loss as the CIPE approach. Furthermore, SSH is a user space program,which results in two problems. First, the tunnel has to be set up manually (though it could be scrip-ted) and should always exist in order for the VPN to be usable. Once the tunnel goes down (whichcan happen once in a while with TCP connections), the VPN goes down. The second problem is thefact that SSH lives in user space, meaning a lot of context switches are needed between user and

77

kernel space: the user wants to connect over the VPN, sets up a connection, this goes from userspace to kernel space, gets routed, gets back to user space to be tunneled through SSH, and then getsback to kernel space in order to be routed as standard TCP traffic. The same actions (though in op-posite order) occurs at the other side of the tunnel.

4.1.6.4. The chosen solutionBefore we can make a well weighed decision in choosing a tunneling solution, we should firstidentify our needs. One need that we can identify is the fact that multiple tunnels per network shouldbe supported. In [Fratto2000] we can find that IPSec in combination with NAT natively doesn't sup-port multiple tunnels. The reason for this is actually the same as for any network layer tunnelingsolution: we can only identify traffic on the network layer by IP address. Normally in situations withNAT, traffic is identified by transport layer attributes, such as the source port number. In case ofnetwork layer tunneling, we can only differentiate traffic by the IP address, since the payload of thenetwork layer packet is not a normal transport layer packet, but a packet of some other type, for ex-ample GRE. In other words, we can only look at the original source IP address and the translated IPaddress in order to know the real destination of incoming tunneled traffic. Due to this fact, all net-work layer solutions aren't appropriate. In the case of IPSec, it would be possible to differentiatebetween various tunnels by the SPI number, as stated by [Fratto2000]. In this case however, weneed specialized hardware, and this is not what we wanted.

This leaves us with transport layer or application layer solutions. In the case of SSL tunnelshowever, it was stated we would need to write a custom application in order to implement tunnelingfor any type of network traffic. Since this is not at all desired, this leaves us with either SSH tunnel-ing or CIPE.

First was decided to use PPP over SSH tunnels. PPP is the Point-to-Point Protocol which offers alayer 2 connection between two end points, which in turn can be used for IP networks and thus alsofor TCP and UDP connections. However it turned out also not as a good choice, due to the nature ofTCP connections. In [Titz2001] is extensively explained why this does not work well. It comesdown to problems with the retransmission algorithm used in TCP in case of network congestion. Insuch situations, TCP lowers its transmission speed in order to lower the congestion, by increasingtimeouts between the sending of two packets.

78

Figure 4.8. SSH tunneling

However, when one TCP connection is tunneled through another, this has a very nasty side effect:

"The lower layer TCP queues up a retransmission and increases its timeouts. Sincethe connection is blocked for this amount of time, the upper layer (i.e. payload)TCP won't get a timely ACK, and will also queue a retransmission. Because thetimeout is still less than the lower layer timeout, the upper layer will queue upmore retransmissions faster than the lower layer can process them. This makes theupper layer connection stall very quickly and every retransmission just adds to theproblem - an internal meltdown effect." [Titz2001]

The upper layer TCP connection is the TCP connection which is tunneled through the lower layerTCP connection. Due to these problems, another tunneling strategy needed to be chosen. Becauseencryption of connections is very desirable, the choice fell on Cipe. Cipe is a relatively new techno-logy which tunnels IP traffic through UDP tunnels, offering encryption along the way. Unlike othertunneling protocols like PPTP and IPSec, Cipe, like SSH, can have multiple tunnels through oneNAT-gateway. The tunneling protocol would run in the transport layer, thus it would be possible toassign it to any given port number (in a 16-bit range), meaning you could theoretically create about65000 tunnels through one NAT-gateway. This number is enough for Wi-Fi networks, as theamount of access points at a local site will never be higher than this. It will however quite regularlybe higher than one.

4.1.7. InteroperabilityIn order to support roaming we will be running an AAA server. We will first investigate which typesof AAA servers are available, followed by an investigation of existing implementations. After that,we will discuss what AAA server type and implementation was chosen to use.

79

4.1.7.1. AAA server types

4.1.7.1.1. AAA Servers (Authentication, Authorization and Accounting)

AAA servers play an important role in corporate networks, both business networks and the networksof Internet Service Providers. AAA servers perform three basic functions: authentication, authoriza-tion and accounting. Authentication (as already explained earlier) performs verification checks tosee whether the user who tries to log in is who he says he is. Authorization deals with controllingwhat someone is allowed to do, which actions that person should be allowed to perform. Finally, ac-counting takes care of tracking what someone has done, logging which actions a certain user hasperformed. According to [Laet2004] The AAA server model was designed in such a flexible waythat (almost) any kind of access method can benefit from its security features: dial up connections,ISDN, ADSL and VPN. There are three popular implementations of AAA servers. There's RADI-US:

"Remote Authentication Dial-In User Service (RADIUS) is a client/server pro-tocol and software that enables remote access servers to communicate with a cent-ral server to authenticate dial-in users and authorize their access to the requestedsystem or service. RADIUS allows a company to maintain user profiles in a cent-ral database that all remote servers can share. It provides better security, allowinga company to set up a policy that can be applied at a single administered networkpoint. Having a central service also means that it's easier to track usage for billingand for keeping network statistics. Created by Livingston (now owned by Lucent),RADIUS is a de facto industry standard used by a number of network productcompanies and is a proposed IETF standard." [SearchSecurity1]

Further there's TACACS+, which is Cisco proprietary implementation of an AAA protocol:

"There are three versions of TACACS and the third version is called TACACS+,which is not compatible with previous versions." [Javvin1]

And finally there's Diameter:

"The Diameter protocol is being designed by the IETF's AAA Working Group."[OpenDiameter1]

Diameter is a new AAA protocol that's being designed by the IETF as an alternative for the older,less capable and proprietary RADIUS and TACACS+ protocols.

4.1.7.2. AAA server implementations

4.1.7.2.1. FreeRADIUS

FreeRADIUS is one of a few open source implementations of a RADIUS server. FreeRADIUSseems to be a quite mature project. FreeRADIUS supports MySQL, PostgreSQL, Oracle and LDAPdatabases. It supports EAP and many of its forms: EAP-MD5, EAP-TLS, EAP-TTLS, EAP-PEAPand EAP-LEAP. It has two very interesting features for Mobidot: it supports executing external pro-grams (which could make the Mobidot solution support other AAA servers by externally connectingto such an AAA server, would the AAA server of a roaming partner be of a different type than RA-DIUS), and it supports proxying of requests (meaning forwarding of the request to another RADIUS

80

server) with fail-over ("A backup operation that automatically switches to a standby database, serveror network if the primary system fails or is temporarily shut down for servicing" [Webopedia5]) andload balancing ("Distributing processing and communications activity evenly across a computer net-work so that no single device is overwhelmed" [Webopedia6]). Finally, the server comes with aPHP-based web user administration tool. A PAM module (Pluggable Authentication Module) andApache web server authentication modules are available. It is stated by the maintainers of FreeRA-DIUS that the software has reached stable release, and it would be ready for deployment in any sizenetwork.

4.1.7.2.2. Cistron RADIUS, ICRADIUS, XtRADIUS, GNU RADIUS

The Cistron RADIUS server was developed by Miquel van Smoorenburg (from the Cistron ISP inthe Netherlands). The server was developed quite some time ago, and lacks support for new fea-tures. It does support proxying of requests and PAM authentication, but it doesn't support databasesexcept for the Berkeley database format DBM and it doesn't support EAP at all, only PAP andCHAP. ICRADIUS, XtRADIUS and GNU RADIUS are derivatives of Cistron RADIUS, eachadding some minor features. ICRADIUS adds MySQL database support. XtRADIUS adds a quitenice feature: the ability of running scripts which will handle the authentication and user accounting,thus enabling querying external resources (much like the external program execution function ofFreeRADIUS). GNU RADIUS adds extensibility by using the Scheme programming language as ascript interpreter, it adds support for PostgreSQL databases and it adds support for SNMP manage-ment and monitoring.

FreeRADIUS is in fact also another derivative of Cistron RADIUS. But due to the fact that the de-velopment approach chosen for FreeRADIUS (development done by a large group of individuals),FreeRADIUS seems to offer much more features and seems to be more mature.

4.1.7.2.3. OpenRADIUS

OpenRADIUS is another implementation of a RADIUS server, which was developed from scratch.OpenRADIUS doesn't support EAP. On the other hand, OpenRADIUS supports proxying, and is ex-tensible because of the use of external program calls for the handling of any action, such as authen-tication of users, etc. For this reason, any type of database could be supported, but isn't at this mo-ment. OpenRADIUS does introduce an optimizing feature with calling external programs: calledprograms are only launched once, and from then on kept in memory, so it can be consulted manytimes without needing to reload it, resulting in a performance gain. This project seems to be a one-man project however, and as such is a less attractive solution than FreeRADIUS.

4.1.7.2.4. tacppd, libtacplus, mod_auth_tacacs

Tacppd is an open source implementation of the Cisco proprietary TACACS+ AAA protocol. Theimplementation at this point in time is quite basic, and is mainly limited to operation with Ciscoproducts. The EAP protocol is not supported, and there's support for one database only: Postgr-eSQL. Furthermore, it seems like this project is also a one-man project. Tacppd doesn't seem to be areal alternative to the use of a RADIUS server, also because of the fact that TACACS+ is a propriet-ary protocol. Tacppd does come with some useful additions however: libtacplus andmod_auth_tacacs. The first of these is a code library with which TACACS+ authentication calls canbe made or received easily. The last of these is an authentication module for use in the Apache webserver.

81

4.1.7.2.5. ACE RADIUS library and OpenDiameter

Both ACE RADIUS and OpenDiameter aren't server products, but code libraries. Which means theyare not usable for immediate deployment of an AAA server. They might, however, come in handyfor the same reason as libtacplus: making external authentication calls to an AAA server of anothertype (in this case RADIUS or Diameter). ACE RADIUS seems to be not quite mature yet, it is stillin beta stage. It also seems that ACE RADIUS does not support EAP, and as such is not quite an in-teresting option. OpenDiameter however seems to be more mature, having support for several EAPprotocol types, and even more on the way. The next version will even support 802.1X and supportfor using the library for software that implements either the supplicant, the authenticator or the au-thentication server. Future releases will also include support for RADIUS.

4.1.7.2.6. Open1X

Open1X is an open source implementation of the IEEE 802.1X protocol. It only focuses on the sup-plicant and authenticator part (and the authenticator part isn't in active development at the moment).Many EAP protocols are supported, including: EAP-MD5, EAP-MSCHAPv2, LEAP, PEAP, EAP-TLS and EAP-TTLS. Recall that the supplicant is the network client who tries to authenticate to anetwork service. This means that Open1X is primarily meant for the users of a wireless network andin this case only those who use Linux as their operating system. Most probably Mobidot will notneed this software, unless it is decided the users of the Mobidot need to install custom software inorder to be able to get a connection.

4.1.7.3. The chosen solutionFor several reasons FreeRADIUS has been chosen as the AAA server of preference. First of all, it ismost probably the most widespread used type. Diameter is a relatively new open source alternative.TACACS+ is a Cisco proprietary implementation. There's no good open source server implementa-tion of TACACS+, as such it cannot be used anyway. Some good libraries for TACACS+ have beenfound however, so theoretically it's possible to extend FreeRADIUS with TACACS+ support, thehooks for such extensions are already available in FreeRADIUS. Further, FreeRADIUS is the onlyone supporting EAP. Since EAP is part of 802.1X/802.11i, the new upcoming security standard forwireless technology, it might be a wise decision to choose a solution which is already capable ofdealing with EAP. Finally, FreeRADIUS supports fail-over which a requirement for setups in whichthe AAA server plays such a central role as it does in the Mobidot infrastructure.

4.2. Implementation4.2.1. Implementing the management system

The implementation of the management system was quite comprehensive and took just a bit lessthan a quarter of the entire project duration, totaling 7747 lines of PHP code and 799 lines ofHTML. Although quite some design changes took place during this period, the requirements wereimplemented easily due to the clear structure of the system.

One of the largest changes in the project was in the set of use cases. At first various use cases weredefined very distinctively from one another, including: PutHotspotUp, PutHotspotDownForMain-tenance, DeployNewAPFirmware, DeployNewHotspotConfiguration, PutFirewallTunnelUp, Put-

82

FirewallTunnelDown, SendNetworkAnnouncement and RetrieveUsageStatistics. Due to the fact thatmost of these use cases are quite different from the other use cases means the design can get(unnecessarily) complicated.

The first choice was to drop the use case RetrieveUsageStatistics. This use case was introduced forroaming partners to retrieve usage information of their users who have roamed onto the Mobidotnetwork. This information can however be sent automatically (without user initiation) to the roam-ing partner by means of an extension of the RADIUS protocol, and this functionality is implementedby the Chillispot captive portal.

Another choice was to embed SendNetworkAnnouncement into the management of hotspots and ac-cess points. Essentially a network announcement needs to be sent only when the hotspot goes downtemporarily for maintenance, it preferably will never be needed for any other cause, as we don'twant to bother the user too much. As such it is unnecessary to model it as a separate use case.

Yet another choice which led to the removal of use cases was the choice to use permanent firewalltunnels instead of temporary firewall tunnels. These tunnels are needed to enable the use of proto-cols such as SNMP in cases where the Mobidot AP is not directly addressable, for example inSNAT-enabled networks. The reason why this was needed will be discussed in the 'Problem domain'section of the first chapter. This choice led to the removal of the PutFirewallTunnelUp and PutFire-wallTunnelDown use cases.

The final choice (related to the changes in use cases) was composed of the removal of several usecases, but all for the same reason. The remaining use cases in essence all adjust the state of the sys-tem in one way or another. Such actions can be caught in general management use cases. For ex-ample PutHotspotUp and PutHotspotDownForMaintenance just adjust the status of a hotspot, andbasically are edit operations in the management of hotspots. Further, DeployNewAPFirmware basic-ally is an add operation in a firmware management use case. The DeployNewHotspotConfigurationuse case can be dealt with in the same way. Due to these changes also a new composite use case isintroduced: ManageFirmware.

Some other changes were made in the modeling of parts of the system in terms of class diagrams.First of all, during the design phase the choice was made to create helper classes which would aid inthe creation of the necessary HTML output. During the implementation however, a very handy tem-plate engine was found, which could generate HTML from text files with variable substitution. Dueto the use of this engine, the helper classes could be dropped. Another, more important, designchange was the choice to drop the differentiation between master and slave access points. Rather,access points would be looked at as stand alone units. Each access point offers wireless access to theneighborhood it is placed in, and as such it doesn't need to know about fellow access points. It onlyneeds to deal with wireless IP traffic, and it needs to know where to hand it off to.

Further, the distinction between Mobidot users and users from roaming partners was dropped, asthis is (in terms of usage logging, authentication checks, etc) already taken care of by Chillispot.From then on, users would be modeled by an UserAccount object, making the design again easier.Lastly, having separate Status classes (HotspotStatus, APStatus) also made the design unnecessarydifficult, particularly because there is little status information, so it can just as well be handled in-side the Hotspot and AP objects.

Finally, a problem was encountered in the storage back ends. It was chosen to implemented it in avery general manner, such that it can be reused for storing any type of information. This was doneusing the bridge pattern, and using only a pre-defined set of functions in the implementer classes. As

83

such there were basically four operations: get, insert, update and delete. This however limits the us-ability of the storage back end, as it can only perform as much as these pre-defined functions canperform. Without adding functions it was possible to add just enough functionality to the existingfunctions to support more extensive queries, i.e. for sorting data in a particular order, paginate re-cords and operate on multiple sets of data in one shot. This was done by using arguments whichwere unused by default, unless they would have a value. Further, in situations where it was needed,database transactions would be composed of multiple queries, i.e. creating, updating or deleting con-figurations, including their firewall and traffic shaping configurations.

4.2.2. Implementing the firmwareThe implementation of the firmware took a bit more than an eighth of the entire project duration,totaling 626 lines of C code and 440 lines of shell script code (bash script code; the awk code whichis embedded in the bash script code will amount to even more lines of code). It consisted of an in-vestigation as to how the firmware works and how it can be extended, and of the implementation ofthe Mobidot extensions that were needed. One important part was understanding how the build rootof the firmware works. The build root is the collection of files that makes up the source of the firm-ware, and which can be used to make a new firmware from scratch. Adding extensions to the Open-WRT firmware was found to be considerably easier than with the other investigated firmware: someminor modifications in configuration and make files and the addition of a small makefile and con-figuration file were needed. This, as opposed to the other firmware, where extensibility is reachedby hacking in the new features.

OpenWRT eases the customization of firmware (as in choosing which software to install in the firm-ware) considerably. Unlike the other firmware, OpenWRT allows to select the packages that arewanted in a menu driven program. After having configured the base firmware configuration, theneeded extensions of the firmware still need to be implemented. The extensions that are needed per-form a specific set of functions. After an access point has been acquired it's got a default installationof a stock Linksys firmware, which is totally inadequate, due to its generality. When the Mobidotspecific firmware is installed a series of actions is performed. First it makes sure there's a functionalInternet connection. If there is none, it tries getting an address using DHCP. If that fails, an HTTPdaemon is launched which enables the user to visit a specific website. This website enables the userto enter specific Internet connection settings. Preferably this wouldn't be needed on-site, as weprefer to deliver the access point to clients, having them connect the access point and then havingthe access point installing itself completely unattended. In this case however, the settings are secur-ity sensitive. Storing them centrally is a potential security problem (even more because the Internetconnection settings, including passwords, are client specific and not Mobidot's). When the Internetconnection is successfully setup, we can continue installing the firmware. Due to storage constraintsit was chosen to leave out as much functionality as possible, only installing on demand what isneeded using packages. The access point at this point downloads a script from the central Mobidotsystem, trying indefinitely when failing. This script takes care of installing the needed packages andconfiguring them according to the settings as defined in the management panel. When this is fin-ished, the access point is ready for use. From then on it will run the same script on an hourly basis,only updating the system if necessary, both in terms of packages (installations and deletions) and interms of configuration settings.

Undoubtedly the most difficult thing of implementing the firmware extensions was the fact that theaccess point has no console, not even the possibility for a serial console. In combination with shellscripts this led to quite a few difficult situations. Shell scripting languages are interpreted languages,

84

meaning they don't get compiled and thus there are no checks on syntax and semantic errors. Theonly way of knowing whether a script works is by running it. However one needs to be very cau-tious, because one bad command in the script can render the access point unusable.

85

Chapter 5. Evaluation5.1. Test setup

In the case of the management system, testing wasn't that difficult. Due to the fact the managementsystem has been written as a web application, it could be tested on any workstation. It was howeverneeded to have installed multiple web browsers, in order to ensure browser independence. In thiscase the system was tested using both a Windows XP and a Debian Linux OS. Windows XP wasequipped with both Internet Explorer version 6 and with Firefox version 1. Debian was equippedwith Firefox 1. Ensuring the website runs well inside Firefox means web browsers like Mozilla (theoriginal, not Firefox) and Netscape 7+ are covered too, since they use the same HTML engine asFirefox. Besides a workstation, a server was needed too, on which the management system would beinstalled. A server which was already in the air for purposes like this fitted the job nicely. The serverhad Debian Linux pre installed, and already had an Apache web server and PHP4 engine installed.

In the case of the firmware, things were a little bit more difficult. In this situation the same worksta-tion and server are needed. However, in this case the workstation needed to be configured with mul-tiple IP addresses in a different range, due to the fact the access point can only be flashed with newfirmware on a fixed IP address. Of course, in order to test the firmware, the access point itself isneeded, of which three were available all having a different revision (unfortunately no emulatorcould be found which could run the firmware before deploying it onto hardware). This could beused in order to test whether the firmware works across different revisions, as Linksys has changedsome hardware components between various revisions.

5.2. Test procedure and approach5.2.1. Development tests

Testing actually can be two separate things. For one, testing can mean testing the low level function-ality of the program: do the methods of the program perform their functions as they should? This isknown as unit testing. On the other hand, testing also means testing the program as a whole. Doesthe program expose errors when the individual subsystems are combined when executing the pro-gram? This is otherwise known as integration testing. Lastly, does it perform the actions which aredefined in the requirements document? Can the functionality as provided by the program be used inan intuitive way? This is also known as system testing.

All three testing methods have been applied, although the first one in a different way than usual.First of all, unit testing is not as well supported by tools under PHP as under languages such as Java.This means that a lot of programming has to be done in order to unit test the various classes.However, since the classes in themselves aren't that difficult (most of them anyway), it was chosento do unit testing by logical reasoning. Just by reasoning what would happen if a certain class wouldbe used resulted in quite a few bugs fixed, mainly logical bugs; syntactic and semantic errors arecaught by PHP upon execution of the program. Further, the classes would be tested anyway whilsttesting the functionality of the program as it is exposed to the user (during integration testing).

So the testing approach consisted mainly of actively testing the user functionality of the program

87

while it was implemented (ongoing integration testing). The system would be expanded feature byfeature, implementing a new one when the old one tested successfully. So basically each time a newuse case was implemented it would be tested right away by a new test case. Finally, the programwould again be tested on its user functionality once everything was implemented, using the sametest cases, but performing the tested actions in multiple ways. This was done to catch bugs whichonly come forth when executing functionality in a program in a certain order.

Finally, the final testing phase consisted of some functional testing (testing the requirements of theRAD), and some performance testing (testing non functional requirements and design goals), in oth-er words this phase performed the system testing. Another part of system testing is the acceptancetesting, which is discussed below in section 'Pilot tests'.

5.2.2. Pilot testsPilot testing was arranged by the suppliers of the assignment at some locations in Delft, namely twohotels and a campsite. This would only be performed however if the system proved to be sufficientto supply these hotels and campsite with a working setup. The judgment in this was done solely bythe suppliers of the assignment. Due to the fact that the system proved not be 100% sufficient, it waschosen not to perform the pilot tests. The reasons why are documented below in the test results.

5.3. Test resultsIn this section the results of the testing phase are discussed. Not all problems and bugs will be dis-cussed. A short overview will be given, discussing the problems or bugs that might introduceneeded design changes. Depending on the estimated time needed to implemented these changes andthe necessity of these changes in relation to the efficiency gained by them, they might or might nothave been implemented. In some cases the changes would result in a better thought out design, but itwouldn't give performance gains. As such these changes have not been implemented, but rather doc-umented in order to learn from them for future projects. The testing results will now be discussedseparately for the firmware part and for the management part of the system.

5.3.1. The firmwareThe largest problem with the firmware was the state of the build root of OpenWRT. It was in betaduring the thesis project, as such not ready for production use. This became clear during a late phaseof the project. One of the largest problems was the fact that the firmware can lock up the hardware itruns on, needing a hard reset in order to continue. This happened regularly (but not always) wheninstalling the Mobidot firmware on the router. After successfully installing all needed packages, therouter would initiate a reboot in order to begin serving user requests. During this reboot the routerlocked up various times. This was the main reason not to continue the pilot projects. Another prob-lem was the fact that the used OpenWRT version wasn't ready for Linux kernel 2.6, meaning sup-port for traffic shaping wasn't as extensive as needed. In order to provide wireless Internet access athotspots with evenly divided bandwidth, extensive traffic shaping is needed. Because of these twoproblems the pilot projects were delayed. These problems however weren't important enough tochoose another build root, such as Sveasoft for example. The better design of OpenWRT comparedto other build roots outweighs the temporary functional problems of the OpenWRT build root.

Another problem, but which was easily fixed, was a bug in one of the scripting engines used in the

88

firmware (grep). The Mobidot installation scripts needed this tool for information about neededpackages, where to get them and how to install them. The script however had a memory problem: itallocated too much memory due to the use of certain options. This resulted in the router running outof memory. The problem was solved by approaching the wanted functionality from a differentangle, using a different tool (awk).

5.3.2. The management systemOn the management side some problems have been found too. The first problem that was discovereddeals with the configuration of access points. While it is possible to configure the firewall and trafficshaping through the management panel, there is no dedicated structure for managing other configur-ation settings which are set in the router in so called non-volatile RAM variables. While most ofthese are related to the firewall (or security in general), they can be set in the firewall script. Itwould have been more nice however to have a separate management function for controlling thevarious nvram variables.

Another problem is with multiple access points at one site. While it was chosen not to focus on mas-ter-slave configurations due to time constraints, it would've been possible to implement featureswhich in the future can be used to setup these configurations. A technology known as Wireless Dis-tribution System can support radio communication between access points using the same wirelesstechnology. While it is still in beta in OpenWRT, it would've been better to prematurely support itby adding configuration possibilities.

The last problem actually relates to both the management system and the firmware. At this momentit is possible to set network announcements, which should be shown to users in case of temporaryunavailability of the system. The problem at this point however is that these messages cannot al-ways be shown. When someone logs in using a web browser, these messages will eventually beshown in the pop up screen which is shown after logging in. If someone logs in using WPA (whichfor the time being is not supported) however, all authentication is done outside a browser, meaningno messages can be communicated to the user.

5.3.3. Results of system testingDuring system testing it was found that most requirements are implemented, and worked well. Thefunctional and performance tests, which are part of the system tests, will be discussed now.

5.3.3.1. Functional testingThe functional requirement 'Bandwidth adjustment per hotspot' has only been partly implemented,since OpenWRT doesn't support traffic shaping well yet. 'Live roaming' is not yet supported, sincethis should be taken care of by the captive portal which doesn't support it yet. Due to the fact that thesolution to the SNAT circumvention has only been designed, but not implemented, it is for the timebeing not possible to get 'Status overviews'. The addition of SNMP would be needed also, whichmeans a steep learning curve (difficult protocol) and the application for Mobidot specific MIBs (setsof SNMP attributes) at the IANA (Internet Assigned Numbers Authority; the organization that's theauthority which deals with the assignment of IP addresses and the birth of new top level domainnames), which would take a fair amount of time. The 'monitoring', 'status/statistical information sup-ply', and 'presence announcements' are closely related to the 'Status overview', and are not imple-mented for the same reason.

89

5.3.3.2. Performance testingThe requirements 'Fair use' and 'Basic bandwidth availability' are related to the 'Bandwidth adjust-ment per hotspot' functional requirement, they have not been implemented for the same reasons. 'Op-tional extra security for users' is not completely implemented since it's not within the main focus ofthe project: the goal was to create a well thought out design, and implement as much as possible.Since the system isn't production ready yet, missing the optional extra security isn't a problem, andcan easily be added later. All needed hooks for it are already available in the firmware. Finally, itwas found to be impossible to detect Rogue APs in an easy way, and even more to warn users aboutthem. As such that requirement has not been met, it can however easily be met by certain EAP pro-tocols (i.e. EAP-TTLS) which most probably will be used in the future.

5.3.3.3. Acceptance and installation testingThis testing approach has not been performed due to the unstable and incomplete state of the Open-WRT build root, as discussed earlier.

90

Chapter 6. ConclusionsThis chapter contains conclusions as they were made for the Mobidot infrastructure project. An ab-stract overview of the project is given, further some sub-optimal approaches will be discussed fromwhich can be learned for future projects. Finally a discussion about how the project was perceived,the overall feeling of the author is described. The chapter ends with a discussion containing generalconclusions about how the entire study at the Technical University of Delft was perceived.

6.1. Project specific conclusionsIn this project an infrastructure has been designed and built which is used to provide the user with awireless connection to the Internet. While the hotspot visitor is the main user of the product, it is notthe main actor we are aiming at. The problem that was perceived is the fact that current solutions arequite expensive, too expensive for low budget institutions such as small hotels and small restaurants.The intention of this project was to create a working solution for public wireless networks at a frac-tion of the cost of current solutions. The two largest cost factors with current solutions are the in-vestment in the equipment and the installation and maintenance by a mechanic. As such, we areaiming at the managers of public (low budget) institutions. The project is renewing in that it reachesnear full automation. This is achieved by making the product plug 'n play, and by applying activemonitoring of the devices. Since the solution is aimed to be low budget, broken installations caneasily be replaced by new ones. Thus keeping down times to a minimum and at the same time keep-ing maintenance costs low. Another renewing aspect (to a lesser extent though) of the project is thefact that roaming will be possible, even though the solution is low budget. This means users of otherWi-Fi suppliers can roam to the Mobidot network, keeping their number of contracts for digitalcommunication services to a minimum.

This project has aimed at creating a well thought out design, instead of a fully working solution witha bad design. This means most of the time has been put in the design, and less in the implementa-tion. As such not all functionality is implemented, although most of it is. Things that have been de-signed but not implemented include monitoring, setups with multiple cooperating access points andVPN security on the WLAN. After this project is finished it is easily possible to add these featuresto complete the solution to a production ready system.

Especially the first two phases of the project, the analysis and design, took a lot of time. In this casethe problem domain is hard to grasp. This is because it is very unclear at the start of the projectwhich systems and actors play a role in this infrastructure, as there are quite a few. Once all require-ments, needed functionality, involved actors and systems and dependencies between systems hadbeen defined and modeled, implementation could be quickly done.

The project suffered some failings mainly because of external factors. Due to the fact that theproject plays in a new field, and is dependent on quite a few other products, the possibilities for athesis project are limited to what these products can deliver. The largest problem in this was thefirmware for the access points. All firmware except one were found to be badly designed and notuseful for this project. The firmware that was found to be well designed and useful, OpenWRT, hadsome maturity problems though. Once this firmware matures, the solution can be finished to be aproduction ready system.

The project was perceived as difficult but interesting. A lot of aspects of the project, including wire-

91

less technology in itself were new to the author. It was interesting to see how one can develop fromknowing near to nothing about a certain subject, to building an entire system in the respective sub-ject. During the study only small, confined exercises have been performed. Never before there'sbeen a large solitary project such as the thesis project. It is interesting to see how one develops fromhaving no idea on how to solve a certain problem, to having extensive knowledge of the variousways to solve such a problem, and design and develop a system to fit that solution. During the study,various courses have been given on a wide variation of subjects. During the thesis project this know-ledge is structured and organized, and this has happened in a satisfactory way. A system has beencreated in a project which was walked through completely from inception to completion, applyingpreviously gained knowledge and researching needed new knowledge. Getting the responsibility tomake the necessary choices and accepting that responsibility to the fullest, shows that the study asprovided by the TUDelft has attained its goal: to deliver quality engineers.

The guidance in the project was perceived as pleasant. The emphasis of the guidance was exactly inthe right area, where it was needed: overall project management, and documentation. Especially de-termining the right audience, and aiming the documentation at that audience was needed and wasguided in an excellent way. Finally, the guidance was excellent in the design of the system. Whilesystem design has been educated at the university, it has only been practiced minimally. Applying itto a large project was a large step to take, and the guidance in this was very satisfactory. The overallproject was perceived as very useful and contributing a lot to personal growth, both in the field ofwork of ICT, and in the field of finding a barrier between work and free time and making sure thatbarrier wouldn't shift too much.

6.2. General conclusionsAfter almost eight years of studying at the TUDelft, the end of this life period is quite near, gettingready to transition to a completely autonomous existence. The time spent at the TUDelft overall hasbeen perceived as pleasant.

The study period not only has made me grow from novice to expert on a professional level. It hasalso made me grow on a personal level, in relation to being with other people, getting to be moreopen to other people and getting a broader perspective upon the world. Personally, one of the mostinteresting aspects of the study was the fact of getting in contact with people from varying religiousand cultural backgrounds. Getting to know these people and their backgrounds was a privilege, andan eye-opening experience. An experience of personal growth that, I believe, many conservativepeople lack. I've met people both with quite strict religious beliefs and quite loose religious beliefs.

During this study some people were more important to me than others, mainly because a lot of mypersonal growth can be contributed to them. Michele Buonaiuto, an Italian from Napoli, who hasbeen my study partner for nearly the entire study (except for the first quarter) has played an import-ant role in my pleasure of studying at the TUDelft. Doing a lot of projects with him was a joy, I'vebeen with him through better and through worse. Another important person during my study wasVahid Shafiei (Iranian). One of the reasons my study took eight years instead of five is the amountof maths. Vahid was the one with whom I found the needed discipline to finish most remainingmaths courses in the fourth year: maths for 8 hours a day, 6 days a week for 9 months. Solving a dif-ficult exercise was a joy and would always go hand in hand with a necessary dose of humor. Hisview upon the world and his intellectual thinking (he has done a philosophy study in Iran) made it ajoy to spend time with him. During later phases of my study, I started to work as a student assistantfor the TUDelft. First for the Computer Organization course (2001, 2003), from September 2003 on

92

as a helpdesk employee at the Practicumgroep Zuid-Plantsoen. It was here where I met Wim Haanof whom I found out to be quite the same person as I am. Sharing much of the same beliefs andworking together fluently has resulted in starting our own business together. Finally LucasBreedveld, Mohammad Sobat and Shuai She, whom I have enjoyed working with on variousprojects but also outside college hours.

When it comes to the study itself, I'm for the most part pleased with how things went. With trueComputer Science courses I didn't have much trouble passing them. First of all I'm quite interestedin a diverse set of subjects, which made it even easier. With maths courses I had more problemshowever. While the material isn't that fundamentally difficult, my old studying method didn't workfor these courses, a lot more discipline and dedication was needed to pass these courses. Finally,when it comes to societal courses, things were quite a lot worse. I find that the respective teachershave a hard time bringing the learning material in an enjoyable way, much like my history classes inhigh school. About the only examination method with these courses was to ask for lists of dates(milestones in history), characteristics of something (name all advantages and disadvantages of aparticular approach), etc. Such educational methods don't make the material interesting, and thus failto being effective in transferring knowledge. One other unfortunate thing is that I had to put quitesome time into maths, which makes it look like maths is all I did in my study. One thing I structur-ally missed in the study is ongoing practice in software design and project management. There areonly about two courses dealing with software design, and only halfway the third year, project man-agement is taught. More attention is given to programming, while this should be the other wayaround, since a university (I think) is supposed to aim at a more abstract level.

When it comes to the TUDelft as an organization, I believe in essence it means well, but fails to be-come one of a kind. This is reflected in the latest reorganization plans, in which a way of workingmuch like the University of Twente and TU of Eindhoven is trying to be achieved. Instead theTUDelft should find its own way of doing things best. One of the things in which TUDelft excelled,and for which many foreign students came to Delft, was Information Systems. Instead of dumpingthis at another faculty, it should have gotten more privilege.

All in all, I had a great time at the TU Delft. Thanks to everyone who made it a wonderful experi-ence, including: Michele Buonaiuto, Wim Haan, Vahid Shafiei, Mohammad Sobat, LucasBreedveld, Shuai She, Hattat el Hammouchi, George Stere, Naim Larbi, Abdulhakim Boztas, FirasAlHassany, Noureddine Ou-Aissa, Chakib Boucharraba, Nahil Celikoglu, Aqab Bin Talal, SabitAsholi, Ravi Chablani, Joost Hietbrink, Michele Nijhuis, Wijnand Post, Hamid Safari, LeonPlanken, Azad Imamoglu, Serap Boduc, Bas Schopman, Amros Karbor, Amad Zawity, Denis deLeeuw Duarte, Jun Chen Chen, Michel Meulpolder, Sander Koning, Mustapha Idrissi, Reza Sum-ampouw, Miriam ter Brake, Ronald Huizer, Lieuwe Jan Koning, Serkan Eskici, Osman Zemouri.

93

Appendix A. ReferencesA.1. Books

• Networking in general

1. [Dyson1994] Peter Dyson - Dictionary of networking

The Network Press, 1994, 2nd edition

ISBN 0-7821-1818-6

2. [Tanenbaum1996] Andrew S. Tanenbaum - Computer Networks

Prentice Hall, Inc, 1996, 3rd edition

ISBN 0-13-394248-1

• Security

1. [Laet2004] Gert de Laet and Gert Schauwers - Network Security Fundamentals

Cisco Press, Sep. 2004

ISBN 1-587051672

2. [Lubbe1997] J.C.A. van der Lubbe - Basismethoden cryptografie

Delftse Universitaire Pers, 1997, Tweede druk

ISBN 90-407-1256-5

• Wi-Fi

1. [Roshan2003] Pejman Roshan and Jonathan Leary - 802.11 Wireless LAN Fundamentals

Cisco Press, Dec. 2003

ISBN 1-58705-077-3

• Various

1. [Franssen2002] Maarten Franssen - Methodologie en Ethiek van de Techniek

TUDelft Fac. TBM, sectie Filosofie, Maart 2002

A.2. Articles and other documents

95

• Network structures

1. [Epema2003] DHJ Epema - Distributed Systems

Course IN4002 on http://blackboard.icto.tudelft.nl, file book2003.pdf

2. [Minar2002] Nelson Minar - Distributed Systems Topologies

http://www.openp2p.com/pub/a/p2p/2001/12/14/topologies_one.html

http://www.openp2p.com/pub/a/p2p/2002/01/08/p2p_topologies_pt2.html

• Wi-Fi

1. [Register1] The Register - Will pressure to speed up 802.11n wreck standards process?

http://www.theregister.co.uk/2004/01/16/will_pressure_to_speed_up/

2. [Wifinetnews1] Wi-Fi Networking News - 802.11n Archives

http://wifinetnews.com/archives/cat_80211n.html

3. [NWFusion1] NetworkWorldFusion - 802.11n

http://www.nwfusion.com/details/6450.html?def

• Wireless technologies other than Wi-Fi

1. [Cohen2003] Cohen & Deutsch - 802.16: A Look Under The Hood

http://www.Wi-Fiplanet.com/tutorials/article.php/10724_3068551_1

2. [Lipset2003] Lipset - 802.16e vs 802.20

http://www.Wi-Fiplanet.com/tutorials/article.php/3072471

3. [Geier2003] Geier - 802.16: A Future Option for Wireless MANs


4. [Cohen2003-2] Cohen & Deutsch - 802.16: The Future in Last Mile Wireless Connectivity


5. [UMTSForum1] UMTS Forum - What is UMTS?

ht-tp://www.umts-forum.org/servlet/dycon/ztumts/umts/Live/en/umts/What+is+UMTS_index

• Security

1. [Arbaugh2001] Arbaugh, Shankar, Wan - Your 802.11 Wireless Network has No Clothes

http://www.cs.umd.edu/~waa/wireless.pdf

2. [Borisov2001] Borisov, Goldberg, Wagner - Intercepting Mobile Communications, The In-

96

security of 802.11

http://www.isaac.cs.berkeley.edu/isaac/mobicom.pdf

3. [Gast2002] Matthew Gast - Wireless LAN security, a short history

http://www.oreillynet.com/pub/a/wireless/2002/04/19/security.html

4. [Dismukes2002] Trey Dismukes - Wireless Security Blackpaper

http://arstechnica.com/articles/paedia/security.ars

5. [Strand2004] Lars Strand - 802.1X Port-Based Authentication HOWTO

http://tldp.org/HOWTO/8021X-HOWTO/intro.html#what80211i

6. [Viney2004] Boden-Cummins, Viney - IPSEC over WLAN: residual vulnerabilities

ht-tp://www.qinetiq.com/home/core_skills/knowledge_information_and_systems/trusted_information_management/white_paper_index.Par.0014.File.pdf

7. [Airespace1] Airespace.com - Authentication and Encryption in an Enterprise WirelessLAN

http://www.airespace.com/technology/technote_auth_enc_wlan.php

8. [AESLounge1] AES Lounge website

http://www.iaik.tu-graz.ac.at/research/krypto/AES/

• Corporate Networks

1. [Davis2004] Jeff Davis - Centralized Wireless LAN, Thin vs Fat Technology

http://www.cablingbusiness.com/pdfs/storynov04.pdf

• Networking in general

1. [Titz2001] Olaf Titz - Why TCP Over TCP Is A Bad Idea

http://sites.inka.de/sites/bigred/devel/tcp-tcp.html

2. [Fratto2000] Mike Fratto - Why Can't IPsec and NAT Just Get Along?

http://www.networkcomputing.com/1123/1123ws2.html

3. [Hubert2003] Bert Hubert - Linux Advanced Routing & Traffic Control

http://www.lartc.org/

4. [Titz2004] Olaf Titz - CIPE Manual

http://sites.inka.de/sites/bigred/devel/cipe-doc/cipe.html

97

5. [Hardin2000] John D. Hardin - Linux VPN Masquerade HOWTO

http://www.linux.org/docs/ldp/howto/VPN-Masquerade-HOWTO.html

6. [Geier2002] Jim Geier - 802.11 Beacons Revealed

http://www.Wi-Fiplanet.com/tutorials/print.php/1492071

7. [Geier2002-2] Jim Geier - 802.11 Alphabet Soup

http://www.Wi-Fiplanet.com/tutorials/article.php/10724_1439551_1

8. [CABA1] CABA - WiMedia (802.15.3) Standards & Protocols

http://www.caba.org/standard/wimedia.html

9. [Hirt2003] Hirt & Porcino - Ultra-Wideband Radio Technology: Potential and ChallengesAhead

Course SPM9612 on http://blackboard.icto.tudelft.nl, file hirt.pdf

10. [Duarte2001] Duarte - UMTS: challenges and perspectives

Course SPM9612 on http://blackboard.icto.tudelft.nl, file UMTS_04duargb.pdf

11. [Javvin1] Protocol Dictionary - TACACS

http://www.javvin.com/protocolTACACS.html

12. [OpenDiameter1] Open Diameter Web Site

http://www.opendiameter.org/

13. [SearchSecurity1] searchSecurity.com Definitions - RADIUS

http://searchsecurity.techtarget.com/sDefinition/0,,sid14_gci214249,00.html

14. [Open1X1] Open1x -- Open Source Implementation of IEEE 802.1x

http://open1x.sourceforge.net/

• Definitions and examples

1. [Hp1] HP - Glossary for mobile development - V

ht-tp://h21007.www2.hp.com/dspp/tech/tech_TechDocumentDetailPage_IDX/1,1701,1383,00.html

2. [Apache1] Apache - Authentication, Authorization, and Access Control

http://httpd.apache.org/docs/howto/auth.html

3. [TCPIPGuide1] TCPIP Guide - IPSec Encapsulating Security Payload (ESP)

98

http://www.tcpipguide.com/free/t_IPSecEncapsulatingSecurityPayloadESP-4.htm

4. [TCPIPGuide2] TCPIP Guide - IPSec Security Associations page 1

ht-tp://www.tcpipguide.com/free/t_IPSecSecurityAssociationsandtheSecurityAssociation.htm

5. [TCPIPGuide3] TCPIP Guide - IPSec Security Associations page 2

ht-tp://www.tcpipguide.com/free/t_IPSecSecurityAssociationsandtheSecurityAssociation-2.htm

6. [Webopedia1] Webopedia - Network Topologies

http://www.webopedia.com/quick_ref/topologies.asp

7. [Webopedia2] Webopedia - 802.11

http://www.webopedia.com/TERM/8/802_11.html

8. [Webopedia3] Webopedia - pluggable authentication module

http://itmanagement.webopedia.com/TERM/P/pluggable_authentication_module.html

9. [Webopedia4] Webopedia - SNMP

http://www.webopedia.com/TERM/S/SNMP.html

10. [Webopedia5] Webopedia - Failover

http://www.webopedia.com/TERM/F/failover.html

11. [Webopedia6] Webopedia - Load Balancing

http://www.webopedia.com/TERM/l/load_balancing.html

12. [Webopedia7] Webopedia - Watchdog

http://winplanet.webopedia.com/TERM/W/watchdog.html

13. [Webopedia8] Webopedia - PCMCIA

http://www.webopedia.com/TERM/P/PCMCIA.html

14. [Webopedia9] Webopedia - PC Card

http://www.webopedia.com/TERM/P/PC_card.html

15. [Webopedia10] Webopedia - CardBus

http://ecrmguide.webopedia.com/TERM/C/CardBus.html

16. [Webopedia11] Webopedia - PCI

99

http://www.webopedia.com/TERM/P/PCI.html

17. [Webopedia12] Webopedia - Tunneling

http://winplanet.webopedia.com/TERM/T/tunneling.html

18. [Rescomp1] Rescomp SNMP Howto - Overview

ht-tp://www.rescomp.berkeley.edu/about/training/senior/progs/SNMP-HOWTO/SNMP-HOWTO-1.html

19. [Wikipedia1] Wikipedia - L2TP

http://en.wikipedia.org/wiki/L2TP

20. [Wikipedia2] Wikipedia - PPTP

http://en.wikipedia.org/wiki/Point-to-Point_Tunneling_Protocol

21. [Wikipedia3] Wikipedia - Firewall (networking)

http://en.wikipedia.org/wiki/Firewall_%28networking%29

22. [Wikipedia4] Wikipedia - Packet filter

http://en.wikipedia.org/wiki/Packet_filter

23. [Wikipedia5] Wikipedia - TKIP

http://en.wikipedia.org/wiki/TKIP

24. [Wikipedia6] Wikipedia - SSL

http://en.wikipedia.org/wiki/Secure_Sockets_Layer

25. [Wikipedia7] Wikipedia - Challenge-response test

http://en.wikipedia.org/wiki/Challenge-response_test

26. [Wikipedia8] Wikipedia - Challenge-response authentication

http://en.wikipedia.org/wiki/Challenge-response_authentication

27. [Wikipedia9] Wikipedia - Roaming

http://en.wikipedia.org/wiki/Roaming

28. [Wikipedia10] Wikipedia - Simple Network Management Protocol

http://en.wikipedia.org/wiki/Simple_network_management_protocol

29. [Wikipedia11] Wikipedia - Management information base

http://en.wikipedia.org/wiki/Management_information_base

100

30. [Wikipedia12] Wikipedia - Abstract syntax notation one

http://en.wikipedia.org/wiki/ASN.1

31. [Wikipedia13] Wikipedia - Protocol data unit

http://en.wikipedia.org/wiki/Protocol_data_unit

32. [Wikipedia14] Wikipedia - Kernel

http://en.wikipedia.org/wiki/Kernel_(computers)

33. [Wikipedia15] Wikipedia - User space

http://en.wikipedia.org/wiki/User_space

34. [Wikipedia16] Wikipedia - Webmin

http://en.wikipedia.org/wiki/Webmin

35. [MLIP1] ML IP - Network Address Translation (NAT)

http://www.ml-ip.com/html/support/glossary.html

36. [Vigyan1] Vigyanprasar website - what does HAM really mean?

http://www.vigyanprasar.com/ham/MEANING.htm

37. [Imms1] Insurance Marketing & Management Services - Cyber-Glossary

http://www.imms.com/cyberglos/

38. [ITSecurity1] ITSecurity.com Dictionary - Spoofing

http://www.itsecurity.com/dictionary/spoof.htm

39. [ITSecurity2] ITSecurity.com Dictionary - Sniffer

http://www.itsecurity.com/dictionary/sniffer.htm

40. [FFIEC1] Federal Financial Institutions Examination Council - Glossary

http://www.ffiec.gov/ffiecinfobase/booklets/information_security/08_glossary.html

41. [Cryptomathic1] Cryptomathic Labs - Technical Dictionary

http://www.cryptomathic.com/labs/techdict.html

42. [Stallion1] Stallion Support Services - Glossary of Terms

http://www.stallion.com/html/support/glossary.html

43. [ZIDDokus1] ZID Dokus - Glossary of ATM Terms and Acronyms

http://www.edvz.uni-linz.ac.at/dokus/atm.html

101

44. [Devx1] DevX - Wireless Glossary: 1G

http://www.devx.com/wireless/Door/11259



46. [Devx3] DevX - Wireless Glossary: 2.5G




• Standards, RFCs and lists

1. [802.1X-2001] Port-Based Network Access Control (802.1X-2001)

http://standards.ieee.org/getieee802/download/802.1X-2001.pdf

2. [RFC3748] RFC3748: Extensible Authentication Protocol (EAP)

http://www.ietf.org/rfc/rfc3748.txt

3. [RFC1701] RFC1701: Generic Routing Encapsulation (GRE)

http://www.ietf.org/rfc/rfc1701.txt

4. [IANA1] Extensible Authentication Protocol (EAP) Registry

http://www.iana.org/assignments/eap-numbers

A.3. Various references

1. [TMobile1] T-Mobile website - Rate Plan

https://selfcare.hotspot.t-mobile.com/RatePlan.do

2. [Picopoint1] Picopoint website - frontpage

http://www.picopoint.com/

3. [Picopoint2] Picopoint website - services

http://www.picopoint.com/services.php

4. [GBIA1] GBIA website - frontpage

http://www.gbia.com/

102

5. [Planetnl1] Planet.nl website - Wi-Fi-aanbieders lid van NLIP

http://www.planet.nl/planet/show/id=118880/contentid=422720/sc=f8cf57

6. [SeattleWireless1] Seattle Wireless - Netgear WG602

http://www.seattlewireless.net/index.cgi/NetgearWG602

7. [SeattleWireless2] Seattle Wireless - Linksys WRT54G

http://www.seattlewireless.net/index.cgi/LinksysWrt54g

8. [Netgear1] Netgear - GPL Open Source Code for Programmers

http://kbserver.netgear.com/kb_web_files/n101238.asp

9. [Linksys1] Linksys - GPL code center

http://www.linksys.com/support/gpl.asp

10. [Soekris1] Soekris Engineering - About

http://www.soekris.com/about.htm

11. [Tweakers1] Tweakers.net - Pricewatch WLAN access points

http://www.tweakers.net/pricewatch/cat/314

12. [Soekris2] Soekris - How to buy

http://www.soekris.com/how_to_buy.htm

13. [Soekris3] Soekris Engineering - Bundles

http://www.soekris.com/bundles.htm

14. [Netgate1] Netgate - Wireless Mini PCI Cards

http://www.netgate.com/index.php?cPath=26_34

15. [KernelOrg1] Kernel.ORG - What is Linux?

http://www.kernel.org/

16. [FreebsdOrg1] FreeBSD.ORG - What is FreeBSD?

http://www.freebsd.org/

17. [SeattleWireless3] Seattle Wireless

http://www.seattlewireless.net/

18. [WirelessLeiden1] Stichting Wireless Leiden

http://www.wirelessleiden.nl/

19. [Tweakers2] Tweakers.net - Nieuws [ XS4All begint rechtszaak tegen Staat om aftapkosten ]

103

http://www.tweakers.net/nieuws/36491

104

Appendix B. Used acronyms

• AAA: Authentication, Authorization and Accounting

• ACE: Adaptive Communication Environment

• ACK: Acknowledgment

• ADSL: Asynchronous Digital Subscriber Line

• AES: Advanced Encryption Standard

• AH: Authentication Header

• AMPS: Advanced Mobile Phone System

• ASN.1: Abstract Syntax Notation One

• ASP: Application Service Provider

• BER: Basic Encoding Rules

• BSD: Berkeley Software Design

• BSS: Basic Service Set

• CBC-CTR: Cipher Block Chaining Counter Mode

• CBC: Cipher Block Chaining

• CCM(P): Cipher block chaining Counter Mode Protocol

• CDMA: Code Division Multiple Access

• CER: Canonical Encoding Rules

• CERT: Computer Emergency Response Team

• CHAP: Challenge Handshake Authentication Protocol

• CIPE: Crypto IP Encapsulation

• CPU: Central Processing Unit

• CRC: Cyclic Redundancy Check

• CSLIP: Compressed Serial Line Internet Protocol

• CVS: Concurrent Versions System

• DBM: Database Manager

• DER: Distinguished Encoding Rules

105

• DES: Data Encryption Standard

• DHCP: Dynamic Host Configuration Protocol

• DMZ: Demilitarized Zone

• DNAT: Destination Network Address Translation

• DNS: Domain Name System

• EAP: Extensible Authentication Protocol

• EDGE: Enhanced Data rates for GSM Evolution

• ESP: Encapsulating Security Payload

• ESS: Extended Service Set

• ETACS: Extended TACS

• FTP: File Transfer Protocol

• GBIA: Global Broadband Internet Access

• GIF: Graphics Interchange Format

• GNU: GNU's Not Unix

• GPL: GNU General Public License

• GPRS: General Packet Radio Service

• GRE: Generic Routing Encapsulation

• GSM: originally Group Speciale Mobile, now Global System for Mobile communications

• GUI: Graphical User Interface

• HAM: The meaning of this acronym is not known, but it relates to amateur radio. See [Vigyan1]for more information.

• HMAC: Hashed Message Authentication Code

• HTML: Hypertext Modeling Language

• HTTP: Hypertext Transfer Protocol

• IBSS: Independent Basic Service Set

• ICE: Inter City Express

• ICMP: Internet Control Message Protocol

• ICT: Information and Communication Technology

• IEEE: Institute of Electrical and Electronics Engineers

106

• IETF: Internet Engineering Task Force

• IPSEC: IP Security

• ISDN: Integrated Services Digital Network

• ISO: International Organization for Standardization, the name ISO is actually the Greek wordiso which means equal.

• ISP: Internet Service Provider

• ITU: International Telecommunications Union

• KCK: Key Confirmation Key

• KEK: Key Encryption Key

• KPN: Koninklijke PTT Nederland

• L2F: Layer 2 Forwarding

• L2TP: Layer 2 Tunneling Protocol

• LAN: Local Area Network

• LDAP: Lightweight Directory Access Protocol

• LEAP: Lightweight Extensible Authentication Protocol

• MAC: Message Authentication Code (in the field of cryptography) or Medium Access Control(in the field of networking)

• MAP:Master Access Point

• MD5:Message Digest version 5

• MIB:Management Information Base

• MIC:Message Integrity Check

• MIMO:Multiple-In Multiple-Out

• MMS:Multimedia Messaging Service

• MNO:Mobile Network Operator

• MPPE:Microsoft Point-to-Point Encryption

• MRTG:Multi Router Traffic Grapher

• MSCHAP:Microsoft Challenge Handshake Authentication Protocol

• MULTICS:Multiplexed Information and Computing Service

• MVC:Model View Controller architecture

107

• N-AMPS: Narrow band AMPS

• NAS: Network Attached Storage

• NAT: Network Address Translation

• NLIP: Nederlandse Internet Providers

• NMT: Nordic Mobile Telephone system

• NOC: Network Operations Center

• OSI: Open System Interconnect

• OSS: Open Source Software

• P2P: Peer-to-Peer

• PAE: Port Access Entity

• PAM: Pluggable Authentication Modules

• PAP: PPP Authentication Protocol

• PCI: Peripheral Component Interconnect

• PCMCIA: Personal Computer Memory Card International Association

• PDA: Personal Digital Assistant

• PDF: Portable Document Format

• PDU: Protocol Data Unit

• PEAP: Protected Extensible Authentication Protocol

• PER: Packed Encoding Rules

• PHP4: PHP: Hypertext Preprocessor, version 4

• PHP: PHP: Hypertext Preprocessor

• PKI: Public Key Infrastructure

• PMK: Pairwise Master Key

• PNG: Portable Network Graphics

• POSIX: Portable Operating System Interface

• PPP: Point-to-Point Protocol

• PPTP: Point-to-Point Tunneling Protocol

• PTK: Pairwise Transient Key

• RADIUS: Remote Authentication Dial-In User Service

108

• RAD: Requirements Analysis Document

• RAM: Random Access Memory

• RC4: Rivest Cipher 4

• RFC: Request-For-Comments

• RRD: Round Robin Database (database that stores information without expanding over time, byoverwriting old information; ie for use with MRTG)

• RSA: Rivest, Shamir and Adleman

• RSN: Robust Secure Network

• SAD: Security Association Database

• SAP: Slave Access Point

• SHA1: Secure Hash Algorithm version 1

• SMS: Short Message Service

• SMTP: Simple Mail Transfer Protocol

• SNAT: Source Network Address Translation

• SNMP: Simple Network Management Protocol

• SOCKS5: Proxy protocol SOCK-et-S version 5

• SPI: Security Parameter Index

• SQL: Structured Query Language

• SSH: Secure Shell

• SSID: Service Set Identifier

• SSL: Secure Socket Layer

• TACACS+: Enhanced incompatible version of TACACS

• TACACS: Terminal Access Controller Access Control System

• TACS: Total Access Communications System

• TCP: Transmission Control Protocol

• TDMA: Time Division Multiple Access

• TGV: Train a Grande Vitesse, English: high speed train

• TKIP: Temporary Key Integrity Protocol

• TK: Temporal Key

109

• TLS: Transport Layer Security

• TSN: Transition Security Network

• TTL: Time-To-Live

• TTLS: Tunneled TLS

• UDP: User Datagram Protocol

• UML: Unified Modeling Language

• UMTS: Universal Mobile Telecommunications System

• UNIX: originally UNICS, meaning Uniplexed Information and Computing System, laterchanged to UNIX. It was a pun on an experimental operating system in the 60s called Multics.

• USB: Universal Serial Bus

• UTP: Unshielded Twisted Pair

• UWB: Ultra Wide Band

• VPN: Virtual Private Network

• WAN:Wide Area Network

• WAP:Wireless Application Protocol

• WBA:Wireless Broadband Alliance

• WBAN:Wireless Body Area Network

• WDS:Wireless Distribution System

• WEP:Wired Equivalent Privacy

• WISP:Wireless Internet Service Provider

• WLAN:Wireless Local Area Network

• WPA2: version 2 of WPA

• WPA:Wi-Fi Protected Access

• WPAN:Wireless Personal Area Network

• WWW:World Wide Web

• XER: XML Encoding Rules

• XML: eXtensible Modeling Language

• XSL: XML Stylesheet Language

110

Appendix C. Extra project informationC.1. Used tools

In here, the choice of development and documentation tools is discussed. One general choice (a bitas a proof of concept) was to only use Open Source tools in order to complete the project (with theexception of the Windows XP OS). One of the most important choices in software tools was the de-velopment environment to use. While most development environments (Netbeans, Dev C++, etc)aim at a specific use or need, it was a desire to use one which can be used for multiple purposes.Having earlier experience with the Eclipse platform made the decision quite easy. While eclipse wasstill in development, by the time the thesis project started it was already quite matured. Eclipsewould fit to be used as a programmer's editor for various languages (a diversity of languages couldbe needed for this project). But it would also suffice as a general text editor and XML editor. Espe-cially this last fact (fitness for XML editing) introduced an interesting possibility, that is, the use ofDocBook XML and XSL for writing project documentation. The use of DocBook introduced somevery interesting advantages. Having had some negative experiences with Microsoft Word, such ascorrupt documents at the end of a project, only strengthened this choice. The fact the report is writ-ten in XML means it is always readable, and much more recoverable in case of problems, as op-posed to some binary proprietary format. The choice for DocBook meant some external tools wouldbe needed in order to be able to generate the documentation. Here it was decided to use java-basedsoftware (Xalan for parsing the XML, Saxon for transforming into XSL-Formatting Objects, and fi-nally Apache FOP for transforming the XSL-FO into PDF), such that platform independence is met(just like with Eclipse, which is also written in java) and use of the Windows OS is not dictated.

Besides documentation tools, design tools needed to be chosen. Platform independence was again animportant factor. ArgoUML was chosen due to earlier experiences with this tool. One problem washowever introduced by this choice (as seemed later on): sequence diagrams weren't implementedyet. The solution was to use another java program called Sequence, which can translate textual de-scriptions of sequence diagrams into graphics in batch. Creating a XSL translator file and DTD(Document Type Definition) file made it possible to define the sequence diagrams in XML, whichwould then be translated to the textual syntax of Sequence, which in turn would translate these de-scriptions into graphics. This means that most of the thesis project documentation is now based inXML and can be translated to other formats in batch, which in the end can be translated to PDF.This introduces homogeneity in the documentation process. As such this eases the documentationprocess, both in normal operation as in recovery from possible data corruption.

Development tools (outside Eclipse) needed to be chosen as well. One important choice was the useof a certain concurrent versioning system, such that the development of the project is versioned.Many solutions for versioning exist, while only some are well known. Previous experience with theCVS versioning directed the desire in this direction. However, CVS has some disadvantages whichmake it less interesting. One such disadvantage is the improper handling of binary files. This is isnot a huge problem, since everything in the project is text based. One other considerable problemhowever, is the inability to restructure the directories inside a project in the repository. A versioningsystem fixing these problems, and which is actually based on CVS, is Subversion. It was chosen touse this versioning system.

For the actual implementation, it was chosen to use the Debian Linux OS. Linux delivers by default

111

a very large set of development software, in the form of compilers, assemblers, debuggers, etc. Fur-ther, Linux (or any UNIX alike OS for that matter), is very rich in its ability for mass processing oftext files (i.e. bash, grep, awk, sed, perl, cut).

C.2. Needed preliminary knowledgeIt is assumed the reader has some basic knowledge of some networking and cryptographic concepts.A short overview of each of these concepts will be presented here.

C.2.1. Networking concepts

C.2.1.1. TCP/IP and OSI network stacks

Figure C.1. OSI reference model [Tanenbaum1996]

Each layer of the network stack performs its own function:

• 1. Physical: This is the layer that takes care of all physical data traffic.

112

• 2. Data link: This is the layer that makes the physical layer accessible for software. The data linklayer takes care of error detection and correction, takes care of identifying individual frames byfinding their boundaries in one way or another. Networks of data link layers (for example ether-net) contain hosts which can all contact each other directly. Hosts on such networks are ad-dressed by MAC (Medium Access Control) addresses.

• 3. Network: The network layer combines various layer 2 networks into one layer 3 network.Layer 3 networks are laid upon layer 2 networks, and multiple layer 3 networks are interconnec-ted using gateways and routers in order to create large layer 3 networks, such as the Internet.Hosts on such networks are identified by IP addresses (at least in the case of the TCP/IP stack).

• 4. Transport: The transport layer spans one or more layer 3 networks, in order to create host-to-host (end-to-end) connections (see the figure above to see the distinction between the layers 1to 3 on the one side, and layers 4 to 7 on the other side). In other words, the transport layer onlydeals with the source and destination machine of particular data traffic. Transport layer connec-tions are identified by a port or some other identifier.

• 5. Session: The session layer makes it possible for users on different machines to establish ses-sions. The session layer provides ordinary data transport in the same way the transport layerdoes, but adds extra services: dialogue control (half-duplex or full-duplex communication),token management (making sure the two sides don't attempt the same operation at the sametime) and synchronization (inserting checkpoints in the data stream in order to be able to resumethe data transfer after a crash).

• 6. Presentation: As stated by [Tanenbaum 1996]:

"The presentation layer is concerned with the syntax and semantics of the inform-ation transmitted."

The presentation layer is used to perform functions which resolve certain problems which arefaced by multiple users and which can be solved in a general way.

• 7. Application: In the application layer is contained a variety of protocols which are commonlyneeded by applications, for example HTTP for web servers and browsers, FTP for file transfersand SMTP for email.

Explained above is the OSI network stack. The TCP/IP stack was developed for the same goal,though by different means. The TCP/IP stack is the one used in the former ArpaNet and its suc-cessor, the Internet. The main distinctions between OSI and TCP/IP are the fact that TCP/IP doesn'tdefine the session and presentation layers, the network layer is called the Internet layer and the datalink layer and physical layer of the OSI stack are combined into one layer in the TCP/IP stack and iscalled host-to-network layer.

113

Figure C.2. TCP/IP and OSI network stacks [Tanenbaum1996]

For a more detailed explanation of these network stacks, refer to [Tanenbaum1996].

C.2.1.2. Some (popular) networking terms

• Spoofing:

"Impersonating a server or person without permission. Pretending to be someoneelse. The deliberate inducement of a user or a resource to take an incorrect action.Attempt to gain access to a system by pretending to be an authorized user. Imper-sonating, masquerading, and mimicking are forms of spoofing." [Imms1]

"Faking the origin; for example, forging mail headers to make it appear that mes-sages originated elsewhere. One spoof incident reported by CERT involved mes-sages sent to users, supposedly from local system administrators, requesting themto change their password to the new value provided in the message. These mes-sages were not from the administrators, but from intruders trying to steal ac-counts." [ITSecurity1]

"Web spoofing. Academics at Princeton university published a paper describinghow easy it is for Web spoofers to produce a 'fake' site that can sit between theuser and his or her intended destination. Thus spoofers could receive messagesand then pass them on to the true destination, and could receive replies and passthem back to the user. In this way it would be possible to 'filter' valuable informa-tion, possibly without the parties concerned ever knowing that it had occurred."[ITSecurity1]

114

A good example of web spoofing in the Netherlands occurred around the start of the 21st cen-tury, when the Rabobank online banking website was hacked and visitors of that site were redir-ected to an identically looking site, which let the users log in and forward (back and forth) datato the real banking website. This way, the hackers could retrieve many logins of the online bank-ing system in question, enabling them to withdraw money illegitimately.

• Sniffing:

"A program that monitors network traffic. Sniffers are used to capture data trans-mitted on a network. The act is called sniffing. Like so many security applications,sniffers can be used to either enhance or weaken network security. Intrusion De-tection Systems use sniffers to detect suspicious traffic; hackers use sniffers to ob-tain passwords." [ITSecurity2]

"The passive interception of data transmissions." [FFIEC1]

Sniffing originates on wired networks, where information belonging to a certain person anddestined for some other system is passed through intermediate systems in order to reach the des-tination. This fact introduces the possibility for users of such systems (whether legitimate or ille-gitimate, by hacking into the system) to intercept such traffic and have a look at it. Network con-nections which are not point-to-point, such as ethernets, also provide for sniffing traffic, since onsuch networks traffic destined for a certain host (for example the gateway to the Internet) getsreceived by all hosts, but normally only the destined host reads and acts on the information thatwas received. This wouldn't be the case if the network device gets put in promiscuous mode bythe user, which can only be done by the administrator of a system. In that case, the system inquestion reads all traffic on the ethernet, including traffic that wasn't destined for that system.

Now the problem gets worse on wireless LANs. While it is normally quite difficult to becomeadministrator on a system which is also connected to a certain wired network, it is much easierto put a privately owned system (i.e. a laptop) in the coverage area of an access point.

• Tunneling:

"A technology that enables one network to send its data via the connections of an-other network. Tunneling works by encapsulating a network protocol within pack-ets carried by the second network. For example, the PPTP technology from Mi-crosoft enables organizations to use the Internet to transmit data across a VPN. Itdoes this by embedding its own network protocol within the TCP/IP packets car-ried by the Internet." [Webopedia12]

• Encapsulation:

"Where data is inserted into a different kind of packet so the original packet is hid-den." [Stallion1]

C.2.2. Cryptographic conceptsSeveral cryptographic concepts will be mentioned below, including a short description. For a morein-depth explanation of these concepts, refer to [Lubbe1997].

115

C.2.2.1. Cryptographic aspects and methods

• Ciphertext: the text that results from encrypting a plaintext.

• Pseudo-random progression: progression of numbers (zeros and ones) of which the structure isas random and unpredictable as possible.

• Encryption: the process of transforming a plaintext into an encrypted form (called ciphertext),which can also be transformed back to its original form (the plaintext).

• Decryption: the process of transforming a ciphertext back to its original form.

• Block ciphering: encryption in blocks of a certain size, for example 64 bits in case of DES. Thisis usually used in case of already present data, for example local files which need to be encryp-ted.

• Stream ciphering: encryption in units, for example per character or per bit encryption. This isusually used in situations with streaming data, such as communications.

• Public key system (asymmetric system): an encryption system with two keys: a public key and aprivate key. Each user has both keys. The public one gets sent to other parties, who will use thatkey for encrypting traffic destined for the owner of the public key. The private key is keptprivate by the user, and is used for decryption. Public key systems are based on two importantaspects: one-way functions and trapdoor functions. One-way functions are functions which areeasily calculated, while their inverse isn't at all. Trapdoor functions are actually one-way func-tions (encryption), except in this case there is additional information that makes it possible tocompute the inverse of the function (decryption), the secrecy of that information is what makesthis system secure. Public key algorithms are usually very slow in their calculations.

• Public key infrastructure:

"A public key infrastructure provides an electronic framework - i.e. software and aset of rules and practices - for secure communication and transactions between or-ganizations and individuals. A PKI is based on asymmetric encryption and digitalsignature technologies. It enables two parties to exchange confidential electronicmessages and to enter into legally binding agreements over the Internet."[Cryptomathic1]

• Shared key system (symmetric system): an encryption system with one key, the shared secretkey. This key is shared by everyone who wants to join in the communication. Shared key sys-tems usually have very fast algorithms, but are also more insecure, since the probability of leak-ing of the key is quite large.

• Key stream: A key stream is a pseudo-random progression. It is generated by a function, with asinput parameters a secret key and sometimes also some extra component such as an initializationvector. The function initializes itself on the basis of the secret key and the initialization vector,and from then on generates (as long as needed) a pseudo-random progression which is to be usedfor the encryption of data. Usually, for additional encryption sessions, the initialization vectorwill be changed linearly and then another key stream is generated.

116

• Key stream reuse: Generation (and use) of an already earlier generated key stream. For examplewhen certain hardware always uses the same secret key and after a reset of that hardware the ini-tialization vector is always reset to some default value, then some initialization vectors will oc-cur much more often than others, resulting in the same pseudo-random progressions being gen-erated over and over, and thus resulting in key stream reuse. This is a potential security threat,because if someone (a hacker) notices this, that person can collect all data that was encrypted us-ing the same key stream. From all that encrypted data he can try to find what the actual keystream was, and since encrypted data is only a combination (in one way or another) of plaintextdata and a certain key stream, he can deduce what the original plaintext was.

• Confidentiality: making sure that communications are confidential: only the intended audiencecan take part in the communication. Confidentiality is achieved through encryption.

• Reliability (integrity): making sure that transferred data arrives at the other end unmodified, usu-ally this is achieved using some form of cryptographic authentication.

• Continuity: making sure that systems can continue operating, communications can continue totake place, data can continue to be stored. Attacks that try to influence the continuity of a systemare usually called Denial-of-Service (DoS) attacks.

• Key management: a necessary means in order to keep cryptographic algorithms effective. Nomatter how secure an algorithm is, if the keys cannot be kept secure, the cryptographic algorithmisn't effective. Key management is an essential part of the entire security scheme. Both in sym-metric and asymmetric systems it is needed for several parties to have common keys in order tocommunicate. In the case of asymmetric systems, parties should have the public keys of all otherparties they want to communicate with. In the case of symmetric systems, parties should havethe secret key of the communication system they want to have access to. Making sure all in-volved parties have all the keys they need in order to be able to communicate is referred to askey management. Key management is composed of the following aspects:

• Key generation: the generation of keys to be used for cryptographic algorithms. The key hasto be as unpredictable as possible (refer to pseudo-random characteristics), and shouldn't becryptographically weak or semi-weak.

• Key storage, transport and meta keys: keys shouldn't be stored and transmitted in the clear.Both for storage and for transport separate keys should be used. Such keys that secure anoth-er key during storage or transport are called meta keys.

• Key change: one important aspect of cryptographic algorithms is the frequent change of keysthat are in use. When keys are changed often enough, attacks such as exhaustive keysearches are (almost) impossible.

• Key destruction: the destruction of keys when they are no longer in use. Two types of de-struction exist: passive and active. Passive destruction is basically letting the power dropfrom the memory chip, obviously this only works for volatile memory. Active destruction isperformed by overwriting the memory with other contents. In case of volatile memory, oneoverwrite pass is necessary. In the case of non-volatile memory (i.e. magnetic devices suchas hard disks), multiple overwrite passes are necessary. Depending on the importance of theencrypted information well known wipe algorithms, such as the DoD 5220-22.M method (7passes) or the Gutmann method (35 passes), can be applied to erase the information.

117

• Key distribution using asymmetric systems: keys used in asymmetric algorithms are distrib-uted using a trusted third party in order to ensure the authenticity of the keys.

• Key distribution using symmetric systems: keys used in symmetric algorithms are initiallydistributed physically, this means that keys are entered into a system by a person. Any sub-sequent keys are distributed using either the previous key, or using a key distribution center.In the latter solution, every user has a key which he only shares with the key distributioncenter, and which will be used to receive new keys from the key distribution center.

• Challenge-response mechanism:

"A challenge-response test is a test involving a set of questions (or "challenges"),that the person or other entity has to answer in order to pass the test. If the personor entity provides an adequate response to the challenges, then it is deemed thatthis person or entity has passed the test." [Wikipedia7]

"In computer security, challenge-response authentication relies on the possessionof a secret of some sort to perform authentication. A very simple example is ask-ing for a password, where the challenge is asking for the password, and the ad-equate response is the correct password. This was adequate in the days before theInternet, when the user could be sure that the system asking for the password wasreally the system they were trying to access, and that nobody was likely to beeavesdropping on the communication channel to observe the password beingentered. These days, a more sophisticated approach is necessary involving two-way authentication, where both the user and the system must each convince theother that they know the shared secret (the password), without this secret ever be-ing transmitted in the clear over the communication channel, where eavesdroppersmight be lurking. The way this is done involves using the password as the encryp-tion key to transmit some randomly-generated information as the challenge,whereupon the other end must return as its response a similarly-encrypted valuewhich is some predetermined function of the originally-offered information, thusproving that it was able to decrypt the challenge. For instance, in Kerberos, thechallenge is an encrypted integer N, while the response is the encrypted integer N+ 1, proving that the other end was able to decrypt the integer N." [Wikipedia8]

• Cryptographic protocol: a set of prescriptions that should be followed by parties that want to ex-change information in a secure way.

• Hash functions: a one-way function of which it is impossible to compute the inverse. A set of in-put values of variable length is reflected onto a set of output values of fixed length. A desiredcharacteristic of hash functions is that such a function should be collision free, meaning that itshould be (near to) impossible to create two messages which transform into the same hash.

• Authentication:

• Message integrity: deals with the fact that messages shouldn't be changed during transit.This means that methods are needed to be able to detect if messages have changed duringtransit.

118

• Entity authentication: deals with ensuring that the other party is who he says he is. (ensuringno man-in-the-middle attacks have taken place)

• Message authentication: basically the combination of message integrity and entity authentic-ation.

• MAC (Message Authentication Code): implementation of message authentication using asecret function instead of a public function like in the case of hash functions, for example theuse of symmetric algorithms, i.e. DES, in the form of a one-way function.

• Digital signature: digital proof that someone did perform a certain action, such as sending acertain message. This is achieved using public key systems, by having the sender of a mes-sage encrypting the message with his own private key (perhaps in addition to encrypting itwith the public key of the other party). The receiver will then decrypt the ciphertext with thepublic key of the sender. Since the sender is the only one in possession of the private keyused for the digital signature, he must be the one who sent the message.

• X.509:

"Public key certificate standard developed as part of the X.500 directory specifica-tion. The X.500 directory specification is a standard for the development of a mul-tipurpose directory service that can be part of a global directory available to any-one in the world with Internet access. Such a directory is sometimes called a glob-al White Pages directory. The X.500 standard was defined by the InternationalTelecommunications Union (ITU), and the International Organization for Stand-ardization and International Electro-Chemical Commission (ISO/IEC). The X.509standard is used for secure management and distribution of digitally signed certi-ficates across secure Internet networks." [Cryptomathic1]

C.2.2.2. Crypto analytic attacks and other attacks

• Exhaustive key search: in this attack all possible combinations of ones and zeros as cryptograph-ic keys are tried, until the right one is found. Usually this is quite difficult for two reasons: thenumber of possible keys is large (usually too large if keys are changed often) and the text that issearched for might not be recognized (while perhaps the right key was generated using this at-tack). This is not a real crypto analytic attack, since no intelligent searching is applied, such asanalysis of the structure of the message or statistics of characteristics of the message.

• Ciphertext-only attack: attack using intelligent search tactics to find the message and/or the keywhere only the ciphertext is available.

• Known plaintext attack: attack using intelligent search tactics to find the message and/or the keywhere a sniffed plaintext and ciphertext are available.

• Chosen plaintext attack: attack using intelligent search tactics to find the message and/or the keywhere a chosen plaintext and corresponding ciphertext are available.

• Birthday attack and birthday paradox: the birthday attack is an attack in which someone

119

searches for messages M and M' for which holds that h(M') = h(M), where h is the hash functionin use. The attack is based on the birthday paradox, the paradox that in a group of for example23 people, the chance of finding two people that have a birthday on the same is larger than 50%.

• Man-in-the-middle attack: attack in which a third (invisible) person intercepts traffic betweentwo parties, changes the information and retransmits it to the right party, without the two otherparties knowing.

120

Appendix D. Project supportingdocumentationD.1. Globalplan for Mobidot thesis project

2005

The thesis project consists of 32 weeks * 40 hours. This amounts to a total time of 1280 hours to bespent for the thesis project, Working times will be: 08:30 - 12:30, 13:00 - 17:00, 18:00 - 22:00(monday to friday). From 01-01-2005 till 31-05-2005 and 05-09-2005 till 31-12-2005, monday-,tuesday- and wednesday afternoon and monday and tuesday evening will be occupied by anotherjob.

Projects

• Thesis [Start date: 04-04-2005, Deadline: 31-10-2005]

• Reports:

• Implementation of a WIFI service provider independent hotspot network [Deadline:31-10-2005]

• Phases:

• Project initialization [Deadline: 10-04-2005]

• Analysis [Deadline: 08-05-2005]

• Design [Deadline: 12-06-2005]

• Implementation [Deadline: 28-08-2005]

• Evaluation [Deadline: 25-09-2005]

• Project finalization [Deadline: 16-10-2005]

• Tasks:

• Presentation [Date: 10-2005]

• Periods:

• 04-04-2005 - 01-05-2005 (4 weeks), 40 hrs/week

• 02-05-2005 - 08-05-2005 (1 week), 60 hrs/week

• 09-05-2005 - 05-06-2005 (4 weeks), 40 hrs/week

• 06-06-2005 - 10-07-2005 (5 weeks), 60 hrs/week

121

• 11-07-2005 - 24-07-2005 (2 weeks), 0 hrs/week

• 25-07-2005 - 04-09-2005 (6 weeks), 60 hrs/week

• 05-09-2005 - 16-10-2005 (6 weeks), 40 hrs/week

D.2. Risk analysis for Mobidot thesis project

Hazard Likelihood Impact Risk exposure Risk reductionapproach

R1 Unavailabilityof resources

7 7 49 Likelihood re-duction

R2 Unavailabilityof key clientpersonnel(Joost,Michele)

3 5 15 Hazard preven-tion

R3 Technicalproblems

2 10 20 Contingencyplanning

R4 Losing projectcontents andfiles

5 10 50 Contingencyplanning

R5 Sickness af-fecting criticalpath activities

5 7 35 Likelihood re-duction, Con-tingency plan-ning

R6 Sickness af-fecting non-critical activit-ies


R7 Changes to re-quirementsspecificationduring laterphases of theproject


R8 Requirementsspecificationtakes longerthan expected

3 3 9 Risk avoidance

R9 Implementa-tion takes


122

Hazard Likelihood Impact Risk exposure Risk reductionapproach

longer than ex-pected

R10 Implementa-tion testingdemonstrateserrors or defi-ciencies indesign


R11 Design takeslonger than ex-pected


• R1: Make sure all resources are available beforehand. (get all books, etc before they are needed)

• R2: Early scheduling of meetings

• R3: Making available backup systems on which can be worked. The target hardware of theproject itself is low cost and can be bought whenever needed (funds are available)

• R4: Multiple backup strategies

• R5: Living healthy, getting enough sleep, using the weekends as time off to do something else

• R6: Living healthy, getting enough sleep, using the weekends as time off to do something else

• R7: Incremental prototyping

• R8: Plan enough or extra time for this phase or part


• R10: Take enough time for the design, and review it carefully


Critical path activities:

• round up of requirements analysis before design

• round up of thesis project before deadline

Non critical activities:

• Transition from design to implementation

• Transition from implementation to testing

123

design hotspot with opensource tools

Technology

project description

current system

proposed system

project goal

project approach

scientific relevance

social relevance

history of wifi