Skip to content Skip to navigation


Accessible, Accountable, Affordable, and Scalable Wireless Network
by Peter Chen and Hanz Makmur
Laboratory for Computer Science Research
Division of Computer and Information Sciences - Rutgers The State University of New Jersey
Copyrights 2001: Rutgers University, Laboratory for Computer Science Research

Nov 1 2001

Last Modified March 1, 2002

I. Abstract

AAAS WiN (pronounced "ace win") stands for "Accessible, Accountable, Affordable, and Scalable Wireless Network." It's a design to provide ubiquitous wireless network access. The first such implementation is LAWN (Local Area Wireless Network), which has been in service at Rutgers University since August 2001. This document explains AAAS WiN's objectives, conception, and architecture. It also includes a brief description of its first implementation.

II. Introduction

The advent of 802.11b based wireless network technology has propelled the definition of accessiblity to a new plane. Since Apple first introduced iBook, the first notebook with built-in wireless networking in 1999, various vendors has released competing products that brings lower prices and more choices to the consumers. It seems that 802.11b is now poised to bring ubiquitous access to the masses.

Unfortunately, large scale wide spread deployments are hampered by the limitations of these consumer oriented devices, such as the access points. An access point is the interface between wireless devices and the wired network. The first access point was Airport Base Station, introduced along with iBook. Targeted at homes and small offices, these access points carry an affordable price tag of $100-$300. However, this also means that they have limited features, and many deficiencies for large scale deployment.

For example, to account for each wireless client, individual hardware addresses must be registered with each access point. It also lacks facilities for centralized authentication. The alternative is more function-rich but also much pricier access points.

These limitations seem to doom their wide spread usage in more budget conscious organizations ... until now.

At LCSR, a research arm of Division of Computer and Information Sciences at Rutgers, a group of developers stepped up to meet this challenge with an innovative design, AAAS WiN (Accessible, Accountable, Affordable, and Scalable Wireless Network). LAWN (Local Area Wireless Network) is the first implementaiton. LAWN was assembled in spring 2001, put in beta test that summer, and released to the public in August. The system has been operating flawlessly since.

The purpose of this document is to elaborate on the objectives, conception, and architecture of AAAS WiN. Its first implementation, LAWN, is detailed in a separete document. It's the author's hope that AAAS WiN will be widely adopted and bring ubiquitous wireless network access to the masses.

III. Objectives

The primary objectives of AAAS WiN are accessibility, accountability, affordability, and scalability.

III.A. Accessibility

Accesbility means ease of use. To achieve ubiquity, AAAS must be easy to use. For example the authentication process which grants users access should be straight forward and error proof. It should also provide mobility. When a user moves from one access point to the next, he should not constantly be required to relogin again.

III.B. Accountability

Accountability means that every access to the nework is traceable to a user account. The ability to identify unauthorized accesses and possible security breaches is paramount for the security of any organization.

III.C. Affordability.

AAAS must be cost effective, in other words, "cheap." AAAS will be widely adopted only if it's affordable. This entails that the hardware and software required must be low cost and easily available. Preferably, off the shelf non-vendor specific components can be used. This way individual organizations may bargain shop for the best prices.

III.D. Scalability

AAAS must be easily expandable. This means the incremental cost of supporting more users is relatively low. Ideally, AAAS should exhibit an economy of scale. As the user base grows, the per user operating cost should decrease. For example, to enable access in an additional building should not require a drastic upgrade in the current infrastructure.. On that note, AAAS needs to accomodate expansions into geographically diverse area. It is possible that as AAAS users roam from one access points to the next, they may in fact physically move across states or even continents.

IV. Design

At the top level, AAAS is a star configuration with worksgroups connecting to a central authentication server. The authentication server is located on the public network, while each workgroup contains its own private network. The link from a workgroup to the public network is controlled. Wireless clients connect to access points within a workgroup and must first login. The central authentication server examines the credential (for example, a pair of username and password) from a client in a workgroup and responds to the workgroup whether the client is to be granted access.

This is a deliberate separation between the access control mechanism and the authentication authority. In order to satisfy accessibility requirement, AAAS needs to appear as one system. This means that once the user is authenticated and granted access from one access point, he should retain his access as he roams to another access point. In general, the appearance as one system usually entails some degree of centralization.

