aaa authentication dot1x default group radius Figure describes the basic process for configuring AAA.

Content 8.1 Understanding Switch Security Issues 8.1.10 802.1x Port-Based Authentication The IEEE 802.1x standard defines a port-based access control and authentication protocol that restricts unauthorized workstations from connecting to a LAN through publicly accessible switch ports. The authentication server authenticates each workstation connected to a switch port before making available any services offered by the switch or the LAN. Until the workstation is authenticated, 802.1x access control allows only Extensible Authentication Protocol over LAN (EAPOL) traffic through the port to which the workstation is connected. After authentication succeeds, normal traffic can pass through the port. With 802.1x port-based authentication, the devices in the network have the following specific roles:

Client: The device (workstation) that requests access to the LAN and switch services, and responds to requests from the switch. The workstation must be running 802.1x-compliant client software, such as what is offered in the Microsoft Windows XP and Vista operating systems. (The port that the client is attached to is the supplicant [client] in the IEEE 802.1x specification.)
Authentication server: Performs the actual authentication of the client. The authentication server validates the identity of the client and notifies the switch whether or not the client is authorized to access the LAN and switch services. Because the switch acts as the proxy, the authentication service is transparent to the client. The RADIUS security system with EAP extensions is the only supported authentication server.
Switch (also called the authenticator): Controls physical access to the network based on the authentication status of the client. The switch acts as an intermediary (proxy) between the client (supplicant) and the authentication server, requesting identifying information from the client, verifying that information with the authentication server, and relaying a response to the client. The switch uses a RADIUS software agent, which is responsible for encapsulating and decapsulating the EAP frames and interacting with the authentication server.

The switch port state determines whether the client is granted access to the network. The port starts in the unauthorized state. While in this state, the port disallows all ingress and egress traffic, except for 802.1x protocol packets. When a client is successfully authenticated, the port transitions to the authorized state, allowing all traffic for the client to flow normally. If the switch requests the client identity (authenticator initiation) and the client does not support 802.1x, the port remains in the unauthorized state, and the client is not granted access to the network. In contrast, when an 802.1x-enabled client connects to a port and the client initiates the authentication process (supplicant initiation) by sending the EAPOL-start frame to a switch not running the 802.1x protocol, no response is received, and the client begins sending frames as if the port is in the authorized state. You control the port authorization state by using the dot1x port-control interface configuration command and these keywords:

force-authorized: Disables 802.1x port-based authentication and causes the port to transition to the authorized state without any authentication exchange required. The port transmits and receives normal traffic without 802.1x-based authentication of the client. This is the default setting.
force-unauthorized: Causes the port to remain in the unauthorized state, ignoring all attempts by the client to authenticate. The switch cannot provide authentication services to the client through the interface.
auto: Enables 802.1x port-based authentication and causes the port to begin in the unauthorized state, allowing only EAPOL frames to be sent and received through the port. The authentication process begins when the link state of the port transitions from down to up (authenticator initiation) or when an EAPOL-start frame is received (supplicant initiation). The switch requests the identity of the client and begins relaying authentication messages between the client and the authentication server. The switch uniquely identifies each client attempting to access the network with the client MAC address.

If the client is successfully authenticated (receives an “accept” frame from the authentication server), the port state changes to authorized, and all frames from the authenticated client are allowed through the port. If the authentication fails, the port remains in the unauthorized state, but authentication can be retried. If the authentication server cannot be reached, the switch can retransmit the request. If no response is received from the server after the specified number of attempts, authentication fails and network access is not granted. When a client logs off, it sends an EAPOL-logoff message, causing the switch port to transition to the unauthorized state. The commands for configuring 802.1x are illustrated in Figure . To implement 802.1x port-based authentication, follow the steps in Figure . In Figure , the example shows how to enable AAA and 802.1x on Fast Ethernet port 5/1.

Content 8.2 Protecting Against VLAN Attacks 8.2.1 Explaining VLAN Hopping VLAN hopping is a network attack whereby an end system sends packets to, or collects packets from, a VLAN that should not be accessible to that end system. This is accomplished by tagging the invasive traffic with a specific VLAN ID or by negotiating a trunk link to send or receive traffic on penetrated VLANs. VLAN hopping can be accomplished by switch spoofing or double tagging. In a switch spoofing attack, the network attacker configures a system to spoof itself as a switch by performing Inter-Switch Link (ISL) or 802.1Q trunking, along with Dynamic Trunking Protocol (DTP) negotiations, to establish a trunk connection to the switch. Any switch port configured as DTP auto may become a trunk port when a DTP packet generated by the attacking device is received, and thereby accept traffic destined for any VLAN supported on that trunk. The malicious device can then send packets to, or collect packets from, any VLAN carried on the negotiated trunk. Figure describes the switch spoofing sequence of events. Another method of VLAN hopping is for a workstation to generate frames with two 802.1Q headers to get the switch to forward the frames onto a VLAN that would be inaccessible to the attacker through legitimate means. If the double-tagged frame has a multicast, broadcast, or unknown destination, the switch that receives the frame floods this frame out all ports attached to the same VLAN (VLAN 10) as the attacker’s port native VLAN. The switch would strip the first VLAN tag before forwarding, provided this tag matched the native VLAN of the port it was received on. Any access port on this first switch assigned to VLAN 10 would receive the frame with the second VLAN tag. If a trunk port has the same native VLAN (VLAN 10), the switch would not re-tag the frame and it would arrive at the next switch with only the second VLAN tag. The second switch would then believe the frame originated from a different VLAN (VLAN 20) and thus flood it out to all ports active in this second VLAN. Also the second switch would forward the frame on any additional trunks that were active with the second VLAN. If the trunk port on the first switch was assigned a different VLAN than the attacker’s port, the frame would simply be flooded to all active ports in VLAN 10 on both switches (no VLAN hopping). The reason is that the first switch would tag the 801.1Q frame with the attacker’s port VLAN prior to sending it across the trunk. Figure describes the double-tagging method of VLAN hopping.

Content 8.2 Protecting Against VLAN Attacks 8.2.2 Mitigating VLAN Hopping