by Dory Leifer, DEL Communications Consulting

Visitor networks are LANs that are most often deployed in hotels, airports, cafés, college campuses, apartments, and other locations. They enable the public network access on an ad-hoc basis. Recently, 802.11 “hot spots” have gained increased attention; they represent one example of a visitor network.

Visitors attach devices such as a laptop or personal digital assistant (PDA) that they use only while traveling or, more often, they attach machines normally used in the office or home. These machines can be thought of as “visiting hosts.”

This article explores some of the technical issues with IP visitor networks and considers practical options for service provider deployment on wired Ethernet and wireless networks. In exploring deployment options, the article focuses mainly on solutions that do not require client software on the visiting host. These clientless techniques are based on heuristics and, although they do not work effectively under all circumstances, they have proven to be quite useful in practice.

For this discussion, it is assumed that the service provided by the visitor network is for access in one location at a time. Therefore, the article does not address network hand-off for mobile clients that are moving from one network attachment point to another while attempting to maintain connectivity.

Traditional LANs vs. Visitor Networks
Traditional LANs have been well optimized for enterprise networks. They provide high bandwidth and an economical and universal method of delivering network connectivity. In comparison, visitor networks are a rather curious hybrid of a LAN and a public network, such as one used for dial-in network access. Their objective is to physically use LANs to deliver what has normally been considered a public network service: universal access.

In enterprise networks, traditional LANs are usually carefully administrated. Normally the connected hosts are owned and administrated by the same enterprise that operates the network. Hosts that are connected to the network are configured according to the designated protocol and address schemes. They are often configured for at least Simple Mail Transfer Protocol (SMTP), Post Office Protocol (POP), file, and print sharing. On visitor networks, the hosts are typically owned and configured by the visitors, while the service provider administrates the network.

This difference in administration creates a serious challenge for the visitor network. The network must support a wide range of configurations because they will differ from one visiting host to another. For example, if a host had previously been configured for a static IP address, that address is likely to be from a different subnet, perhaps from a private network that the visitor normally uses at the office. Even if a host gets some of its configuration from Dynamic Host Configuration Protocol (DHCP), Domain Name System (DNS) and SMTP servers may refer to addresses or names on a private network that are not reachable on the visitor network.

Traditional wired LANs normally span physically secure areas, so any person who has access to the Ethernet wall jack for the building can connect anything to the network. With a visitor network it may be undesirable to allow everyone access. For example, a visitor network deployed in a university library may be available only to students. Similar to public dial-in access, visitor networks often rely on authentication and authorization before granting service.

Whereas LANs are excellent at facilitating peer-to-peer services such as file and print sharing between connected hosts, visitor networks often attempt to minimize these direct interactions between visitors, instead establishing a set of services that the service provider itself offers or simply routing the IP packets off the LAN to an Internet Service Provider. Minimizing interactions between visitors is desirable because service providers will want to reduce the risk of a visitor’s machine being attacked by another visitor. On some occasions, however, visitors who do trust each other may want to use the visitor network for file sharing, printing, or even network gaming.

Going Clientless
One of the most difficult choices for service providers deploying visitor networks is to decide whether or not to rely on the installation of specialized client software on the visiting host.

Client software allows specific network protocols to be passed between the client and the visitor network. Protocols such as Point-to-Point Protocol over Ethernet (PPPoE) [1], Layer 2 Tunneling Protocol (L2TP) [2], and Mobile-IP [3] support both authentication as well as IP tunneling to assist in routing and address assignment. On some wireless LANs and networks with high-end Ethernet switches, 802.1x (which will be discussed in more detail later) supports flexible authentication schemes and aids in data encryption [4]. Although these protocols implemented on the client can present a significant technical advantage for implementing visitor networks, they require at least some modification to the configuration on the visiting host.

