Vernier Testing


WRITTEN: 12 March 2001
UPDATED: 10 July 2001

For those interested in our experiences with Vernier Networks' access control technology.

Background

The Networks & Distributed Computing division of UW's office of Computing & Communications has been working with Packet Design LLC and their new spinoff Vernier Networks to evaluate a new technology for network access control, and in the context of 802.11b wireless Ethernet, topology-independent roaming.

Roaming vs. Good Network Design

One of the key problems of 802.11b native roaming is that it is a layer 2 capability that operates at cross-purposes with good network design principles. Because 802.11b devices can normally only roam between access points connected to a single IP subnet, and because good network design practice calls for avoiding large flat networks (due to performance and fault-isolation considerations), there is a conflict between current wireless Ethernet products and modern network topologies.

Vernier Networks' technology offers a solution to the topology constraints by implementing a form of IP mobility that allows roaming across subnets (while not requiring any changes to the client machines.)

UW's current wireless deployment plans call for connecting wireless access points to a single subnet within a building, but to not support roaming between buildings. Nevertheless, we are very interested in exploring the Vernier capabilities and the greater freedom it offers. Our preliminary tests have been encouraging.

Network Access Control

This is a complex topic, and opinions vary widely on whether network-level access control is a good or bad thing, and if it is desirable, how best to implement it. The conversation is more animated now that wireless Ethernet is being deployed. Some sites plan to do per-user authentication, some per-device (MAC address) auth, and others none at all. Motivations for network-level access control include: Perhaps more important than any of these is the need to be able to shut off a device that is found to be causing trouble, either accidentally or maliciously.

At UW, we do not consider the first two items to be sufficiently compelling to offset the operational pain associated with any form of network login and its associated accounting; however, traceability is unarguably a desirable goal (though perhaps the illusion of traceabilty might suffice in many cases :) and being able to shut down a misbehaving device is considered essential. In the wired world, this is usually done by disabling a port on an edge switch. In the wireless world, the analogous approach of disabling the edge switch port to which a wireless access point was connected would not be used except in extreme cases because many users could be sharing that access point, and therefore a single Ethernet port. Accordingly, a more sophisticated blocking approach is needed for wireless devices; one which will still work if the errant station moves from one wireless zone to another.

Complicating the decision on what to do about network-level auth is the observation that if you do it for wireless, you really ought to do it for wired connections as well, which leads to some serious and unwelcome behavior modification of end-users. (There are theoretically some single-sign-on opportunities here, but unless everyone is operating in a single administrative domain for all services, this can backfire and become a nightmare... as one colleague at another university discovered after installing a major vendor's wirless auth software which co-opted the MS window's login function and found that, depending on password he supplied, he could either use the Internet or he could print, but not both.)

Further complicating it is the current state of products. The 802.11 wireless industry currently offers proprietary authentication and authorization schemes, and the promise of one day soon supporting an interoperable 802.11e specification, which (among other things) adapts the 802.1x Extended Authentication Protocol Over LAN (EAPOL) standard for wireless. But the interoperable versions are not here yet.

Moreover, opinions vary on how well the 802.11e / 802.1x standards will meet enterprise needs, since they are essentially a layer 2 solution that by intention is unable to leverage layer 3 network capabilities. For example, maintaining an authenticated wireless connection while roaming amongst access points on different subnets could be a problem. In the past, layer 2 Ethernet solutions have often replicated and often conflicted with layer 3 IP solutions (VLANs, QoS, flow control, etc...)

Although UW has not yet decided on a network auth policy, we are very intrigued by Vernier's capabilities. It offers fine-grain access control based on user identity or device identity. And it can leverage our existing layer 3 auth infrastructure by accessing central services via IP.

Current Status and Next Steps

Our preliminary experience has been positive. As new feature sets have been released, our tests indicate the devices work as advertised. Soon we expect to have a version that supports RADIUS authentication, at which point we will be able to tie the Vernier devices into our campus-wide authentication infrastructure via a RADIUS-Kerberos gateway.

The place these devices may fit into our infrastructure most immediately is in support of our wired drop-in labs, as a replacement for the aging Cisco lock'n'key technology we currently use. The fact that the Vernier device handles user auth via a web browser, rather than requiring the user to telnet to a router, is a significant improvement. Although users must be instructed to use the web first, in order to trigger the auth process, this is no worse than our current situation where they must be instructed to telnet to the router.

Regarding support from the vendor, it has been excellent to date.

UPDATE: We are now using the Vernier device within our own IT staff building with the following policy: access *within* the University does not require authentication; access to the "outside" Internet *does* require authentication.

This policy has two important characteristics:

  1. It avoids UW becoming notorious as the "place to go" for open access to the Internet via 802.11, and it avoids the embarrassment of some "drive by" hacker attacking a high profile site via out wireless network.
  2. It minimizes the hassle for people who just want to access local UW resources.

This policy does nothing to protect internal UW systems from "drive by" attackers, but we get zillions of attacks from all over the world every day, so the additional threat is small. Moreover, we discovered that for local Windows login to work, a significant number of "holes" would need to be punched thru the vernier access controls anyway, so this approach seems to be a useful compromise.

The RADIUS authentication is working fine via a RADIUS-Kerberos gateway we deployed for the purpose. However, we are discussing with Vernier the feasibility of integrating our own Web Authentication Service into their web authentication page in order to give our users a consistent look-and-feel for the authentication.

We still plan on using a single conventional subnet for all the wireless access points within a building. If we were to deploy Vernier access control boxes throughout the wireless infrastructure, that would mean we would need one per building, which seems reasonable. Layer 3 roaming between buildings remains a low priority for us, but we will revisit the question as we gain more experience with our wireless roll out.

TEG HOME