Working with Devices Incapable of 8021X
Today, 802.1X is the recommended port-based authentication method at the access layer in enterprise networks.
However, not all devices have an 802.1X-supplicant capability embedded into their operating system (OS). For example, most printers, IP phones, fax machines, and so on do not have this capability, but they still need to be allowed into the network even without 802.1X authentication. A supplemental authentication technique should be employed as the basis of the nonresponsive host issue with 802.1X. This solution-based feature set is MAC Authentication Bypass (MAB). IBNS also focuses on clients who do not possess 802.1X capability or whose 802.1X capability might be temporarily suspended to support mobility into environments where the end user/client might not be otherwise known to the authentication infrastructure in advance. When 802.1X is implemented in such an environment, you typically need the ability to dynamically provision individual MAC addresses (without impacting service availability) for network authentication of nonresponsive devices, such as printers, videoconferencing units, satellite receivers, faxes, and so on. MAB controls network access based on a MAC address. MAB's goals are to provide network access control on a port basis based on a MAC address and to dynamically apply policy to a client session based on a MAC address.
The Guest-VLAN might also provide access for clients incapable of 802.1X and where the client MAC address might be unknown in advance. Although originally designed as a deployment enabled for 802.1X-supplicant functionality on end stations, the Guest-VLAN also provides an option for mobile guest users.
802.1X Guest-VLAN
If you start to deploy 802.1X in a network, leveraging Guest-VLAN functionality is a key element in providing network access to clients who are not equipped with an 802.1X supplicant. The 802.1X Guest-VLAN functionality was initially developed as a migration tool to allow enterprises to easily migrate client devices to support 802.1X while still providing network connectivity.
Any VLAN can be configured as the Guest-VLAN, except private VLANs (PVLANs), voice VLANs (VVID), and the VLAN used for Remote SPAN (RSPAN). Most Cisco Catalyst platforms currently support the Guest-VLAN feature. Figure 17-6 demonstrates the functionality of the 802.1X Guest-VLAN feature.
Currently, when a switch port initially receives a link, an EAP-Identity-Request message is sent to actively look for an 802.1X supplicant. This happens regardless of whether the device connected to the port is actually equipped with the supplicant.
Figure 17-6 802.1X Guest-VLAN Operation Client
00.0a.05.71.de.08
00.0a.05.71.de.08
EAPOL-Request (Identity) D = 01.80.c2.00.00.03
EAPOL-Request (Identity) D = 01.80.c2.00.00.03
EAPOL-Request (Identity) D = 01.80.c2.00.00.03
Dol1x Process
Upon Link Up
30 Seconds
30 Seconds
30 Seconds
802.1X Guest-VLAN Timing
Assuming that a user does not have the 802.1X capability on her machine, the request from the switch goes unanswered. After the expiration of a timer (tx-period), the switch sends a new EAP-Identity-Request frame. The 802.1X specification dictates this behavior. This process continues until the third request from the switch goes unanswered. The number of retries is driven by the value of the max-reauth-req parameter. After the maximum number of retries is exceeded, and if the switch port has been configured with the 802.1X Guest-VLAN functionality, the port is moved to the Guest-VLAN, and the switch sends an EAP-Success message. The client ignores and discards this message if not enabled for 802.1X.
From the point of view of the 802.1X process, the port has become authorized, and the 802.1X state machine has entered the authenticated state; no further security or authentication mechanisms are applied. (The 802.1X state machine stops running.) It is basically as if the administrator disabled 802.1X and hardset the port into that specific VLAN. The behavior illustrated is valid when using default values for the 802.1X parameters that affect Guest-VLAN functionality: max-reauth-req and tx-period.
The max-reauth-req parameter sets the maximum number of times that the switch retransmits an EAP-Identity-Request frame on the wire before receiving a response from the connected client. By default, this value is set to 2. This is why Figure 17-6 shows two retries (Steps 2 and 3) after the initial EAP-Identity-Request frame sent at linkup. Here are the commands that change this parameter:
Switch(config-if)#dot1x max-reauth-req ?
<1-10> Enter a value between 1 and 10
The tx-period parameter sets the number of seconds that the switch waits for a response to an EAP-Identity-Request frame from the client before resending the request. The default value is 30 seconds; it is configurable as follows:
Switch(config-if)#dot1x timeout tx-period ?
<1-65535> Enter value between 1 and 65535
NOTE The max-req parameter is part of the configurable 802.1X parameter in Cisco IOS. The max-req parameter is different from the max-reauth-req parameter and represents the maximum number of retries a switch performs for EAP-Request frames of types other than EAP-Identity-Request. Basically, this parameter refers to EAP-Data frames, which are the EAP frames exchanged after the supplicant has replied to the initial EAP-Identity-Request frame. For this reason, the max-req parameter is only effective when a valid 802.1X supplicant is connected, and it does not apply to Guest-VLAN services.
The overall default configuration of the 802.1X Guest-VLAN is relatively simple, and it is demonstrated as follows:
interface FastEthernet0/1 switchport access vlan 2 switchport mode access dotlx port-control auto dotlx guest-vlan 10
The following formula calculates the time interval before the Guest-VLAN is enabled:
[(max-reauth-req + 1) * tx-period] The time to enable a port in the Guest-VLAN can be tweaked to 2 seconds:
interface FastEthernet0/1 switchport access vlan 2 switchport mode access dotlx port-control auto dotlx guest-vlan 10 dotlx timeout tx-period 1 dot1x max-reauth-req 1
Only attempt this configuration after you consider the consequences that this can have on the regular functionality of 802.1X. For example, if you configure the Guest-VLAN to be a different VLAN than the access VLAN, a port might forward into the Guest-VLAN too quickly; if protecting the end host is paramount, this operation might not be desired. Also, from a security perspective, 802.1X is the dialup networking model. The default timers tend to follow least access principles in terms of security to provide access only when a supplicant dials on the connection. Also, analyzing the integration issues between 802.1X and DHCP at startup time helps in understanding this. In the end, it is possible to set the tx-period and max-reauth-req parameters to the minimum configurable values to reduce the time interval required for the deployment of a switch port in the Guest-VLAN.
Continue reading here: MAC Authentication Primer
Was this article helpful?