draft-ietf-capwap-protocol-binding-ieee80211-00.txt   draft-ietf-capwap-protocol-binding-ieee80211-01.txt 
Network Working Group P. Calhoun, Editor Network Working Group P. Calhoun, Editor
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Intended status: Informational M. Montemurro, Editor Expires: July 27, 2007 M. Montemurro, Editor
Expires: April 16, 2007 Research In Motion Research In Motion
D. Stanley, Editor D. Stanley, Editor
Aruba Networks Aruba Networks
October 13, 2006 January 23, 2007
CAPWAP Protocol Binding for IEEE 802.11 CAPWAP Protocol Binding for IEEE 802.11
draft-ietf-capwap-protocol-binding-ieee80211-00 draft-ietf-capwap-protocol-binding-ieee80211-01
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 37 skipping to change at page 1, line 37
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 16, 2007. This Internet-Draft will expire on July 27, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
Abstract Abstract
Wireless LAN product architectures have evolved from single Wireless LAN product architectures have evolved from single
autonomous access points to systems consisting of a centralized autonomous access points to systems consisting of a centralized
Access Controller (AC) and Wireless Termination Points (WTPs). The Access Controller (AC) and Wireless Termination Points (WTPs). The
general goal of centralized control architectures is to move access general goal of centralized control architectures is to move access
control, including user authentication and authorization, mobility control, including user authentication and authorization, mobility
management and radio management from the single access point to a management and radio management from the single access point to a
centralized controller. centralized controller.
skipping to change at page 2, line 31 skipping to change at page 2, line 31
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Conventions used in this document . . . . . . . . . . . . 4 1.2. Conventions used in this document . . . . . . . . . . . . 4
1.3. Contributing Authors . . . . . . . . . . . . . . . . . . . 4 1.3. Contributing Authors . . . . . . . . . . . . . . . . . . . 4
1.4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 4 1.4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 4
1.5. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.5. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. IEEE 802.11 Binding . . . . . . . . . . . . . . . . . . . . . 6 2. IEEE 802.11 Binding . . . . . . . . . . . . . . . . . . . . . 6
2.1. Split MAC and Local MAC Functionality . . . . . . . . . . 6 2.1. Split MAC and Local MAC Functionality . . . . . . . . . . 6
2.1.1. Split MAC . . . . . . . . . . . . . . . . . . . . . . 6 2.1.1. Split MAC . . . . . . . . . . . . . . . . . . . . . . 6
2.1.2. Local MAC . . . . . . . . . . . . . . . . . . . . . . 8 2.1.2. Local MAC . . . . . . . . . . . . . . . . . . . . . . 9
2.2. Roaming Behavior . . . . . . . . . . . . . . . . . . . . . 11 2.2. Roaming Behavior . . . . . . . . . . . . . . . . . . . . . 12
2.3. Group Key Refresh . . . . . . . . . . . . . . . . . . . . 12 2.3. Group Key Refresh . . . . . . . . . . . . . . . . . . . . 13
2.4. BSSID to WLAN ID Mapping . . . . . . . . . . . . . . . . . 13 2.4. BSSID to WLAN ID Mapping . . . . . . . . . . . . . . . . . 14
2.5. Quality of Service for IEEE 802.11 MAC Management 2.5. Quality of Service for IEEE 802.11 MAC Management
Messages . . . . . . . . . . . . . . . . . . . . . . . . . 13 Messages . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.6. Run State Operation . . . . . . . . . . . . . . . . . . . 13 2.6. Run State Operation . . . . . . . . . . . . . . . . . . . 14
3. IEEE 802.11 Specific CAPWAP Control Messages . . . . . . . . . 14 3. IEEE 802.11 Specific CAPWAP Control Messages . . . . . . . . . 15
3.1. IEEE 802.11 WLAN Configuration Request . . . . . . . . . . 14 3.1. IEEE 802.11 WLAN Configuration Request . . . . . . . . . . 15
3.2. IEEE 802.11 WLAN Configuration Response . . . . . . . . . 15 3.2. IEEE 802.11 WLAN Configuration Response . . . . . . . . . 16
4. CAPWAP Data Message Bindings . . . . . . . . . . . . . . . . . 16 4. CAPWAP Data Message Bindings . . . . . . . . . . . . . . . . . 17
5. CAPWAP Control Message bindings . . . . . . . . . . . . . . . 18 5. CAPWAP Control Message bindings . . . . . . . . . . . . . . . 19
5.1. Discovery Request Message . . . . . . . . . . . . . . . . 18 5.1. Discovery Request Message . . . . . . . . . . . . . . . . 19
5.2. Primary Discovery Request Message . . . . . . . . . . . . 18 5.2. Primary Discovery Request Message . . . . . . . . . . . . 19
5.3. Join Request Request Message . . . . . . . . . . . . . . . 18 5.3. Join Request Request Message . . . . . . . . . . . . . . . 19
5.4. Configuration Status Message . . . . . . . . . . . . . . . 18 5.4. Configuration Status Message . . . . . . . . . . . . . . . 19
5.5. Configuration Status Response Message . . . . . . . . . . 19 5.5. Configuration Status Response Message . . . . . . . . . . 20
5.6. Configuration Update Request Message . . . . . . . . . . . 19 5.6. Configuration Update Request Message . . . . . . . . . . . 20
5.7. Station Configuration Request . . . . . . . . . . . . . . 20 5.7. Station Configuration Request . . . . . . . . . . . . . . 21
5.8. WTP Event Request . . . . . . . . . . . . . . . . . . . . 20 5.8. WTP Event Request . . . . . . . . . . . . . . . . . . . . 21
6. IEEE 802.11 Message Element Definitions . . . . . . . . . . . 21 6. IEEE 802.11 Message Element Definitions . . . . . . . . . . . 22
6.1. IEEE 802.11 Add WLAN . . . . . . . . . . . . . . . . . . . 21 6.1. IEEE 802.11 Add WLAN . . . . . . . . . . . . . . . . . . . 22
6.2. IEEE 802.11 Antenna . . . . . . . . . . . . . . . . . . . 25 6.2. IEEE 802.11 Antenna . . . . . . . . . . . . . . . . . . . 26
6.3. IEEE 802.11 Assigned WTP BSSID . . . . . . . . . . . . . . 26 6.3. IEEE 802.11 Assigned WTP BSSID . . . . . . . . . . . . . . 27
6.4. IEEE 802.11 Delete WLAN . . . . . . . . . . . . . . . . . 27 6.4. IEEE 802.11 Delete WLAN . . . . . . . . . . . . . . . . . 28
6.5. IEEE 802.11 Direct Sequence Control . . . . . . . . . . . 27 6.5. IEEE 802.11 Direct Sequence Control . . . . . . . . . . . 28
6.6. IEEE 802.11 Information Element . . . . . . . . . . . . . 28 6.6. IEEE 802.11 Information Element . . . . . . . . . . . . . 29
6.7. IEEE 802.11 MAC Operation . . . . . . . . . . . . . . . . 29 6.7. IEEE 802.11 MAC Operation . . . . . . . . . . . . . . . . 30
6.8. IEEE 802.11 MIC Countermeasures . . . . . . . . . . . . . 31 6.8. IEEE 802.11 MIC Countermeasures . . . . . . . . . . . . . 32
6.9. IEEE 802.11 Multi-Domain Capability . . . . . . . . . . . 31 6.9. IEEE 802.11 Multi-Domain Capability . . . . . . . . . . . 32
6.10. IEEE 802.11 OFDM Control . . . . . . . . . . . . . . . . . 32 6.10. IEEE 802.11 OFDM Control . . . . . . . . . . . . . . . . . 33
6.11. IEEE 802.11 Rate Set . . . . . . . . . . . . . . . . . . . 33 6.11. IEEE 802.11 Rate Set . . . . . . . . . . . . . . . . . . . 34
6.12. IEEE 802.11 RSNA Error Report From Station . . . . . . . . 34 6.12. IEEE 802.11 RSNA Error Report From Station . . . . . . . . 35
6.13. IEEE 802.11 Station . . . . . . . . . . . . . . . . . . . 36 6.13. IEEE 802.11 Station . . . . . . . . . . . . . . . . . . . 37
6.14. IEEE 802.11 Station QoS Profile . . . . . . . . . . . . . 37 6.14. IEEE 802.11 Station QoS Profile . . . . . . . . . . . . . 38
6.15. IEEE 802.11 Station Session Key . . . . . . . . . . . . . 37 6.15. IEEE 802.11 Station Session Key . . . . . . . . . . . . . 38
6.16. IEEE 802.11 Statistics . . . . . . . . . . . . . . . . . . 39 6.16. IEEE 802.11 Statistics . . . . . . . . . . . . . . . . . . 40
6.17. IEEE 802.11 Supported Rates . . . . . . . . . . . . . . . 43 6.17. IEEE 802.11 Supported Rates . . . . . . . . . . . . . . . 44
6.18. IEEE 802.11 Tx Power . . . . . . . . . . . . . . . . . . . 43 6.18. IEEE 802.11 Tx Power . . . . . . . . . . . . . . . . . . . 44
6.19. IEEE 802.11 Tx Power Level . . . . . . . . . . . . . . . . 44 6.19. IEEE 802.11 Tx Power Level . . . . . . . . . . . . . . . . 45
6.20. IEEE 802.11 Update Station QoS . . . . . . . . . . . . . . 44 6.20. IEEE 802.11 Update Station QoS . . . . . . . . . . . . . . 45
6.21. IEEE 802.11 Update WLAN . . . . . . . . . . . . . . . . . 45 6.21. IEEE 802.11 Update WLAN . . . . . . . . . . . . . . . . . 46
6.22. IEEE 802.11 WTP Quality of Service . . . . . . . . . . . . 47 6.22. IEEE 802.11 WTP Quality of Service . . . . . . . . . . . . 48
6.23. IEEE 802.11 WTP Radio Configuration . . . . . . . . . . . 48 6.23. IEEE 802.11 WTP Radio Configuration . . . . . . . . . . . 49
6.24. IEEE 802.11 WTP Radio Fail Alarm Indication . . . . . . . 50 6.24. IEEE 802.11 WTP Radio Fail Alarm Indication . . . . . . . 51
6.25. IEEE 802.11 WTP Radio Information . . . . . . . . . . . . 50 6.25. IEEE 802.11 WTP Radio Information . . . . . . . . . . . . 51
7. IEEE 802.11 Binding WTP Saved Variables . . . . . . . . . . . 52 7. IEEE 802.11 Binding WTP Saved Variables . . . . . . . . . . . 53
7.1. IEEE80211AntennaInfo . . . . . . . . . . . . . . . . . . . 52 7.1. IEEE80211AntennaInfo . . . . . . . . . . . . . . . . . . . 53
7.2. IEEE80211DSControl . . . . . . . . . . . . . . . . . . . . 52 7.2. IEEE80211DSControl . . . . . . . . . . . . . . . . . . . . 53
7.3. IEEE80211MACOperation . . . . . . . . . . . . . . . . . . 52 7.3. IEEE80211MACOperation . . . . . . . . . . . . . . . . . . 53
7.4. IEEE80211OFDMControl . . . . . . . . . . . . . . . . . . . 52 7.4. IEEE80211OFDMControl . . . . . . . . . . . . . . . . . . . 53
7.5. IEEE80211Rateset . . . . . . . . . . . . . . . . . . . . . 52 7.5. IEEE80211Rateset . . . . . . . . . . . . . . . . . . . . . 53
7.6. IEEE80211TxPower . . . . . . . . . . . . . . . . . . . . . 52 7.6. IEEE80211TxPower . . . . . . . . . . . . . . . . . . . . . 53
7.7. IEEE80211QoS . . . . . . . . . . . . . . . . . . . . . . . 52 7.7. IEEE80211QoS . . . . . . . . . . . . . . . . . . . . . . . 53
7.8. IEEE80211RadioConfig . . . . . . . . . . . . . . . . . . . 52 7.8. IEEE80211RadioConfig . . . . . . . . . . . . . . . . . . . 53
8. Technology Specific Message Element Values . . . . . . . . . . 53 8. Technology Specific Message Element Values . . . . . . . . . . 54
9. Security Considerations . . . . . . . . . . . . . . . . . . . 54 9. Security Considerations . . . . . . . . . . . . . . . . . . . 55
9.1. IEEE 802.11 Security . . . . . . . . . . . . . . . . . . . 54 9.1. IEEE 802.11 Security . . . . . . . . . . . . . . . . . . . 55
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 55 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 57
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 56 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 58
11.1. Normative References . . . . . . . . . . . . . . . . . . . 56 11.1. Normative References . . . . . . . . . . . . . . . . . . . 58
11.2. Informational References . . . . . . . . . . . . . . . . . 57 11.2. Informational References . . . . . . . . . . . . . . . . . 59
Editors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 58 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 60
Intellectual Property and Copyright Statements . . . . . . . . . . 59 Intellectual Property and Copyright Statements . . . . . . . . . . 61
1. Introduction 1. Introduction
This specification defines the Control And Provisioning of Wireless This specification defines the Control And Provisioning of Wireless
Access Points (CAPWAP) Protocol Binding Specification for use with Access Points (CAPWAP) Protocol Binding Specification for use with
the IEEE 802.11 Wireless Local Area Network (WLAN) protocol. Use of the IEEE 802.11 Wireless Local Area Network (WLAN) protocol. Use of
CAPWAP control message fields, new control messages and message CAPWAP control message fields, new control messages and message
elements are defined. The minimum required definitions for a elements are defined. The minimum required definitions for a
binding-specific Statistics message element, Station message element, binding-specific Statistics message element, Station message element,
and WTP Radio Information message element are included. and WTP Radio Information message element are included.
skipping to change at page 6, line 21 skipping to change at page 6, line 21
2.1. Split MAC and Local MAC Functionality 2.1. Split MAC and Local MAC Functionality
The CAPWAP protocol, when used with IEEE 802.11 devices, requires The CAPWAP protocol, when used with IEEE 802.11 devices, requires
specific behavior from the WTP and the AC, to support the required specific behavior from the WTP and the AC, to support the required
IEEE 802.11 protocol functions. IEEE 802.11 protocol functions.
For both the Split and Local MAC approaches, the CAPWAP functions, as For both the Split and Local MAC approaches, the CAPWAP functions, as
defined in the taxonomy specification [7], reside in the AC. defined in the taxonomy specification [7], reside in the AC.
To provide system component interoperability, the WTP MUST support
802.11 encryption/decryption at the WTP and the WTP MUST support
802.11 encryption/decryption at the AC. The AC MUST support either
(a) 802.11 encryption/decryption at the WTP or (b) 802.11 encryption/
decryption at the AC. The AC MAY support both 802.11 encryption/
decryption at the WTP and 802.11 encryption/decryption at the AC.
2.1.1. Split MAC 2.1.1. Split MAC
This section shows the division of labor between the WTP and the AC This section shows the division of labor between the WTP and the AC
in a Split MAC architecture. Figure 1 shows the separation of in a Split MAC architecture. Figure 1 shows the separation of
functionality between CAPWAP components. functionality between CAPWAP components.
Function Location Function Location
Distribution Service AC Distribution Service AC
Integration Service AC Integration Service AC
Beacon Generation WTP Beacon Generation WTP
skipping to change at page 7, line 30 skipping to change at page 7, line 37
Client WTP AC Client WTP AC
Beacon Beacon
<----------------------------- <-----------------------------
Probe Request Probe Request
----------------------------( - )-------------------------> ----------------------------( - )------------------------->
Probe Response Probe Response
<----------------------------- <-----------------------------
802.11 AUTH/Association 802.11 AUTH/Association
<---------------------------------------------------------> <--------------------------------------------------------->
Station Configuration Request[Add Station (Clear Text, 802.1X)] Station Configuration Request[Add Station (Station Message Elements)]
<-------------------------> <------------------------->
802.1X Authentication & 802.11 Key Exchange 802.1X Authentication & 802.11 Key Exchange
<---------------------------------------------------------> <--------------------------------------------------------->
Station Configuration Request[Add Station (AES-CCMP, PTK=x)] Station Configuration Request[Add Station (AES-CCMP, PTK=x)]
<-------------------------> <------------------------->
802.11 Action Frames 802.11 Action Frames
<---------------------------------------------------------> <--------------------------------------------------------->
802.11 DATA (1) 802.11 DATA (1)
<---------------------------( - )-------------------------> <---------------------------( - )------------------------->
Figure 2: Split MAC Message Flow Figure 2: Split MAC Message Flow
Figure 2 provides an illustration of the division of labor in a Split Figure 2 provides an illustration of the division of labor in a Split
MAC architecture. In this example, a WLAN has been created that is MAC architecture. In this example, a WLAN has been created that is
configured for IEEE 802.11, using AES-CCMP for privacy. The configured for IEEE 802.11, using 802.1X based end user
following process occurs: authentication and AES-CCMP link layer encryption. The following
process occurs:
o The WTP generates the IEEE 802.11 beacon frames, using information o The WTP generates the IEEE 802.11 beacon frames, using information
provided to it through the IEEE 802.11 Add WLAN (see Section 6.1) provided to it through the IEEE 802.11 Add WLAN (see Section 6.1)
message element. message element, including the RSNIE, which indicates support of
802.1X and AES-CCMP.
o The WTP processes the probe request frame and responds with a o The WTP processes the probe request frame and responds with a
corresponding probe response frame. The probe request frame is corresponding probe response frame. The probe request frame is
then forwarded to the AC for optional processing. then forwarded to the AC for optional processing.
o The WTP forwards the IEEEE 802.11 Authentication and Association o The WTP forwards the IEEEE 802.11 Authentication and Association
frames to the AC, which is responsible for responding to the frames to the AC, which is responsible for responding to the
client. client.
o Once the association is complete, the AC transmits a Station o Once the association is complete, the AC transmits a Station
Configuration Request message, which includes an Add Station Configuration Request message, which includes an Add Station
message element, to the WTP (see Section 4.4.8 in [1]). In the message element, to the WTP (see Section 4.4.8 in [1]). In the
above example, the WLAN is configured for IEEE 802.1X, and above example, the WLAN was configured for IEEE 802.1X.
therefore the '802.1X only' policy bit is enabled.
o If the WTP is providing encryption/decryption services, once the o If the WTP is providing encryption/decryption services, once the
client has completed the IEEE 802.11 key exchange, the AC client has completed the IEEE 802.11 key exchange, the AC
transmits another Station Configuration Request message which transmits another Station Configuration Request message which
includes an Add Station message element, an IEEE 802.11 Station includes an Add Station message element, an IEEE 802.11 Station
message element, an IEEE 802.11 Station Session Key message message element, an IEEE 802.11 Station Session Key message
element and an IEEE 802.11 Information Element message element element and an IEEE 802.11 Information Element message element
which includes the RSNIE to the WTP, delivering the security which includes the RSNIE to the WTP, delivering the security
policy to enforce for the station (in this case AES-CCMP), and the policy to enforce for the station (in this case AES-CCMP), and the
encryption key to use. If encryption/decryption is handled in the encryption key to use. If encryption/decryption is handled in the
AC, the IEEE 802.11 Information message element with an RSNIE AC, the IEEE 802.11 Information message element with an RSNIE
would not be included. would not be included.
o The WTP forwards any IEEE 802.11 Management Action frames received o The WTP forwards any IEEE 802.11 Management Action frames received
to the AC. to the AC.
o All IEEE 802.11 station data frames are tunneled between the WTP o All IEEE 802.11 station data frames are tunneled between the WTP
and the AC. and the AC.
The WTP SHALL include the IEEE 802.11 MAC header contents in all
frames transmitted to the AC. When 802.11 encryption/decryption is
performed at the WTP,the WTP SHALL decrypt the uplink frames prior to
transmitting the frames to the AC. The WTP SHALL also add padding,
if necessary, for downlink frames coming from the AC. When 802.11
encryption/decryption is performed at the AC,the WTP SHALL NOT
decrypt the uplink frames prior to transmitting the frames to the AC.
The AC and WTP SHALL populate the IEEE 802.11 MAC header fields as
described in Figure 3.
MAC header field Location
Frame Control:
Version AC
ToDS AC
FromDS AC
Type AC
SubType AC
MoreFrag WTP/AC
Retry WTP
Pwr Mgmt -
MoreData WTP
Protected AC
Order AC
Duration: WTP
Address 1: AC
Address 2: AC
Address 3: AC
Sequence Ctrl: WTP
Address 4: AC
QoS Control: AC
Frame Body: AC
FCS: WTP
Figure 3: Population of the IEEE 802.11 MAC header Fields for
Downlink Frames
When 802.11 encryption/decryption is performed at the AC, the
MoreFrag bit is populated at the AC. The Pwr Mgmt bit is not
applicable to downlink frames, and is set to 0. Note that the FCS
field is not included in 802.11 frames exchanged between the WTP and
the AC. Upon sending data frames to the AC, the WTP is responsible
for validating, and stripping the FCS field. Upon receiving data
frames from the AC, the WTP is responsible for adding the FCS field,
and populating the field as described in [3].
2.1.2. Local MAC 2.1.2. Local MAC
This section shows the division of labor between the WTP and the AC This section shows the division of labor between the WTP and the AC
in a Local MAC architecture. Figure 3 shows the separation of in a Local MAC architecture. Figure 4 shows the separation of
functionality among CAPWAP components. functionality among CAPWAP components.
Function Location Function Location
Distribution Service WTP Distribution Service WTP
Integration Service WTP Integration Service WTP
Beacon Generation WTP Beacon Generation WTP
Probe Response Generation WTP Probe Response Generation WTP
Power Mgmt/Packet Buffering WTP Power Mgmt/Packet Buffering WTP
Fragmentation/Defragmentation WTP Fragmentation/Defragmentation WTP
Assoc/Disassoc/Reassoc WTP Assoc/Disassoc/Reassoc WTP
skipping to change at page 9, line 24 skipping to change at page 10, line 24
IEEE 802.11 QOS IEEE 802.11 QOS
Classifying WTP Classifying WTP
Scheduling WTP Scheduling WTP
Queuing WTP Queuing WTP
IEEE 802.11 RSN IEEE 802.11 RSN
IEEE 802.1X/EAP AC IEEE 802.1X/EAP AC
RSNA Key Management AC RSNA Key Management AC
IEEE 802.11 Encryption/Decryption WTP IEEE 802.11 Encryption/Decryption WTP
Figure 3: Mapping of 802.11 Functions for Local AP Architecture Figure 4: Mapping of 802.11 Functions for Local AP Architecture
Since the Distribution and Integration Services exist on the WTP, Since the Distribution and Integration Services exist on the WTP,
station generated frames are not forwarded to the AC, with the station generated frames are not forwarded to the AC, with the
exception listed in the following paragraphs. exception listed in the following paragraphs.
While the MAC is terminated on the WTP, it is necessary for the AC to While the MAC is terminated on the WTP, it is necessary for the AC to
be aware of mobility events within the WTPs. Thus the WTP MUST be aware of mobility events within the WTPs. Thus the WTP MUST
forward the IEEE 802.11 Association Request frames to the AC. The AC forward the IEEE 802.11 Association Request frames to the AC. The AC
MAY reply with a failed Association Response frame if it deems it MAY reply with a failed Association Response frame if it deems it
necessary, and upon receipt of a failed Association Response frame necessary, and upon receipt of a failed Association Response frame
skipping to change at page 10, line 15 skipping to change at page 11, line 15
Client WTP AC Client WTP AC
Beacon Beacon
<----------------------------- <-----------------------------
Probe Probe
<----------------------------> <---------------------------->
802.11 AUTH 802.11 AUTH
<----------------------------- <-----------------------------
802.11 Association 802.11 Association
<---------------------------( - )-------------------------> <---------------------------( - )------------------------->
Station Configuration Request[Add Station (Clear Text, 802.1X)] Station Configuration Request[Add Station (Station Message Elements)]
<-------------------------> <------------------------->
802.1X Authentication & 802.11 Key Exchange 802.1X Authentication & 802.11 Key Exchange
<---------------------------------------------------------> <--------------------------------------------------------->
802.11 Action Frames 802.11 Action Frames
<---------------------------------------------------------> <--------------------------------------------------------->
Station Configuration Request[Add Station (AES-CCMP, PTK=x)] Station Configuration Request[Add Station (AES-CCMP, PTK=x)]
<-------------------------> <------------------------->
802.11 DATA 802.11 DATA
<-----------------------------> <----------------------------->
Figure 4: Local MAC Message Flow Figure 5: Local MAC Message Flow
Figure 4 provides an illustration of the division of labor in a Local Figure 5 provides an illustration of the division of labor in a Local
MAC architecture. In this example, a WLAN has been created that is MAC architecture. In this example, a WLAN has been created that is
configured for IEEE 802.11, using AES-CCMP for privacy. The configured for IEEE 802.11, using AES-CCMP for privacy. The
following process occurs: following process occurs:
o The WTP generates the IEEE 802.11 beacon frames, using information o The WTP generates the IEEE 802.11 beacon frames, using information
provided to it through the Add WLAN (see Section 6.1) message provided to it through the Add WLAN (see Section 6.1) message
element. element.
o The WTP processes a probe request frame and responds with a o The WTP processes a probe request frame and responds with a
corresponding probe response frame. corresponding probe response frame.
skipping to change at page 11, line 32 skipping to change at page 12, line 32
or 802.11 frame tunnel mode. or 802.11 frame tunnel mode.
2.2. Roaming Behavior 2.2. Roaming Behavior
This section expands upon the examples provided in the previous This section expands upon the examples provided in the previous
section, and describes how the CAPWAP control protocol is used to section, and describes how the CAPWAP control protocol is used to
provide secure roaming. provide secure roaming.
Once a client has successfully associated with the network in a Once a client has successfully associated with the network in a
secure fashion, it is likely to attempt to roam to another WTP. secure fashion, it is likely to attempt to roam to another WTP.
Figure 5 shows an example of a currently associated station moving Figure 6 shows an example of a currently associated station moving
from its "Old WTP" to a "new WTP". The figure is valid for multiple from its "Old WTP" to a "new WTP". The figure is valid for multiple
different security policies, including IEEE 802.1X and WPA or WPA2, different security policies, including IEEE 802.1X and WPA or WPA2,
both with key caching (where the IEEE 802.1x exchange would be both with key caching (where the IEEE 802.1x exchange would be
bypassed) and without. bypassed) and without.
Client Old WTP WTP AC Client Old WTP WTP AC
Association Request/Response Association Request/Response
<--------------------------------------( - )--------------> <--------------------------------------( - )-------------->
Station Configuration Request[Add Station (Clear Text, 802.1X)] Station Configuration Request[Add Station (Station Message Elements)]
<----------------> <---------------->
802.1X Authentication (if no key cache entry exists) 802.1X Authentication (if no key cache entry exists)
<--------------------------------------( - )--------------> <--------------------------------------( - )-------------->
802.11 4-way Key Exchange 802.11 4-way Key Exchange
<--------------------------------------( - )--------------> <--------------------------------------( - )-------------->
Station Configuration Request[Delete Station] Station Configuration Request[Delete Station]
<----------------------------------> <---------------------------------->
Station Configuration Request[Add Station (AES-CCMP, PTK=x)] Station Configuration Request[Add Station (AES-CCMP, PTK=x)]
<----------------> <---------------->
Figure 5: Client Roaming Example Figure 6: Client Roaming Example
2.3. Group Key Refresh 2.3. Group Key Refresh
Periodically, the Group Key (GTK)for the BSS needs to be updated. Periodically, the Group Key (GTK)for the BSS needs to be updated.
The AC uses an EAPOL-Key frame to update the group key for each STA The AC uses an EAPOL-Key frame to update the group key for each STA
in the BSS. While the AC is updating the GTK, each L2 broadcast in the BSS. While the AC is updating the GTK, each L2 broadcast
frame transmitted to the BSS needs to be duplicated and transmitted frame transmitted to the BSS needs to be duplicated and transmitted
using both the current GTK and the new GTK. Once the GTK update using both the current GTK and the new GTK. Once the GTK update
process has completed, broadcast frames transmitted to the BSS will process has completed, broadcast frames transmitted to the BSS will
be encrypted using the new GTK. be encrypted using the new GTK.
skipping to change at page 12, line 48 skipping to change at page 13, line 48
IEEE 802.11 WLAN Configuration Request ( Update WLAN (GTK, GTK Index, GTK Start, Group TSC) ) IEEE 802.11 WLAN Configuration Request ( Update WLAN (GTK, GTK Index, GTK Start, Group TSC) )
<---------------------------------------------- <----------------------------------------------
802.1X EAPoL (GTK Message 1) 802.1X EAPoL (GTK Message 1)
<-------------( - )------------------------------------------- <-------------( - )-------------------------------------------
802.1X EAPoL (GTK Message 2) 802.1X EAPoL (GTK Message 2)
-------------( - )-------------------------------------------> -------------( - )------------------------------------------->
IEEE 802.11 WLAN Configuration Request ( Update WLAN (GTK Index, GTK Complete) ) IEEE 802.11 WLAN Configuration Request ( Update WLAN (GTK Index, GTK Complete) )
<--------------------------------------------- <---------------------------------------------
Figure 6: Group Key Update Procedure Figure 7: Group Key Update Procedure
2.4. BSSID to WLAN ID Mapping 2.4. BSSID to WLAN ID Mapping
The CAPWAP protocol binding enables the WTP to assign BSSIDs upon The CAPWAP protocol binding enables the WTP to assign BSSIDs upon
creation of a WLAN (see Section 6.1). While manufacturers are free creation of a WLAN (see Section 6.1). While manufacturers are free
to assign BSSIDs using any arbitrary mechanism, it is advised that to assign BSSIDs using any arbitrary mechanism, it is advised that
where possible the BSSIDs are assigned as a contiguous block. where possible the BSSIDs are assigned as a contiguous block.
When assigned as a block, implementations can still assign any of the When assigned as a block, implementations can still assign any of the
available BSSIDs to any WLAN. One possible method is for the WTP to available BSSIDs to any WLAN. One possible method is for the WTP to
skipping to change at page 20, line 36 skipping to change at page 21, line 36
o Station QoS Profile, see Section 6.14 o Station QoS Profile, see Section 6.14
5.8. WTP Event Request 5.8. WTP Event Request
The following IEEE 802.11 specific message elements may be included The following IEEE 802.11 specific message elements may be included
in the CAPWAP WTP Event Request message. in the CAPWAP WTP Event Request message.
o IEEE 802.11 MIC Countermeasures, see Section 6.8 o IEEE 802.11 MIC Countermeasures, see Section 6.8
o IEEE 802.11 RSNA Error Report From Station, see Section 6.12
o IEEE 802.11 Statistics, see Section 6.16 o IEEE 802.11 Statistics, see Section 6.16
o IEEE 802.11 WTP Radio Fail Alarm Indication, see Section 6.24 o IEEE 802.11 WTP Radio Fail Alarm Indication, see Section 6.24
6. IEEE 802.11 Message Element Definitions 6. IEEE 802.11 Message Element Definitions
The following IEEE 802.11 specific message elements are defined in The following IEEE 802.11 specific message elements are defined in
this section. this section.
IEEE 802.11 Message Element Type Value IEEE 802.11 Message Element Type Value
skipping to change at page 23, line 45 skipping to change at page 24, line 45
accompanied RSN Information Element. In these scenarios, the key accompanied RSN Information Element. In these scenarios, the key
and cipher information is communicated via the Add Station message and cipher information is communicated via the Add Station message
element, see Section 4.4.8 in [1] and the IEEE 802.11 Station element, see Section 4.4.8 in [1] and the IEEE 802.11 Station
Session Key message element, see Section 6.15. Session Key message element, see Section 6.15.
Group TSC A 48-bit value containing the Transmit Sequence Counter Group TSC A 48-bit value containing the Transmit Sequence Counter
for the updated group key. The WTP will set the TSC for for the updated group key. The WTP will set the TSC for
broadcast/multicast frames to this value for the updated group broadcast/multicast frames to this value for the updated group
key. key.
QOS: An 8-bit value specifying the default QoS policy to enforce QOS: An 8-bit value specifying the default QOS policy for the WTP
for station's traffic on this WLAN. to apply to network traffic received for a non-WMM enabled STA.
The following values are supported: The following values are supported:
0 - Best Effort 0 - Best Effort
1 - Video 1 - Video
2 - Voice 2 - Voice
3 - Background 3 - Background
Auth Type: An 8-bit value specifying the supported authentication Auth Type: An 8-bit value specifying the supported authentication
type. type.
The following values are supported: The following values are supported:
0 - Open System 0 - Open System
1 - WEP Shared Key 1 - WEP Shared Key
2 - WPA/WPA2 802.1X
3 - WPA/WPA2 PSK
MAC Mode: This field specifies whether the WTP should support the MAC Mode: This field specifies whether the WTP should support the
WLAN in Local or Split MAC modes. Note that the AC MUST NOT WLAN in Local or Split MAC modes. Note that the AC MUST NOT
request a mode of operation that was not advertised by the WTP request a mode of operation that was not advertised by the WTP
during the discovery process (see Section 4.4.40 in [1]). The during the discovery process (see Section 4.4.40 in [1]). The
following values are supported: following values are supported:
0 - Local-MAC: Service for the WLAN is to be provided in Local 0 - Local-MAC: Service for the WLAN is to be provided in Local
MAC mode. MAC mode.
1 - Split-MAC: Service for the WLAN is to be provided in Split 1 - Split-MAC: Service for the WLAN is to be provided in Split
skipping to change at page 34, line 20 skipping to change at page 35, line 17
Radio ID: An 8-bit value representing the radio to configure. Radio ID: An 8-bit value representing the radio to configure.
Rate Set: The AC generates the Rate Set that the WTP is to include Rate Set: The AC generates the Rate Set that the WTP is to include
in it's Beacon and Probe messages. The length of this field is in it's Beacon and Probe messages. The length of this field is
between 2 and 8 bytes. The value of this field comes from the between 2 and 8 bytes. The value of this field comes from the
IEEE 802.11 dot11OperationalRateSet MIB element (see [3]). IEEE 802.11 dot11OperationalRateSet MIB element (see [3]).
6.12. IEEE 802.11 RSNA Error Report From Station 6.12. IEEE 802.11 RSNA Error Report From Station
The IEEE 802.11 RSN Error Report From Station message element is sent The IEEE 802.11 RSN Error Report From Station message element is used
by an AC to an WTP to send RSN error reports to the AC. The WTP does by a WTP to send RSN error reports to the AC. The WTP does not need
not need to transmit any reports that do not include any failures. to transmit any reports that do not include any failures. The fields
The fields from this message element come from the IEEE 802.11 from this message element come from the IEEE 802.11
Dot11RSNAStatsEntry table, see [3]. Dot11RSNAStatsEntry table, see [3].
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client MAC Address | | Client MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client MAC Address | BSSID | | Client MAC Address | BSSID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BSSID | | BSSID |
skipping to change at page 37, line 15 skipping to change at page 38, line 15
rates to be used with the station, as found in the IEEE 802.11 rates to be used with the station, as found in the IEEE 802.11
dot11OperationalRateSet MIB element (see [3]). dot11OperationalRateSet MIB element (see [3]).
6.14. IEEE 802.11 Station QoS Profile 6.14. IEEE 802.11 Station QoS Profile
The IEEE 802.11 Station QoS Profile message element contains the The IEEE 802.11 Station QoS Profile message element contains the
maximum IEEE 802.11e priority tag that may be used by the station. maximum IEEE 802.11e priority tag that may be used by the station.
Any packet received that exceeds the value encoded in this message Any packet received that exceeds the value encoded in this message
element must either be dropped or tagged using the maximum value element must either be dropped or tagged using the maximum value
permitted by to the user. The priority tag must be between zero (0) permitted by to the user. The priority tag must be between zero (0)
and seven (7). and seven (7). This message element MUST NOT be present without the
IEEE 802.11 Station (see Section 6.13) message element
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address | | MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address | 802.1P Precedence Tag | | MAC Address | 802.1P Precedence Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 1037 for IEEE 802.11 Station QOS Profile Type: 1037 for IEEE 802.11 Station QOS Profile
skipping to change at page 55, line 5 skipping to change at page 55, line 23
CAPWAP protocol does not add any new vulnerabilities. Derived CAPWAP protocol does not add any new vulnerabilities. Derived
session keys between the STA and WTP can be compromised, resulting in session keys between the STA and WTP can be compromised, resulting in
many well-documented attacks. Implementors SHOULD discourage the use many well-documented attacks. Implementors SHOULD discourage the use
of WEP and encourage use of technically sound cryptographic solutions of WEP and encourage use of technically sound cryptographic solutions
such as those in an IEEE 802.11 RSN. such as those in an IEEE 802.11 RSN.
STA authentication is performed using IEEE 802.lX, and consequently STA authentication is performed using IEEE 802.lX, and consequently
EAP. Implementors SHOULD use EAP methods meeting the requirements EAP. Implementors SHOULD use EAP methods meeting the requirements
specified [6]. specified [6].
When used with IEEE 802.11 RSN security, the CAPWAP protocol may
introduce new vulnerabilities, depending on whether the link security
(packet encryption and integrity verification) is provided by the WTP
or the AC. When the link security function is provided by the AC, no
new security concerns are introduced.
However, when the WTP provides link security, a new vulnerability
will exist when the following conditions are true:
o The client is not the first to associate to the WTP/ESSID (i.e.
other clients are associated), and a GTK already exists
o traffic has been broadcast under the existing GTK
Under these circumstances, the receive sequence counter (KeyRSC)
associated with the GTK is non-zero, but because the AC anchors the
4-way handshake with the client, the exact value of the KeyRSC is not
known when the AC constructs the message containing the GTK. The
client will update its Key RSC value to the current valid KeyRSC upon
receipt of a valid multicast/broadcast message, but prior to this,
previous multicast/broadcast traffic which was secured with the
existing GTK may be replayed, and the client will accept this traffic
as valid.
Typically, busy networks will produce numerous multicast or broadcast
frames per second, so the window of opportunity with respect to such
replay is expected to be very small. In most conditions, it is
expected that replayed frames could be detected (and logged) by the
WTP.
The only way to completely close this window is to provide the exact
KeyRSC value in message 3 of the 4-way handshake; any other approach
simply narrows the window to varying degrees. Given the low relative
threat level this presents, the additional complexity introduced by
providing the exact KeyRSC value is not warranted. That is, this
specification provides for a calculated risk in this regard.
The AC SHOULD use an RSC of 0 when computing message-3 of the 4-way
802.11i handshake, unless the AC has knowledge of a more optimal RSC
value to use. Mechanisms for determining a more optimal RSC value
are outside the scope of this specification.
10. IANA Considerations 10. IANA Considerations
There are no IANA Considerations. There are no IANA Considerations.
11. References 11. References
11.1. Normative References 11.1. Normative References
[1] "draft-ietf-capwap-protocol-specification-03". [1] "draft-ietf-capwap-protocol-specification-03".
skipping to change at page 58, line 5 skipping to change at page 60, line 5
[9] Manner, J. and M. Kojo, "Mobility Related Terminology", [9] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004. RFC 3753, June 2004.
[10] Rescorla et al, E., "Datagram Transport Layer Security", [10] Rescorla et al, E., "Datagram Transport Layer Security",
June 2004. June 2004.
11.2. Informational References 11.2. Informational References
[11] "WiFi Protected Access (WPA) rev 1.6", April 2003. [11] "WiFi Protected Access (WPA) rev 1.6", April 2003.
Editors' Addresses Authors' Addresses
Pat R. Calhoun Pat R. Calhoun
Cisco Systems, Inc. Cisco Systems, Inc.
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
Phone: +1 408-853-5269 Phone: +1 408-853-5269
Email: pcalhoun@cisco.com Email: pcalhoun@cisco.com
Michael P. Montemurro Michael P. Montemurro
skipping to change at page 59, line 7 skipping to change at page 61, line 7
Dorothy Stanley Dorothy Stanley
Aruba Networks Aruba Networks
1322 Crossman Ave 1322 Crossman Ave
Sunnyvale, CA 94089 Sunnyvale, CA 94089
Phone: +1 630-363-1389 Phone: +1 630-363-1389
Email: dstanley@arubanetworks.com Email: dstanley@arubanetworks.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
 End of changes. 31 change blocks. 
101 lines changed or deleted 195 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/