The lowest common denominator for traveling laptops is a simple TCP/IP stack and a browser. If the service can accommodate the visitor with only these items, the visitor network becomes much more suitable to the broadest audience. Of course without authentication, tunneling, and client configuration available from client software, the visitor network must rely on a set of heuristics or, said by some, hacks, to perform its tricks. Subsequent sections of this article illustrate technically how a visitor network can operate without relying on the installation of client software.

The service provider may choose to distribute client software in a situation where the visitor may use the service repeatedly. In many other situations, however, it is not feasible. For example, the last thing that travelers want to find in a hotel room upon arriving at midnight and needing a network connection is a CD-ROM full of new software drivers to drop on their laptop before using the hotel’s in-room Ethernet. Even if the provided software does nothing but change the configurations, such as select a Web proxy server, it may have negative consequences when the laptop is returned to the office. Such added steps could also discourage visitors from using the visitor network again.

Visitor Network Basics
There are no hard guidelines or standards on what constitutes a visitor network. However, numerous vendors are selling devices that operate with wired and wireless networks, and act as gateways between the visitor network and the traditionally routed infrastructure. The typical visitor experience proceeds as follows (this is essentially a clientless example): the visiting host would not require the installation of special software, and in many cases would not require configuration changes:

	The visiting host is physically attached to the network by connecting to a twisted-pair Ethernet port.
	Visitors open their browser and attempt to load any page with the Hypertext Transfer Protocol (HTTP).
	Regardless of the specified URL, the browser loads a default page that requests authentication or billing information.
	When authenticated, the visitors now have general Internet access.
	An accounting record describing a visitor’s session is generated and processed by the service provider’s billing system, resulting in a charge on either the visitor’s account or a corporate account.

Visitor Gateways
Visitor networks can be implemented with a special-purpose device called a “visitor gateway.” Figure 1 illustrates the basic functional schematic of an example device. (Unfortunately, just about every vendor selling these devices uses a different name. This article uses the term in a generic sense and not to refer to any company’s particular product.)

Figure 1: Visitor Gateway



The visitor gateway sits between the LANs used to provide service to the visitors and a standard routed interface. Physically, a visitor gateway is a device that appears much like a router or firewall, with minimally two Ethernet interfaces.

Hybrid of NAS and LAN
The following sections focus on the visitor gateway, specifically its operational model, its handling of various Internet packet types, virtual LANs (VLANs), authentication, and accounting.

Visitor gateways behave as a hybrid of a standard LAN and a Network Access Server (NAS). For illustration, one can compare the operation of the visitor gateway with the operation of a NAS. Like a NAS with individual modem ports, the visitor network gateway typically builds virtual port structures as new hosts are discovered on the connected LAN. These virtual interfaces are configured by the gateway to accommodate the IP addresses used and referred to by the visiting host. The visitor gateway may create a virtual port structure for every host based on its Media Access Control (MAC) address or VLAN identifier and treat every virtual interface as an independent subnet upon which the visiting host and the virtual interface of the visitor network are the only attachments. Think of the relationship as a logical point-to-point link.

Conversely, the NAS, using the Point-to-Point Protocol (PPP) [5] on a dial-in connection, has a significant advantage over the visitor gateway in this scenario. PPP allows the NAS to negotiate an acceptable IP address for the dial-in client, set the client’s default gateway, and even in some cases configure the client’s DNS. The NAS normally has at least Password Authentication Protocol (PAP) and Challenge Handshake Authentication Protocol (CHAP) for authentication. If the visiting host requests configuration through DHCP [6], the visitor network has an opportunity to assign private or public addresses that are mutually convenient for both parties. On the other hand, if the visiting host already has a static address configured for its native network, for example, then the visitor gateway must spoof or imitate the behavior of the configured subnet.

The appeal of PPP in the dial-in world led to the recent development of PPPoE for LANs. Although PPPoE has been used with service selection gateways to offer public Digital Subscriber Line (DSL), there has been little use of it on visitor gateways. This is likely to be true because of the lack of a ubiquitous client and the complexities of solving multilevel authentication and encryption involving the local link, local network, and private network. PPPoE certainly is worth future study for visitor networks.