On the other hand, for affordability, AAAS needs to be as light as possible in the center. If the centralized elements are overtly resource intensive, the startup cost for a minimal implimentation will be too high.

To satisfy these constraints, we distilled the centralized elements down to the bare essentials, the access control. We further recognized that access control actually consists of two components, the access control mechanism and an authentication server or a gatekeeper and a keymaster. The gatekeeper guards the door to the public network, and opens the door when a correct "key" is given. The keymaster holds all the keys. When a wireless client encounters a gatekeeper, he announces himself to the keymaster, and asks for a key. The keymaster examines the client's credentials, and grants him a key if the credentials are valid. In this scenario, it's clear that the "gatekeepers" do not need to be centralized, as long as the keys come from the same key master. In other words, only the authentication server needs to be centralized.

IV.A. Authentication Server

The authentication server is the center piece of AAAS. As previously described, it is the one and only centralized component. Its function is to verify a client's credentials and inform the workgroup whether the client is to be granted access.

While AAAS does not mandate the authentication mechanism (e.g., PAM, Kerberos, SMB, IMAP, POP3, RADIUS etc) or the communication protocol between the authentication server and a workgroup, we do recommend the implementations to be secure. If the authentication is not done locally on the authentication server, and an external source is used, the transmission of the credentials from the authentication to the external source should be secure. The transmission may be based on protocols that use SSL, such as HTTPS, SFTP, or IMAP+SSL, etc. Similarly, the communication between the keymaster (authentication server) and the gatekeepers should be secure, so it's not vulnerable to exploits such as man-in-the-middle attacks.

IV.B A Workgroup
A workgroup is a self-contained private network. This is where the action takes place. At its center is a switch or a hub where all the access points, wall outlets, the firewall, and IDS (Intrusion Detection System) are connected. One may think of a workgroup as a village, and the switch is the town square. The access points and wall outlets are roads leading to the town square. The firewall is the wall surrounding the village. The IDS is the big brother that watches the traffic.

IV.B.1 Firewall
The firewall shields the private network from the public network. This is where the magic occurs, where network access is controlled. In order for a client to connect to the public network, it will need to login, or to present its credential (usually a username and password pair) to the firewall and have it verified some how. At which point, the firewall will open access for that particular client.

This is a critical step both in terms of accessibility and accountability. If the login process is overtly cumbersome, it will inhibit accessibility. On the flip side, the access must be restricted to those who are authorized, and an audit trail is logged. It's possible to accomplish both goals seamlessly. Even though this is a design document, I shall outline a possible implementation to illustrate this point.

The action begins when a wireless client comes into range of a wireless access point. First, the wireless client must have be configured to use DHCP for its wireless network interface. The DHCP request is relayed through the wireless access point to the DHCP server which happens to run on the firewall host. The DHCP server responds with the IP address, netmask, gateway address, and DNS settings. The IP address is a private network address (,, or -based on RFC1918) The gateway and the DNS server are the firewall host. The wireless client configures its wireless network interface accordingly, and becomes part of the private network.

At this point, even though the wireless has become part of the private network, it still has not gained access to the public network. This requires a login. Since the gateway is the firewall host, all network traffic is routed there. The firewall rules are set up so that all access going outside of the workgroup are denied by default unless explicitly granted. The firewall rules also route all HTTP (port 80) traffic to the firewall's Apache HTTP server. This is where the login page is presented.

The user will then submit his/her credentials to be verified. The firewall host relays this credential securely to the authentication server on the public network. Upon a positive response, the firewall host then alters its firewall rule to allow this wireless clients to access the public network based on either its IP address or its MAC address. The firewall also performs network translation, so all wireless clients' private IP addresses are translated into the firewall host's public IP address.

This may not sound exciting. However, it's quite impressive in action. Prior to the login, as soon as a wireless user attempts to access any web site, he is immediately presented with the login page. The user does not need to remember any special URL for login. It's so intuitive that it requires almost no training on the user.

IV.B.2 Hub/Switch

The switch or the hub is the center piece of a workgroup that ties all other pieces together. On a tight budget, a hub will certain suffice. However, for security, a switch is preferred since network traffic will not be visible from one port to another. This cuts down on the potential of malicious clients sniffing network traffic.

