Beruflich Dokumente
Kultur Dokumente
Overview
Cisco has supported 802.1x authentication for 802.11 LANs since November 2000 with the
introduction of the Lightweight Extensible Authentication Protocol (LEAP) algorithm.
Cisco 802.1x/LEAP provides user-based, centralized authentication, as well as per-user
wired equivalent privacy (WEP) session keys. Wireless LAN network administrators have
been taking advantage of the simplified user and security administration that LEAP provides.
Cisco support for 802.1x includes support for most EAP authentication types. With the
introduction of Windows XP, Cisco supports the Transport Layer Security (TLS) EAP
subtype, EAP-TLS, as well. As wireless LANs become more prevalent in enterprise networks,
they are also extending into the enterprise branch office (Figure 1).
Cisco Aironet® deployments in the branch office may send authentication requests back to
the authentication server (access control server [ACS] or Remote Access Dial-In User Service
[RADIUS] server) across a WAN link. The 802.1x framework uses RADIUS messages for
communications between the access point and the authentication server. RADIUS messages
use User Datagram Protocol (UDP) and are connectionless, so it is possible during WAN link
congestion for RADIUS packets to be delayed or dropped. This can cause delays or
authentication timeouts to users attempting to authenticate to an access point, or when
roaming to a different access point.
This issue is overcome by giving the RADIUS packets priority on transmissions both from
the access point to the RADIUS server and from the RADIUS server to the access point.
When priority is given to the RADIUS packets, the WAN routers service them before
lower-priority traffic. The end result is that LEAP clients can authenticate successfully during
times of WAN link congestion.
This document discusses the requirements and prerequisites for classifying and marking
RADIUS packets using the Cisco Modular QoS Command Line (MQC), a methodology to
determine the appropriate queue size for the 802.1x/RADIUS packets, and to determine how
to enable queuing on router interfaces to provide priority for the RADIUS packets during
network congestion. Although this paper is targeted for any 802.1x authentication type,
Cisco LEAP is used in the examples. The methodology in prioritizing traffic can be applied
to other algorithms as well.
Enterprise
Campus/
Headquarters Enterprise
Network
ACS
Enterprise
WAN
Enterprise
Branch Offices
Prerequisites
• Router requirements—Refer to http://www.cisco.com/en/US/products/ps6558/
products_ios_technology_home.html for Cisco IOS® platform requirements
• Access point requirements—Minimum access point firmware of 11.06 for LEAP Draft 10, recommended 11.10T
• Client requirements—ACU 4.15.006, Drivers 6.97, and firmware of 4.25.10 (LEAP Draft 10), recommended
ACU 5.01, Drivers 8.01.06, and firmware of 4.25.23
This document assumes that 802.1x authentication is already configured on the access point, client, and ACS.
This document assumes a basic understanding of quality of service (QoS) and differentiated services (DiffServ)
technology and techniques.
This document focuses on prioritizing RADIUS packets from the access point to the RADIUS server and from the
RADIUS server to the access point across congested WAN links. In order to provide the appropriate perspective on
the authentication messages, this section reviews the 802.1x standard for the wireless authentication process.
Cisco LEAP, like many EAP variants used for wireless LAN authentication, is an authentication algorithm that
utilizes the 802.1x authentication framework. The 802.1x standard is the messaging between a LEAP-enabled
RADIUS server, 802.1x authenticator (the access point), and a LEAP-enabled client (the wireless station).
Understanding the 802.1x message flow provides the necessary insight into LEAP for the purposes of this paper.
The client becomes active on the medium and associates to the access point. The access point detects the client
association and enables the client’s port. It forces the port into an unauthorized state, so only 802.1x traffic is
forwarded. Traffic such as Dynamic Host Configuration Protocol (DHCP), Hypertext Transfer Protocol (HTTP), File
Transfer Protocol (FTP), Simple Message Transfer Protocol (SMTP), Post Office Protocol 3 (POP3), and so on is
blocked. The client can send an EAP-Start message, although client initiation is not required (Figure 2).
The access point replies with an EAP-Request Identity message back to the client to obtain the client’s identity. The
client’s EAP-Response packet containing the client’s identity is forwarded to the authentication server.
The authentication server is configured to authenticate clients with a specific authentication algorithm. Currently,
802.1x for 802.11 LANs does not stipulate a specific algorithm to use, but because we are focusing on LEAP, the
assumption is that LEAP credential verification takes place.
The end result is an ACCEPT or REJECT packet from the authentication server to the access point.
Upon receiving the ACCEPT packet, the access point transitions the clients port to an authorized state, and traffic
is forwarded.
RADIUS
Client Server
AP
Start
AP blocks all requests until
authentication completes
Request Identity
Identity Identity
Lab Setup
Figure 3 shows the test network used to simulate the branch office connectivity to the central ACS.
Cisco LEAP
Client
The WAN is simulated using an Adtran Atlas 800Plus WAN circuit emulator. A T1 is provisioned for use between
the main WAN router and the branch office router. To simplify the testing, only one 64-kbps channel is enabled on
the routers.
To generate the congestion, two FTP file transfers are initiated by a wired client on the branch office side of the
network to a server on the other side of the WAN link. To saturate both directions of the link, one FTP is a PUT
sending a large file to the server, while the other is a GET, receiving a large file from the server.
When the transfers are under way, the wireless client attempts to LEAP authenticate. With no QoS in place, the
authentication will fail. A packet trace illustrates the failure (Figure 4):
The access point, with IP address 172.24.100.247, is attempting to reach RADIUS server 172.24.100.156. The first
Access-Request message (ID = 41) is received, and 172.24.100.156 responds back to the access point. The second
Access-Request message (ID = 42) does not receive a response, so the access point issues an Internet Control Message
Protocol (ICMP) destination unreachable message, indicating that the host is not responding.
Because every network implementation is different, no QoS configuration will meet the needs of every
implementation. This document assumes that no other traffic requires prioritization. In actual implementations,
prioritizing 802.1x/LEAP RADIUS packets can be done while maintaining voice and video, or any other application
priority.
To give LEAP RADIUS packets priority, three things must happen to the packets:
1. The packets are classified as they enter the router ingress interface.
2. The classified packets are marked with a differentiated service code point (DSCP) or IP Precedence value.
3. The classified packets are placed in a priority transmit queue.
Figure 5 shows the packet classification and marking process in the router.
Ingress Packets Router Ingress Interface Classify Packets Mark Packets Router Egress Interface
Class Queue
RADIUS
1 RADIUS
RADIUS
1 RADIUS
Best Effort Queue
Note: For full details on packet classification and marking, refer to:
http://www.cisco.com/en/US/products/sw/iosswrel/ps1835/products_configuration_guide_chapter09186a00800bd909.html
To classify the packets, a simple ACL is needed to “catch” only RADIUS packets that are destined or sourced from
the authentication server.
On the branch office router in our testbed, the following ACL was used:
ip access-list extended LEAP
permit udp any host 172.24.100.156 eq 1645
The ACL permits UDP traffic from any source address to the destination address of 172.24.100.156 and a
destination port of 1645 (the IP address and port of the ACS).
Note: In the testbed, the only RADIUS traffic is 802.1x/LEAP authentication messages. In an actual
implementation, the RADIUS traffic may include non-LEAP messages, which would be incorrectly prioritized. If that
happens, the ACL can be made more granular by including the IP addresses of the access points in the ACLs.
With the ACLs granular enough to catch the RADIUS packets, yet broad enough to scale to handle multiple access
points, the next step is to create the classifications. This is accomplished using the class-map Cisco IOS command.
The class-map command enables the router to use the ACL to classify the traffic.
The command as implemented on both the branch office and corporate WAN routers follows:
class-map match-any LEAP
match access-group name LEAP
The commands create a class map called “LEAP” that classifies traffic that matches the access list named “LEAP.”
Classifying the traffic has made the router aware that the traffic is “interesting.” The traffic has no marking applied
to it yet, nor has any queuing been configured to prioritize it with respect to normal traffic.
Marking the LEAP RADIUS packets is the next step. Marking modifies the three type of service (ToS) bits (Figure 6)
or six DSCP bits in the IP header (Figure 7). DSCP values are used in the testbed network, because DSCP is the latest
and best classification and marking framework to date, although IP Precedence works as well.
Bits: 0 1 2 3 4 5 6 7
DTR – Bits
Must
Be
RFC 1122 Zero
RFC 1349
Bits (0–2): IP-Precedence Defined Bits (3–6): The Type of Service Defined
111 – Network Control 0000 (all normal)
110 – Internetwork Control 1000 (minimize delay)
101 – CRITIC/ECP 0100 (maximize throughput)
100 – Flash Override 0010 (maximize reliability)
011 – Flash 0001 (minimize monetary cost)
101 – Immediate
001 – Priority
000 – Routine
Bits: 0 1 2 3 4 5 6 7
DS-Field DSCP CU
Class Selector
Codepoints Currently
Unused
Standard 802.1x RADIUS packets are considered network control packets, so to maintain consistency with other
Cisco products and standards, 802.1x RADIUS frames are marked as DSCP value AF31. For some perspective, the
AF31 marking places 802.1x RADIUS frames in the same class as voice over IP (VoIP) call control packets.
The packets are marked using the policy-group Cisco IOS command. The policy-group command marks packets
based on the classifications defined with the class-map command.
The command as implemented on both the branch office and corporate WAN routers follows:
class-map match-any LEAP
match access-group name LEAP
!
policy-map mark
class LEAP
set ip dscp 26
The policy group called “mark” marks all LEAP classified traffic and sets the DSCP value in the packet to a DSCP
26 or AF31.
The LEAP RADIUS traffic is now classified and marked. The show policy-group interface Cisco IOS command is
used to verify that LEAP RADIUS packets are being properly marked. The output is as follows:
irv3-wnbu-mmbo1#show policy-map interface f0/0.100
FastEthernet0/0.100
Class-map: LEAP(match-any)
63 packets, 13641 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: access-group name LEAP
63 packets, 13641 bytes
5 minute rate 0 bps
QoS Set
ip dscp 26
Packets marked 63
The last line of output shows that 63 classified packets have been marked with a DSCP value of 26.
The 802.1x/LEAP RADIUS traffic is now classified and marked for priority. The traffic is still forwarded as normal
traffic, so the last step is to prioritize the LEAP RADIUS traffic.
Before router configuration takes place, a few queuing decisions need to be made:
1. Is the 802.1x/LEAP traffic the only traffic that needs to be prioritized (voice traffic may be present and
require QoS)?
2. What queuing algorithm will be used?
This document provides a methodology for prioritizing LEAP RADIUS traffic. What is critical is how LEAP RADIUS
traffic relates to other priority traffic (such as voice, video, or application-specific traffic) and normal traffic.
In our testbed, the only traffic that requires priority is LEAP RADIUS traffic. Because the possibility of voice existing
on a WAN is high, 802.1x traffic is not placed in a strict priority queue (assuming the use of low-latency queuing
[LLQ] or IP Real-Time Transport Protocol [RTP] Priority Queuing). Class-Based Weighted Fair Queuing (CBWFQ)
is used, and 802.1x RADIUS packets are placed in a class queue with a bandwidth guarantee. Unclassified data
packets are placed in the best-effort queue.
The size of the 802.1x transactions will vary by EAP type. In the LEAP example, the size of each RADIUS packet
requires approximately 1.5 kb of bandwidth. These values will vary, based on username length, network access server
name, and other variable fields. To maintain simplicity, the bandwidth requirement should be symmetric in both
directions; the corporate WAN router queue matches the remote branch office router queue.
Given that the smallest bandwidth requirement configurable is 8 kb, approximately five authentications per second
can be supported at any given time. The number of authentications per second in a wireless LAN depends on the
number of users and the WEP key rekey interval.
An 8-kb queue can service up to five authentications per second and can scale to up 3000 users (at the rate of five
authentications per second). As the number of authentications per second increases, the bandwidth requirement
should increase (Figure 8).
16
14
Bandwidth Requirement
12
10
0
1 2 3 4 5 6 7 8 9 10
Authentications Per Second
Prioritizing the LEAP RADIUS packets over normal traffic is the last step—it is also the most crucial step.
Now that we have defined the queue and bandwidth guarantee for LEAP RADIUS packets, we apply the queuing to
an interface. Using the service-policy command in the same manner used previously to mark traffic, the policy group
“queue” is applied to the WAN interface. The following example illustrates the application of the command.
interface Serial3/0:0
load-interval 30
The service-policy command directs outbound packets on the link to conform to the policy group named “queue.”
This is done on both WAN routers.
To verify that the egress interface is giving the classified packets the correct priority, the show policy-group Cisco IOS
command is used. The following is an example from the testbed:
irv3-wnbu-wan1#show policy-map interface s2/0/0:0
Serial2/0/0:0
class-map: LEAP(match-all)
20 packets, 2631 bytes
5 minute offered rate 0 bps, drop rate 0 bps
match: access-group LEAP
queue size 0, queue limit 10
packets output 20, packet drops 0
tail/random drops 0, no buffer drops 0, other drops 0
bandwidth: kbps 8, weight 62
irv3-wnbu-wan1#
The output from the command reveals that 20 packets matched the ACL named “LEAP,” and those 20 packets were
prioritized according to the settings in the policy group named “queue.” The 802.1x/LEAP RADIUS packets were
successfully prioritized.
Just as congestion can occur on a high-utilization WAN link, it can occur on LAN links as well. If necessary, the
process for classifying and queuing high-priority traffic such as LEAP RADIUS packets can be done end to end from
the first router hop from the access point to the last router before the ACS or RADIUS server. This requirement varies
on a case-by-case basis, but the methodology for classifying, marking, and queuing packets is the same as that
detailed for the WAN link in the testbed.
This paper describes how to utilize Cisco MQC and robust QoS support to cost-effectively deploy secure wireless
LANs to remote offices. The ACS server has a recommended limit of 40 authentications per second. It may be
possible for a large number of remote users to place excessive strain on the ACS server, or possibly the WAN link. At
some point, a local ACS server or dedicated ACS server for remote clients may be needed. The scenarios for this will
vary on a case-by-case basis, but it is important not to discount the possibility of deploying a local or dedicated ACS
server.
Cisco Systems has more than 200 offices in the following countries and regions. Addresses, phone numbers, and fax numbers are listed on the
Cisco Web site at www.cisco.com/go/offices
Argentina • Australia • Austria • Belgium • Brazil • Bulgaria • Canada • Chile • China PRC • Colombia • Costa Rica • Croatia
Czech Republic • Denmark • Dubai, UAE • Finland • France • Germany • Greece • Hong Kong SAR • Hungary • India • Indonesia • Ireland
Israel • Italy • Japan • Korea • Luxembourg • Malaysia • Mexico • The Netherlands • New Zealand • Norway • Peru • Philippines • Poland
Portugal • Puerto Rico • Romania • Russia • Saudi Arabia • Scotland • Singapore • Slovakia • Slovenia • South Africa • Spain • Sweden
S w i t z e r l a n d • Ta i w a n • T h a i l a n d • Tu r k e y • U k r a i n e • U n i t e d K i n g d o m • U n i t e d S t a t e s • Ve n e z u e l a • Vi e t n a m • Z i m b a b w e
All contents are Copyright © 1992–2002 Cisco Systems, Inc. All rights reserved. Aironet, Cisco, Cisco IOS, Cisco Systems, and the Cisco Systems logo are registered trademarks of Cisco Systems, Inc. and/or its affiliates in
the U.S. and certain other countries.
All other trademarks mentioned in this document or Web site are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company.
(0201R)
03/02 BW8054