ARP
Hosts learn Layer 2 MAC addresses using the Address Resolution Protocol (ARP). Although hosts and routers respond only when asked about the IP address of their interfaces or those on a proxy-ARP table, visitor gateways usually respond with their own MAC address to any ARP requests from the attached visiting hosts, effectively proxying for the host’s default gateway (if one is configured). The visitor gateway can also configure the interface address of its virtual port based on the host’s IP address. In this manner, the gateway auto-configures itself to accommodate the visitor, who can continue to use his/her configured address.

Used on a standard shared LAN, this technique only goes so far. If, for example, one host on the visitor network shared its default router configuration with the IP addresses of another host (not that uncommon for private network numbers), then when the first host attempted to get the MAC address of its default router, it would end up with two responses, one from the visitor gateway and one from the other host on the LAN.

TCP/UDP Port Redirector
The visitor gateway for each Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) packet received from the visiting host decides whether to pass the packet through or direct it to a local service such as DNS, SMTP, or Web server. It makes this decision based on some configured policy from the service provider (such as to redirect all SMTP) and from authorization states of the visitors. For example, if the service provider wishes to charge visitors $10 for daily access at a hotel, the port redirector could reflect HTTP requests to the local Web server that would, in turn, present the option to the visitor. Subsequent HTTP requests presumably would always be passed transparently through the gateway to the intended address.

The operation of the redirector is fairly simple. It works as a backwards network address-port translator. Instead of modifying the source, it modifies the destination and then applies standard IP forwarding on the resulting packets.

DNS
Visitor gateways typically implement proxies for domain name service requests and channel all DNS requests from the visiting host through the proxy. This serves at a minimum to reflect DNS requests to a closer DNS server, a useful performance advantage if the visitor’s configured DNS server is a considerable distance away. Of greater significance is that it allows general Internet access by the visitor even if the configured DNS server is on a private network, which is now unreachable because the visitor’s laptop has been moved from the office.

Redirecting to a DNS server not of the visitor’s choosing may work smoothly until the visitor attempts to resolve domain names known only to the real DNS server on the private network. There is, of course, a limit to how well you can hide reality.

One common problem encountered by visitor networks is with a Web proxy on a private network. If the visitor refers to a Web proxy by name, the visitor gateway may choose to respond, inventing an IP address for the proxy and then assuming, by itself, operation of the proxy function. This technique has to be used with some care because hosts often cache DNS responses; these are effectively convenient lies that could end up being carried as “dirty entries” on the visitor’s machine for longer than intended.

Rewriting DNS queries and responses does open the opportunity for the service provider to “assume” (some may say “hijack”) sites. This opens the door to the possibility that, for example, yahoo.com is resolved to an address that is not Yahoo but rather a Web site with an affiliation to the service provider. Although this is a policy and business issue for the service provider, it is likely to irritate quite a number of visitors and reduce the perceived value of the service.

NATs
Visitor network gateways frequently use Network Address Translation (NAT), and often with port translation, in order to conserve IP addresses by sharing a small address pool with a large number of visitor hosts. In addition, NAT is required by the gateway if the source address used by the visiting host is not routable by the rest of the network back to the visitor gateway. This is almost always the case when the visiting host is using a static preconfigured IP address from another network. The gateway may choose its application of NAT based on policy. For example, two visitors may be configured for DHCP but one is assigned a private “Net 10” (RFC 1918) address that is passed through a NAT while another is assigned a routable address. In practice this flexibility is useful for service in apartments where the visitors are expected to “visit” for months. The service provider may choose to offer tiered services, one with a routable address suitable for the customers to run servers, and another with a private address suitable only for outgoing connections (e-mail, HTTP, and so on).

VLANs
The visitor gateway—modeling its relationship with visiting hosts as a virtual point-to-point link—may attempt to ignore the fact that hosts are on a shared network. However, certain interactions between hosts are inevitable on a shared LAN. For example, if a visitor’s Windows laptop is configured for file sharing with no security enabled, other visitors may see, or worse, have permission to write to, critical files.

