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 (10.0.0.0/8,
192.168.0.0/12, or 172.16.0.0/16 -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.
IV.B.4. IDS
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.