« back to results for ""
Below is a cache of http://www.smartbridges.com/pdf/whitepaper.pdf. It's a snapshot of the page taken as our search engine crawled the Web.
The web site itself may have changed. You can check the current page or check for previous versions at the Internet Archive. Yahoo! is not affiliated with the authors of this page or responsible for its content.
Central control of Client Devices.





Central control of Client Devices.
A smartBridges White Paper.
February 2003

Abstract: The Media Access for the Wireless devices can
be controlled centrally - authorizing only a homogeneous set
of client devices known to the ISP. A central database of
such device's ID in form of a data store of MAC is suggested.
This can be linked with a standards based RADIUS server
for access control. The benefits of such an approach to the
operational aspects; such as the device provisioning &
device management and in general to new usage plans,
make it very lucrative for the WISP. This facility also gives a
fine-grained control over the Network and makes the
provisioning of the client devices simple, while being secure.

Keywords: Device Management, RADIUS/AAA service, RADIUS
Client, MAC Association, Location Based Services, Access
Control, Security, Device provisioning, ISP.
The case for Centralized Access Control

Most Access Points allow the 'associations' table to limit the client devices, which can
access the wireless media. This means that the WISP has to key-in the MACs of all
devices on each AP. This in theory is a good practice, as only a few client devices
can access that AP, but it leads to management nightmares such as

A dedicated effort is needed to track the MACs on all Access Points. The
options for such management of the MAC tables involve manual
configuration on each AP and then noting the values in a file or in a
database.

New MAC provisioning such as addition and deletion of users is tedious. At
best this is a meticulous manual configuration at each AP. At worst, this
evolves into a heinous spreadsheet based tracking system, with troublesome
data synchronization issues. Most WISP thus end up keeping all AP open.

The localized MAC tables could mean that more than one session can be
opened by a user, by possibly doing MAC spoofing, which sadly remains as
one of the hazards of the WISP operational environment.

It is impossible to use high-level business logic to make a case-to-case
access control, such as one linked to a usage-based package.

The MAC of the device needs to be configured on each of the APs for
allowing mobility between them.

To provide a flexible and more secure operation model, it becomes essential that the
device control is made central, and the intelligence on such decisions is taken away
from the Access Points. This can be achieved by the Central Access model, whereby
all the Access Points query a central RADIUS service to seek control permissions for
allowing the client devices onto the Network. This simple separation of control opens
up a multitude of opportunities for the WISP and gives him a hook into configuration and user management, while making the Network more secure.

How Does It Work?
The essential components of the centralized control system are a RADIUS Server,
the MAC Database and a RADIUS Compliant Access Point. As shown here:


RADIUS Compliant Access Point such as the airPoint Pro. This is the most crucial
element, as it is the capability to interface with an external system before the WLAN
association is allowed to happen that is important for a central control. It is also
possible to prevent a device from re-associating depending on the RADIUS settings.
The intelligence for disconnecting the user can be managed at the WISP end, through
any of the myriad billing systems.

RADIUS Server. This service is installed at any one place on the WISP infrastructure.
Optionally this can even be part of a business alliance with another operator, where
the service is sourced from a central operator. The examples of available RADIUS
servers are given later. The RADIUS server acts as an external authenticator in this
implementation, the location of the which is not important for the functional
parameters, as long as it is possible for the Access Point to get a result for the query within a reasonable time.

MAC database The MAC is used as the user Key, unique for each device in a
network, and thus the mapping to a user-ID for the billing system is possible. Any
other Token/Password would require user intervention or modifications on the user's
PC/router. The MAC, however, is part of the association request itself, and can be
used non-intrusively. The Access Points do not interact with this database directly, as
it is stored in a RADIUS compatible format, accessible only to the server.

Connection Example
When a user starts using the infrastructure, the client device needs to associate with
the Access Point. The flow of the connection is as follows:

As shown with the corresponding numbers in the above diagram

1.When any WLAN client device wants to use the network it is not automatically
authorized to access the network. The device tries to associate to the nearest or
the assigned AP.

2.The AP captures the MAC of the client device from the association query and uses that to determine the association state for the client. Since it is no longer a
localized database, it determines that it has to connect to the RADIUS server. The
parameters for the connection to the server are already configured along with the
known 'secret'.

3.The AP queries the RADIUS server with the MAC of the client device as the
'username' and 'password'. For this the AP encodes the traffic with the 'secret'.

4.The RADIUS server in-turn queries its MAC database, and determines the validity
for the client device.

5.If its a valid device as per the database, the RADIUS server returns an 'Allow' result
to the AP, which maintains a temporary internal state for such devices. If the
RADIUS server determines the device to be not bona fide, it return a Reject
result to the AP, which leads to an association failure for the device.

6.Subsequently, subject to the Accept result above, the AP allows the device with
that known MAC to Associate. The device now can use all the allowed Network
resources, and is on the Network for all practical purposes.

The RADIUS server is maintained at a central location, whereby more than one
Access Point can use it for client access validation, for example Access Points
I
and II
, which may or may not be in the same location.

One of the immediate benefits is that the client devices do not get automatic access
to the media or the network just because the user knows which AP to use.

The RADIUS server and the MAC database are extensible by virtue of the most
RADIUS implementations being modular. The database format can be changed to
suit the WISP's network. Also, it is not essential for the RADIUS server to be
managed by the WISP itself. It can be anywhere on the network, as long as the AP
can access it for queries without large network delays. A RADIUS server can also be
used to Proxy the requests to another one, independent of the settings on the Access
Points.
Application Benefits

The main benefits of controlling the device centrally are not limited to the following:

1) Easier client Device Provisioning. Since the legitimate devices are entered into
the central MAC database, the WISP does not need to make changes to multiple
Access Points. Both addition as well removal of devices can be controlled centrally.
This also means that the WISP can maintain a homogeneous database, which can
link with a customer management system capable of indicating multiple devices or
access licenses given to specific billing contact, such as a company.

2) Device Usage monitoring. Since the association request are visible in the RADIUS
service, its trivial to monitor the requests by specific clients for network access. This
also leads to interesting applications in Usage based billing as controls like Time-Of-
The-Day, Days-Of-The-Week etc can be supported on the network access.

3) Billing Integration. Most of the off the shelf billing systems link to the RADIUS
service, as the agent for data collection as well for implementing the usage plans.
The reports can be centrally obtained. Most Billing Systems impose basic log-out
periods on the basis of usage plans, for example if a user's billing information shows
that the maximum session should be just one hour, the real time agent of the billing
system updates this information in the RADIUS server which can then deny access to
the client after the lapse of the same time period.

4) Mobility between Access Points. If the WISP uses a localized MAC association
table based infrastructure, its paramount for access that when the user moves
between two Access Points, the MAC is locally allowed on both. This requires the
comprehensive MAC table updates all over. With the central database this ceases to
be of issue. The clients can painlessly move fro