Virtual LANs provide a solution for isolating individual clients. On a wired Ethernet, many modern Ethernet switches can be configured to implicitly treat each port as a member of a different VLAN. For example, port 1 could be on VLAN 11; port 2 on VLAN 12; and so on. The visitor gateway is connected to one or more “trunk” ports that are configured as a member of all VLANs. This effectively allows another level of addressing so the visitor gateway can individually address a single Ethernet network connected to a port. The VLAN switches then act as simple concentrators. If a visiting host attempts to broadcast or multicast, these frames end up only traveling to the gateway and are not seen by other visiting hosts.

Figure 2: VLAN Frame Format



The VLAN frame format is shown in Figure 2. IEEE 802.1q defines the “tagging” [8]. The VLAN-enabled Ethernet switch can add the appropriate headers to standard Ethernet frames, and it forwards these through the trunk port. Optionally, another Ethernet switch concentrates the trunk traffic and attaches to the visitor gateway, as seen in Figure 3. One potential catch is that some Ethernet switches will not pass the oversized (maximum 1504 octet) VLAN frames; others attempt to be “overly aware” of the VLAN membership rules and insist on configuration of each of the VLANs, a challenging prospect if you are concentrating thousands of ports, each with a unique VLAN identifier.

Figure 3: VLAN Configuration



Some Ethernet switch vendors have implemented a nonstandard technique whereby broadcasts and multicasts are forwarded exclusively to a designated port, the theory being that if a host’s broadcast and multicast frames do not get forwarded to other hosts, the hosts effectively will not “see” each other because they do not see ARP requests or higherlayer service advertisements. In some ways, this is simpler than using VLANs and provides some isolation over standard Ethernet networks.

Figure 4: Switch Multicast Blocking



Combinations of these switches with normal ones can lead to some interesting frame forwarding scenarios. For example, as seen in Figure 4, Ethernet switches A and B are each connected to Ethernet switch C. Visiting hosts are attached to the ports on A and B. A and B are designed to have the forwarding restriction described, but C is a normal switch. This means that a broadcast from a visitor connected to A will not be seen by other visitors on A (by nature of the restriction) but it will be forwarded “upstream” to C, which will then forward it to B. Because B received it coming from the upstream, it will forward it to all the visiting hosts on B, causing the isolation technique to fail. A, B, and C all need to have the forwarding restriction.

Web-Based Authentication and Policy
Visitor networks often avail themselves of the one reliable way to converse with a human without additional client software: the Web browser. By selectively reflecting HTTP requests to the local gateway, the gateway can perform or facilitate several operations:

	Authenticate users with traditional username/password—The visitor gateway may, in turn, use a Remote Access Dial-In User Service (RADIUS) [7] authentication request to validate the user.
	Provide links within a “walled garden”—sites that can be visited without authentication—These sites are implemented with either a Web proxy inside the gateway or access control lists effective on the individual visiting host’s virtual interface.
	Gather and validate credit card information through third-party credit card processing Web sites
	Offer visitors Web pages they can use to subscribe to services or to change service parameters

Using the browser can have a significant advantage, even over installed client software. The browser allows a conversation with a human user instead of a software client. This affords the network provider a wide variety of options, such as dealing politely with an authentication rejection, providing additional troubleshooting help, or confirming “conditions of use” before the user accepts charges. It is also a place for offering the user other products and services through Web links.

A central repository for visitor policy and configuration is especially important when a large number of gateways are deployed in disparate physical locations. An interesting option for visitor gateways is for them to learn policy by participating in the exchange of HTTP between the visiting host and an external Web server. The visitor gateway can piggyback the origin and state of a visiting host in a URL and refer the visitor’s browser to a Web site. This origin information when presented to a service selection application running in a provider’s data or operation center allows the application to determine which gateway the visitor is attached to as well as the visitor’s virtual port identification and MAC address.

