FRAMINGHAM (10/02/2003) - As companies roll out wireless networks, one area of concern is how to automatically segment wireless users into the correct virtual LANs already established on the wired side. VLAN membership on wired networks typically is defined by the physical Layer 2 switch or Layer 3 router port to which a user is connected. But with wireless, users aren't tied to a physical port.
To address this problem, advances in wireless authentication have led to role-based VLAN association. This method of automatically deriving the correct VLAN membership uses a number of standard authentication methods, such as HTTP-based captive portals and 802.1X, which has become the authentication mechanism of choice.
Consider this scenario. Wireless users in a finance department might be connected securely to the Finance VLAN using a secure-link encryption method such as Wi-Fi Protected Access. However, once they roam to another access point, they no longer necessarily have access to the Finance VLAN and can't use their network resources. Reconfiguring the network to make each VLAN accessible from every point across the entire company is not a viable solution.
However, 802.1X port-based authentication provides a framework for authorizing station access to Ethernet and wireless LANs. 802.1X uses Extensible Authentication Protocol (EAP) to relay port-access requests between LAN stations (supplicants), Ethernet switches or wireless access points (authenticators), and RADIUS servers (authentication servers).
The central mechanism used to protect users in Wi-Fi networks is based on data encryption and user authentication - not typically by roles derived from an authentication method. Role-based VLAN association with 802.1X is attractive because it provides logical segmentation of workgroup traffic, and easier integration with security and traffic-engineering policies configured on wired networks.
Network administrators want to keep the same Extended Service Set IDs (ESSID) and encryption profiles for all users, and assign users in different workgroups to different VLANs as they enter the wireless LAN (WLAN), based on attributes already configured on the authentication server. Without role-based VLANs, this isn't possible unless you make a lot of changes to WLAN configuration by introducing new ESSIDs for each user group. This represents a significant capital investment and operational expense.
A WLAN switch can support a variety of user roles with different access rights and VLAN associations. It also can support a variety of server rules from which to derive a user role, such as the RADIUS attributes in the access-accept message from the RADIUS server. For example, a server rule can be defined to extract the value of a specific RADIUS attribute (say Attribute 11, Filter-Id) and use the value as the role. In 802.1X authentication, the client authenticates to the RADIUS server through a WLAN switch. The WLAN associates a VLAN to the client based on the role derived by applying the server rules.
The WLAN switch puts the client in unauthorized state once 802.11 association with an access point is complete. In this state, only 802.1X EAP packets generated by the client are forwarded through the WLAN switch. The WLAN switch sends an EAP Request-ID, a user identity request message, to the client. The client responds with an EAP Response-ID message. The WLAN switch encapsulates the EAP Response-ID as a RADIUS access-request message and forwards it to the RADIUS server.
If authentication is successful, the RADIUS server sends an access-accept message to the WLAN switch. This message identifies different user attributes such as role and access rights. The WLAN switch then parses this response to determine into which VLAN the client should be placed.
Using this information, the WLAN switch places the client in an authorized state and sends an EAP Success message. It then forwards all future data traffic from the client to the right VLAN. Upon receiving the EAP Success message, the client starts a Dynamic Host Configuration Protocol transaction to get an IP address on the role-based VLAN.
Iyer is a principal software developer at Aruba Wireless Networks. He can be reached at firstname.lastname@example.org.