To support an IDS, one needs to raise the bar even further. In this case, the switch will need to be configurable so that one port can be configured to see all traffics from other ports. This most likely entails a higher end switch. We shall detail this further in the IDS section.

IV.B.3. Access points

"Wireless Access points" are well named. Think of them as wireless equivalents of wall outlets. Wireless access points are the interface between wireless clients and the central switch.

Together, wireless access points and wall outlets are where clients plug into the network. And "all roads lead to Roam." They are all connected to the central switch. Contrary to their wired counter part, access points have the additional ability to handle multiple wireless clients simultaneously.


IDS (Intrusion Detection System) monitors for suspicious network traffic. These could entail break-in attempts, or attacks.

In order for the IDS to function, it must be connected to a port that sees all network traffic in the workgroup. A central hub may suffice. However, it's not the best choice. It will also allow clients in the workgroup to see each other's traffic. The better thing to do is to use a switch that can be configured on port by port basis. Some ports then can be configured to see traffics from others.

V. Validation

Before we reach a conclusion and begin to pat ourselves on the shoulder. Let's make sure that AAAS WiN has met all our requirements.

V.A. Accessibility

Is AAAS easy to access? Yes, it can be.

This of course is implementation dependent. AAAS itself does not specify how each clients becomes part of a workgroup. This is determined by individual workgroups. It is relatively easy to set up workgroups to be user friendly.

For example, as we previously described, the firewall host can also run DHCP, so the wireless client can automatically configured with the appropriate IP address, DNS servers, and gateway address. The gateway is set to the firewall and accepts all incoming traffic within the workgroup (but not going outside the workgroup). This gives a wireless client conductivity to the firewall host. As soon as any HTTP request is sent, it's forwarded by the firewall to the firewall host's Apache server, and the login then takes place.

The entire login process is intuitive and fool proof. Most users instinctively open up their web browsers as soon as they are connected to the workgroup.

V.B. Accountability

Accountability is accomplished by the firewall host. Once the client is authenticated, and public access through the firewall is granted, the firewall can log the network traffic. The log will contain the client's IP address in the private network. Combined the private IP address with the authentication log, we can trace every network access back to its user account. The level of details of logging can be tuned by the administrator as necessary.

V.C. Affordability

Is AAAS cheap? Yes, generally speaking the total cost of ownership is very low.

AAAS places minimal requirements on the hardware. It also requires relatively little administration. None of the access points, switches, firewalls, or IDS, or authentication servers are vendor specific. They can be bought right off the shelf from a wide range of vendors. Since all network facilities such as access control, dynamic host configuration, and name services are handled by the firewall, the access points need very few features. The only concerns will be the their reliabilities and cost.

The firewall host and the authentication server can be built from low cost hardware and software. A PC with Pentium II 300Mhz, 256M memory, and 10GB hard disk, installed with Linux (free) are more than enough. Such PC can cost as low as $200 each as of November 2001.

The administration required is concentrated on the firewall host in each workgroup, and the central authentication.

V.D. Scalability

AAAS has no inherent limits to its scalability. Each workgroup can have a large number of access points. In the simplest configuration with all access points directly connecting to a central switch, the limit is the number of ports available on the switch. One can easily extend this by cascading switches.

The authentication server can handle a large number of requests. If the workgroups are spread out geographically, and latency is an issue. One may even set up local authentication servers and trust relationships.

Both workgroups on the edge and authentication servers in the center may be scaled up rapidly.

VI. Conclusion

As show above, AAAS WiN is easy to use and cheap to build. One can log and audit all network access, and it can grow rapidly with no intrinsic limit. It satisfies our requirements for accessibility, accountability, affordability, and scalability.

VII .Future improvements

Expanding AAAS to other method of authentications is one part of the project that will always be on going. Additional authentication modules can always be added to the system anticipating newer technology.

Quality of Service (QoS) issue is one of the feature that will be added to throttle speed. Such QoS feature can be assigned to specific user or groups to make sure that no user can monopolise the bandwidth. QoS can also be used to prioritize bandwidth to specific users.

VIII. Acknowledgements

The concept AAAS WiN was borned after discussions amongst Dr. Badrinath, Dr. Donald Smith, Charles McGrew, Kenneth Harris Jr, Hanz Makmur and Peter Chen in October 2000. The result of this discussion is the implementation of DCIS/LCSR LAWN in May 2001.