With the origin information, the service selection gateway can present the visitor with any number of billing, quality of service, or IP addressing options that apply to his/her connection. When the service selection application needs to affect the policy information stored in the visitor gateway, it can use a similar piggyback technique in the return direction.

Accounting
Finding an easy-to-deploy accounting method is crucial for service providers to generate accurate billing. The visitor gateway may send RADIUS accounting records in response to connections and disconnections made by visiting hosts. Disconnections can be determined by Simple Network Management Protocol (SNMP) traps from the physical layer devices or by repeated interval polling of the visiting host using ARPs or pings. Because RADIUS has been widely deployed by service providers for dial-in or other networks, it is very possible that the existing accounting system would be able to support the visitor gateway if it, too, offers RADIUS.

In hotels, accounting information can be sent directly to the hotel’s Property Management System (PMS), causing users to see an access charge on their folio. This is normally accomplished by connecting a standard low-speed serial interface between the visitor gateway and the PMS. The visitor gateway posts the charges by exchanging records with the PMS. A simple record format is used to identify a room and associated charge. Although the format and exchange protocols are usually simple, they are rarely standard. Interfacing to a PMS may require the vendor of the visitor gateway to pay a license fee to the company selling the PMS before it can implement a PMS protocol. Additionally, after implementation, the visitor gateway vendor may need to go through certification for each PMS to which the gateway will be connected. Even if the equipment vendor pays the license, service providers are rarely free to go to a hotel and attach to the hotel PMS—often the service provider is shocked that the hotel insists that they be reimbursed for “interface license fees” charged by the PMS vendor to “enable the protocol.”

The 802.1x Standard and Wireless LANs
Techniques of implementing visitor networks using wireless LANs (WLANs) have been both widely publicized and debated. Wireless 802.11 “hot spots” and the like have been the subject of great publicity because these WLANs are so convenient and cost-effective to deploy that they allow service providers to economically deploy them in areas that would be impractical to serve with wired networks. However, WLANs continue to be the topic of great debate because they have been plagued by the lack of compatibility and weaknesses in security architectures.

The 802.1x standard, recently ratified by the IEEE, holds the best promise in offering a standard authentication scheme for LANs. The 802.1x standard operates with client software. In one sample scenario, the visiting host, also known as the “supplicant,” receives an Extensible Authentication Protocol (EAP) request/identity message from the visitor network via an Ethernet switch, a WLAN access point, or a visitor gateway, any of which function as the “authenticator.” The authenticator then relays the client’s identification to an authentication server. The server then decides if the supplicant is to be allowed access and responds appropriately to the authenticator.

With WLANs, the Wired Equivalent Privacy (WEP) keys can be loaded as part of the exchange so the client and access points can operate without manual key selection. WEP has been used for several years as a method of encrypting user data over the air interface. Without WEP (or even with it, as we have seen), anyone with a laptop and a receiver can spy on the exchanged traffic [10, 11].

Microsoft ships an 802.1x client in the standard distribution of Windows XP, an important move forward in making the protocol universal. Other software vendors are shipping or have announced product for older versions of Windows, Macintoshes, Linux, and some PDAs. The 802.1x standard client implementations, however, may need firmware support on the host adapters, and support may never be available on a large number of 802.11 cards already deployed. Furthermore, all 802.1x standards are not alike because they may implement different authentication schemes. Microsoft’s current implementation uses the Extensible Authentication-Transport Level Security (EA-TLS) protocol, which requires a Public Key Infrastructure (PKI) [9]. Some critics contend that this creates additional deployment burdens on organizations with small networks. If a common provider, such as Boingo or T-Mobile, provides the visitor network in “hot spots” (that is, cafés and airports), the PKI requirement should not be an issue.

On Ethernet switches, 802.1x implemented directly on the switches may be adequate if the policy for visitor access is relatively simple. For example, if users on a particular network are all trusted employees working for the same business, the work of the authentication/authorization scheme is then to determine whether or not to allow someone to access the network, simply “port on” or “port off.” A more sophisticated approach would allow users to be classified as belonging to a set of classes. On some switches, 802.1x would allow each port to assume a set of VLAN memberships. For example, VLAN 120 would allow unrestricted Internet access, VLAN 119 would restrict access to a set of Web servers, and VLAN 118 would restrict access further to only an authentication server. The authentication system using 802.1x would direct the switch port configuration.

In practice, the control required by visitor networks needs to be far more flexible, and perhaps should be left to the visitor gateway. The gateway, as diagrammed in Figure 1, can control the routing system as well as higher-level protocol proxies based on policy. Besides, leaving the authentication behind the switches allows network implementors the flexibility of using virtually any Ethernet switch, or even other media such as Ethernet framing over xDSL.

The switch-based 802.1x approach, however, may have a significant advantage over the visitor gateway in that after the authentication is out of the way, the Ethernet switch can switch traffic simply at full speed without additional per-packet overhead.

Security Concerns—Better Just to Bootstrap?
Visitor networks are particularly vulnerable to hacking and snooping by virtue of their physical locations, especially if serviced by WLANs. Unfortunately, security is one of the few things that a service provider cannot deliver to visitors without their explicit cooperation and participation. The service providers face a difficult choice to either stay out of the solution or attempt to deliver adequate security through client configuration or special software distribution. The answer is difficult to determine; however, at least two factors to consider are whether the network is wired or wireless, and what the expectations of the visitors will be.

Weaknesses in WEP commonly offered on wireless LAN products have been very well publicized [10,11]. These weaknesses involve the encryption protocols and the fact that most implementations use manually configured keys. The latter is of little use on a visitor network because the network provider would need to disclose the same keys to everyone. Better proprietary systems have been deployed using PKI, and 802.1x is also a possibility. WEP may be replaced by much stronger Advanced Encryption Standard (AES) in Offset Codebook (OCB) mode as part of the IEEE 802.1i working group [12]. No solution has been both standardized and universally deployed. The lack of a standard and universal solution to replace WEP requires that the service provider who chooses another form of security customize a wireless solution. They may need to distribute specialized client software and/or restrict their service to supporting a set of wireless cards and drivers.

Simple Ethernet switches can provide some isolation between ports, but the learning bridge algorithms they use are designed to efficiently deliver Ethernet frames, not provide a secure service. With many switches, it takes one frame with a sham source MAC address to convince the switch to spill someone else’s traffic onto the wrong port. “Man in the middle” attacks are often trivial after a visiting host is tricked into sending its traffic somewhere else; the opportunities of doing this to another machine on the same LAN are abundant.

As an end user of a visitor network, trusting an unfamiliar service provider in an unknown environment is a fundamentally insecure process. So, why not let the visitor network provide the basic IP connectivity in order to bootstrap the connection, and then let the visitors themselves implement the security on top? One reason is that unsuspecting users getting hacked at their favorite hotel chain does not bode well for the hotel if the incidents end up in the press. Guests probably feel pretty secure using the hotel phone for a dial-in network connection without any encryption; many also feel secure locking the door with the sliding chain.

One reasonable compromise is matching the security of a dial-in connection. A wired Ethernet, assuming that it cannot be easily coaxed to spill traffic between ports, could present an acceptable risk level. On the other hand, a poorly protected wireless network is like a hotel door without a lock.

If the visitor network offers no protection, then the burden is placed completely on the visitors to implement their own end-to-end security. Using Virtual Private Network (VPN) software that implements IP Security (IPSec) is one possibility. Unfortunately, even that is not always straightforward, given the complexities with using protocols such as IPSec over NATs [13]. Other protocols such as Transport Layer Security (TLS) and Secure Shell (SSH), which operate above the network layer, may be a better option. In addition, several proprietary VPN protocols are designed to tunnel through NATs. Those without any security solution could compromise not only their personal data but also the security of their employer’s networks.

Any long-term security solution is going to demand proper client configuration and compatible software. Ultimately, development of standards and client sophistication will make this possible, but in the meantime, we will need to choose between ease of connecting to an insecure network and dealing with the potential multiple layers of authentication and encryption before gaining access. Sadly, faced with this choice and looking forward to a 7 a.m. meeting, the trusty hotel phone and modem jack on the laptop might look pretty inviting.

Summary
Visitor networks allow service providers to provide access in public places. These networks can be implemented in a way that either may or may not require specialized client software on the visiting host. Client software allows service providers to more carefully control the behavior of the visiting host but, at the same time, may limit the user base to those who have the software installed.

Visitor networks often rely on a visitor gateway to perform functions generally not required on a traditional LAN. The gateway, which shares certain characteristics with a NAS, is responsible for routing, address assignment, translation, TCP/UDP redirection, authentication, accounting, and affecting policy.

The visitor gateway exchanges packets with the visiting hosts via LANs. On Ethernet, VLANs are often best suited to visitor networks because they allow the gateway to address each client separately providing the greatest level of isolation compared to other Ethernet options.

WLANs represent an important advance toward the universal deployment of visitor networks in “hot spots.” However, the lack of a common and effective solution may force service providers to choose between ease of access and security. Visitors may choose to implement a VPN or security scheme on top of the raw IP access offered by the visitor network.

References
[1] L. Mamakos, K. Lidl, J. Evarts, D. Carrel, D. Simone, R. Wheeler, “A Method for Transmitting PPP over Ethernet (PPPoE),” RFC 2516, February 1999.

[2] W. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn, B. Palter, “Layer 2 Tunneling Protocol, L2TP,” RFC 2661, August 1999.

[3] S. Glass, T. Hiller, S. Jacobs, C. Perkins, “Mobile IP Authentication, Authorization, and Accounting Requirements,” RFC 2977, October 2000.

[4] IEEE Standards for Local and Metropolitan Area Networks: Port-Based Network Access Control, IEEE Std 802.1X-2001, June 2001.

[5] W. Simpson, “The Point-to-Point Protocol (PPP),” STD 51, RFC 1661, July 1994.

[6] R. Droms, “Dynamic Host Configuration Protocol,” RFC 2131, March 1997.

[7] A. Rubens, W. Simpson, S. Willens, C. Rigney, “Remote Authentication Dial-In User Service (RADIUS),” RFC 2058, January 1997.

[8] IEEE standard for local and metropolitan area networks: Virtual Bridged Local Area Networks, IEEE Std 802.1Q-1998.

[9] B. Adoba, D. Simon, “PPP EAP TLS Authentication Protocol,” RFC 2716 (experimental), October 1999.

[10] N. Borisov, I. Goldberg, D. Wagner, “Intercepting Mobile Communications: The Insecurity of 802.11,” http://www.isaac.cs.berkeley.edu/isaac/wep-faq.html

[11] E. Danielyan, “IEEE 802.11,” The Internet Protocol Journal, Volume 5, Number 1, March 2002.

[12] D. Whiting, R. Housley, “AES Encryption & Authentication Using CTR Mode with CBC-MAC,” Status of Project IEEE 802.11i, July 2002.

[13] B. Adoba, “IPSec-NAT Compatibility Requirements,” Internet-Draft, March 1, 2002.

DORY LEIFER is a principal with DEL Communications Consulting, Inc. He had cofounded PublicPort in 1998, an Ann Arbor, Michigan, startup that developed one of the first visitor network gateways. After Tut Systems acquired PublicPort, he held a director of marketing position with Tut until 2001. Leifer spent 11 years with the University of Michigan and Merit Network and during that time contributed to the Internet Engineering Task Force (IETF). He has taught tutorials in access technologies for various seminars and tutorials, including NetWorld+Interop. He holds a B.S. in Computer Science from Rensselaer Polytechnic Institute and an M.S.E. in Industrial and Operations Engineering from the University of Michigan. Leifer currently resides in the San Francisco Bay Area and can be reached by e-mail at leifer@del.com