RFC 5412
Lightweight Access Point Protocol
8. Device Management Operations
This section defines LWAPP operations responsible for debugging, gathering statistics, logging, and firmware management.8.1. Image Data Request
The Image Data Request is used to update firmware on the WTP. This message and its companion response are used by the AC to ensure that the image being run on each WTP is appropriate. Image Data Requests are exchanged between the WTP and the AC to download a new program image to a WTP. When a WTP or AC receives an Image Data Request, it will respond with
an Image Data Response. The format of the Image Data and Image Download message elements are described in the following subsections.8.1.1. Image Download
The Image Download message element is sent by the WTP to the AC and contains the image filename. The value is a variable-length byte string. The string is NOT zero terminated.8.1.2. Image Data
The Image Data message element is present when sent by the AC and contains the following fields. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opcode | Checksum | Image Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Image Data ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 33 for Image Data Length: >= 5 Opcode: An 8-bit value representing the transfer opcode. The following values are supported: 3 - Image Data is included. 5 - An error occurred. Transfer is aborted. Checksum: A 16-bit value containing a checksum of the Image Data that follows. Image Data: The Image Data field contains 1024 characters, unless the payload being sent is the last one (end of file).
8.2. Image Data Response
The Image Data Response acknowledges the Image Data Request. An Image Data Responses is sent in response to an Image Data Request. Its purpose is to acknowledge the receipt of the Image Data Request packet. The Image Data Response carries no message elements. No action is necessary on receipt.8.3. Reset Request
The Reset Request is used to cause a WTP to reboot. Reset Requests are sent by an AC to cause a WTP to reinitialize its operation. The Reset Request carries no message elements. When a WTP receives a Reset Request it will respond with a Reset Response and then reinitialize itself.8.4. Reset Response
The Reset Response acknowledges the Reset Request. Reset Responses are sent by a WTP after receiving a Reset Request. The Reset Response carries no message elements. Its purpose is to acknowledge the receipt of the Reset Request. When an AC receives a Reset Response, it is notified that the WTP will now reinitialize its operation.8.5. WTP Event Request
The WTP Event Request is used by a WTP to send information to its AC. These types of events may be periodical, or some asynchronous event on the WTP. For instance, a WTP collects statistics and uses the WTP Event Request to transmit this information to the AC. When an AC receives a WTP Event Request, it will respond with a WTP Event Request.
The WTP Event Request message MUST contain one of the following message element described in the next subsections, or a message element that is defined for a specific technology.8.5.1. Decryption Error Report
The Decryption Error Report message element value is used by the WTP to inform the AC of decryption errors that have occurred since the last report. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Radio ID |Num Of Entries | Mobile MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mobile MAC Address[] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 39 for Decryption Error Report Length: >= 8 Radio ID: The Radio Identifier, typically refers to some interface index on the WTP. Num Of Entries: An 8-bit unsigned integer indicating the number of mobile MAC addresses. Mobile MAC Address: An array of mobile station MAC addresses that have caused decryption errors.8.5.2. Duplicate IPv4 Address
The Duplicate IPv4 Address message element is used by a WTP to inform an AC that it has detected another host using the same IP address it is currently using. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 77 for Duplicate IPv4 Address
Length: 10 IP Address: The IP address currently used by the WTP. MAC Address: The MAC address of the offending device.8.5.3. Duplicate IPv6 Address
The Duplicate IPv6 Address message element is used by a WTP to inform an AC that it has detected another host using the same IP address it is currently using. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 77 for Duplicate IPv6 Address Length: 10 IP Address: The IP address currently used by the WTP. MAC Address: The MAC address of the offending device.8.6. WTP Event Response
The WTP Event Response acknowledges the WTP Event Request. WTP Event Responses are sent by an AC after receiving a WTP Event Request. The WTP Event Response carries no message elements.
8.7. Data Transfer Request
The Data Transfer Request is used to upload debug information from the WTP to the AC. Data Transfer Requests are sent by the WTP to the AC when it determines that it has important information to send to the AC. For instance, if the WTP detects that its previous reboot was caused by a system crash, it would want to send the crash file to the AC. The remote debugger function in the WTP also uses the Data Transfer Request in order to send console output to the AC for debugging purposes. When an AC receives a Data Transfer Request, it will respond with a Data Transfer Response. The AC may log the information received as it sees fit. The Data Transfer Request message MUST contain ONE of the following message element described in the next subsection.8.7.1. Data Transfer Mode
The Data Transfer Mode message element is used by the AC to request information from the WTP for debugging purposes. 0 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | Data Type | +-+-+-+-+-+-+-+-+ Type: 52 for Data Transfer Mode Length: 1 Data Type: An 8-bit value describing the type of information being requested. The following values are supported: 1 - WTP Crash Data 2 - WTP Memory Dump8.7.2. Data Transfer Data
The Data Transfer Data message element is used by the WTP to provide information to the AC for debugging purposes.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Type | Data Length | Data ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 53 for Data Transfer Data
Length: >= 3
Data Type: An 8-bit value describing the type of information being
sent. The following values are supported:
1 - WTP Crash Data
2 - WTP Memory Dump
Data Length: Length of data field.
Data: Debug information.
8.8. Data Transfer Response
The Data Transfer Response acknowledges the Data Transfer Request.
A Data Transfer Response is sent in response to a Data Transfer
Request. Its purpose is to acknowledge the receipt of the Data
Transfer Request packet.
The Data Transfer Response carries no message elements.
Upon receipt of a Data Transfer Response, the WTP transmits more
information, if any is available.
9. Mobile Session Management
Messages in this section are used by the AC to create, modify, or
delete mobile station session state on the WTPs.
9.1. Mobile Config Request
The Mobile Config Request message is used to create, modify, or
delete mobile session state on a WTP. The message is sent by the AC
to the WTP, and may contain one or more message elements. The
message elements for this LWAPP control message include information that is generally highly technology-specific. Therefore, please refer to the appropriate binding section or document for the definitions of the messages elements that may be used in this control message. This section defines the format of the Delete Mobile message element, since it does not contain any technology-specific information.9.1.1. Delete Mobile
The Delete Mobile message element is used by the AC to inform a WTP that it should no longer provide service to a particular mobile station. The WTP must terminate service immediately upon receiving this message element. The transmission of a Delete Mobile message element could occur for various reasons, including administrative reasons, as a result of the fact that the mobile has roamed to another WTP, etc. Once access has been terminated for a given station, any future packets received from the mobile must result in a deauthenticate message, as specified in [6]. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Radio ID | MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 30 for Delete Mobile Length: 7 Radio ID: An 8-bit value representing the radio MAC Address: The mobile station's MAC address9.2. Mobile Config Response
The Mobile Configuration Response is used to acknowledge a previously received Mobile Configuration Request, and includes a Result Code message element that indicates whether an error occurred on the WTP. This message requires no special processing and is only used to acknowledge the Mobile Configuration Request.
The Data Transfer Request message MUST contain the message elements described in the next subsection.9.2.1. Result Code
The Result Code message element is defined in Section 6.2.1.10. LWAPP Security
Note: This version only defines a certificate and a shared-secret- based mechanism to secure control LWAPP traffic exchanged between the WTP and the AC.10.1. Securing WTP-AC Communications
While it is generally straightforward to produce network installations in which the communications medium between the WTP and AC is not accessible to the casual user (e.g., these LAN segments are isolated, and no RJ45 or other access ports exist between the WTP and the AC), this will not always be the case. Furthermore, a determined attacker may resort to various, more sophisticated monitoring and/or access techniques, thereby compromising the integrity of this connection. In general, a certain level of threat on the local (wired) LAN is expected and accepted in most computing environments. That is, it is expected that in order to provide users with an acceptable level of service and maintain reasonable productivity levels, a certain amount of risk must be tolerated. It is generally believed that a certain perimeter is maintained around such LANs, that an attacker must have access to the building(s) in which such LANs exist, and that they must be able to "plug in" to the LAN in order to access the network. With these things in mind, we can begin to assess the general security requirements for AC-WTP communications. While an in-depth security analysis of threats and risks to these communications is beyond the scope of this document, some discussion of the motivation for various security-related design choices is useful. The assumptions driving the security design thus far include the following: o WTP-AC communications take place over a wired connection that may be accessible to a sophisticated attacker. o access to this connection is not trivial for an outsider (i.e., someone who does not "belong" in the building) to access.
o if authentication and/or privacy of end-to-end traffic for which
the WTP and AC are intermediaries is required, this may be
provided via IPsec [14].
o privacy and authentication for at least some WTP-AC control
traffic is required (e.g., Wired Equivalent Privacy (WEP) keys for
user sessions, passed from the AC to the WTP).
o the AC can be trusted to generate strong cryptographic keys.
The AC-WTP traffic can be considered to consist of two types: data
traffic (e.g., to or from an end user), and control traffic, which is
strictly between the AC and WTP. Since data traffic may be secured
using IPsec (or some other end-to-end security mechanism), we confine
our solution to control traffic. The resulting security consists of
two components: an authenticated key exchange and control traffic
security encapsulation. The security encapsulation is accomplished
using AES-CCM, described in [3]. This encapsulation provides for
strong AES-based authentication and encryption [2]. The exchange of
cryptographic keys used for CCM is described below.
10.2. LWAPP Frame Encryption
While the LWAPP protocol uses AES-CCM to encrypt control traffic, it
is important to note that not all control frames are encrypted. The
LWAPP discovery and join phase are not encrypted. The Discovery
messages are sent in the clear since there does not exist a security
association between the WTP and the AC during the discovery phase.
The join phase is an authenticated exchange used to negotiate
symmetric session keys (see Section 10.3).
Once the join phase has been successfully completed, the LWAPP state
machine Figure 2 will move to the Configure state, at which time all
LWAPP control frames are encrypted using AES-CCM.
Encryption of a control message begins at the Message Element field:
meaning the Msg Type, Seq Num, Msg Element Length, and Session ID
fields are left intact (see Section 4.2.1).
The AES-CCM 12-byte authentication data is appended to the end of the
message. The authentication data is calculated from the start of the
LWAPP packet and includes the complete LWAPP control header (see
Section 4.2.1).
The AES-CCM block cipher protocol requires an initialization vector. The LWAPP protocol requires that the WTP and the AC maintain two separate IVs, one for transmission and one for reception. The IV derived during the key exchange phase by both the WTP and the AC is used as the base for all encrypted packets with a new key.10.3. Authenticated Key Exchange
This section describes the key management component of the LWAPP protocol. There are two modes supported by LWAPP: certificate and pre-shared key.10.3.1. Terminology
This section details the key management protocol that makes use of pre-shared secrets. The following notations are used throughout this section: o PSK - the pre-shared key shared between the WTP and the AC. o Kpriv - the private key of a public-private key pair. o Kpub - the public key of the pair. o SessionID - a randomly generated LWAPP session identifier, provided by the WTP in the Join Request. o E-x{Kpub, M} - RSA encryption of M using X's public key. o D-x{Kpriv, C} - RSA decryption of C using X's private key. o AES-CMAC(key, packet) - A message integrity check, using AES-CMAC and key, of the complete LWAPP packet, with the Sequence Number field and the payload of the PSK-MIC message element set to zero. o AES-E(key, plaintext) - Plaintext is encrypted with key, using AES. o AES-D(key, ciphertext) - ciphertext is decrypted with key, using AES. o Certificate-AC - AC's Certificate. o Certificate-WTP - WTP's Certificate. o WTP-MAC - The WTP's MAC address.
o AC-MAC - The AC's MAC address.
o RK0 - the root key, which is created through a Key Derivation
Function (KDF) function.
o RK0E - the root Encryption key, derived from RK0.
o RK0M - the root MIC key, derived from RK0.
o SK1 - the session key.
o SK1C - the session confirmation key, derived from SK.
o SK1E - the session encryption key, derived from SK.
o SK1W - the session keywrap key, derived from SK (see RFC 3394
[9]).
o WNonce - The WTP's randomly generated nonce.
o ANonce - The AC's randomly generated nonce.
o EWNonce - The payload of the WNonce message element, which
includes the WNonce.
o EANonce - The payload of the ANonce message element, which
includes the ANonce.
10.3.2. Initial Key Generation
The AC and WTP accomplish mutual authentication and a cryptographic
key exchange in a dual round trip using the Join Request, Join
Response, Join ACK, and Join Confirm (see Section 6.1).
The following text describes the exchange between the WTP and the AC
that creates a session key, which is used to secure LWAPP control
messages.
o The WTP creates a Join Request using the following process:
o If certificate-based security is used, the WTP adds the
Certificate message element (see Section 6.1.6) with its
contents set to Certificate-WTP.
o The WTP adds the Session ID message element (see Section 6.1.7)
with the contents set to a randomly generated session
identifier (see RFC 1750 [4]). The WTP MUST save the Session
ID in order to validate the Join Response.
o The WTP creates a random nonce, included in the XNonce message
element (see Section 6.1.9). The WTP MUST save the XNonce to
validate the Join Response.
o The WTP transmits the Join Request to the AC.
o Upon receiving the Join Request, the AC uses the following
process:
o The AC creates the Join Response, and ensures that the Session
ID message element matches the value found in the Join Request.
o If certificate-based security is used, the AC:
o adds the Certificate-AC to the Certificate message element.
o creates a random 'AC Nonce' and encrypts it using the
following algorithm E-wtp(Kpub, XNonce XOR 'AC Nonce'). The
encrypted contents are added to the ANonce's message element
payload.
o If a pre-shared-key-based security is used, the AC:
o creates RK0 through the following algorithm: RK0 = KDF-
256{PSK, "LWAPP PSK Top K0" || Session ID || WTP-MAC || AC-
MAC}, where WTP-MAC is the WTP's MAC address in the form
"xx:xx:xx:xx:xx:xx". Similarly, the AC-MAC is an ASCII
encoding of the AC's MAC address, of the form "xx:xx:xx:xx:
xx:xx". The resulting K0 is split into the following:
o The first 16 octets are known as RK0E, and are used as an
encryption key.
o The second 16 octets are known as RK0M, and are used for
MIC'ing purposes.
o The AC creates a random 'AC Nonce' and encrypts it using the
following algorithm: AES-E(RK0E, XNonce XOR 'AC Nonce').
The encrypted contents are added to the ANonce's message
element payload.
o The AC adds a MIC to the contents of the Join Response using
AES-CMAC(RK0M, Join Response) and adds the resulting hash to
the PSK-MIC (Section 6.2.9) message element.
o Upon receiving the Join Response, the WTP uses the following
process:
o If a pre-shared key is used, the WTP authenticates the Join
Response's PSK-MIC message element. If authentication fails,
the packet is dropped.
o The WTP decrypts the ANonce message element and XOR's the value
with XNonce to retrieve the 'AC Nonce'. The ANonce payload is
referred to as ciphertext below:
o If a pre-shared key is used, use AES-D(RK0E, ciphertext).
The 'AC Nonce' is then recovered using XNonce XOR plaintext.
o If certificates are used, use d-wtp(Kpriv, ciphertext). The
'AC Nonce' is then recovered using XNonce XOR plaintext.
o The WTP creates a random 'WTP Nonce'.
o The WTP uses the KDF function to create a 64-octet session key
(SK). The KDF function used is as follows: KDF-512{'WTP Nonce'
|| 'AC Nonce', "LWAPP Key Generation", WTP-MAC || AC-MAC}. The
KDF function is defined in [7].
o SK is then broken down into three separate session keys with
different purposes:
o The first 16 octets are known as SK1C, and are used as a
confirmation key.
o The second 16 octets are known as SK1E, and are as the
encryption key.
o The third 16 octets are known as SK1D, and are used as the
keywrap key.
o The fourth 16 octets are known as IV, and are used as the
Initialization Vector during encryption.
o The WTP creates the Join ACK message.
o If certificate-based security is used, the AC:
o encrypts the 'WTP Nonce' using the following algorithm: E-
ac(Kpub, 'WTP Nonce'). The encrypted contents are added to
the WNonce's message element payload.
o If a pre-shared-key-based security is used, the AC:
o encrypts the 'WTP Nonce' using the following algorithm:
AES-E(RK0E, 'WTP Nonce'). The encrypted contents are added
to the WNonce's message element payload.
o The WTP adds a MIC to the contents of the Join ACK using
AES-CMAC(SK1M, Join ACK) and adds the resulting hash to the
PSK-MIC (Section 6.2.9) message element.
o The WTP then transmits the Join ACK to the AC.
o Upon receiving the Join ACK, the AC uses the following process:
o The AC authenticates the Join ACK through the PSK-MIC message
element. If authentic, the AC decrypts the WNonce message
element to retrieve the 'WTP Nonce'. If the Join ACK cannot be
authenticated, the packet is dropped.
o The AC decrypts the WNonce message element to retrieve the 'WTP
Nonce'. The WNonce payload is referred to as ciphertext below:
o If a pre-shared key is used, use AES-D(RK0E, ciphertext).
The plaintext is then considered the 'WTP Nonce'.
o If certificates are used, use d-ac(Kpriv, ciphertext). The
plaintext is then considered the 'WTP Nonce'.
o The AC then uses the KDF function to create a 64-octet session
key (SK). The KDF function used is as follows: KDF-512{'WTP
Nonce' || 'AC Nonce', "LWAPP Key Generation", WTP-MAC ||
AC-MAC}. The KDF function is defined in [7]. The SK is split
into SK1C, SK1E, SK1D, and IV, as previously noted.
o The AC creates the Join Confirm.
o The AC adds a MIC to the contents of the Join Confirm using
AES-CMAC(SK1M, Join Confirm) and adds the resulting hash to the
MIC (Section 6.2.9) message element.
o The AC then transmits the Join Confirm to the WTP.
o Upon receiving the Join Confirm, the WTP uses the following
process:
o The WTP authenticates the Join Confirm through the PSK-MIC
message element. If the Join Confirm cannot be authenticated,
the packet is dropped.
o SK1E is now plumbed into the AC and WTP's crypto engine as the
AES-CCM LWAPP control encryption session key. Furthermore, the
random IV is used as the base Initialization Vector. From this
point on, all control protocol payloads between the WTP and AC are
encrypted and authenticated using the new session key.
10.3.3. Refreshing Cryptographic Keys
Since AC-WTP associations will tend to be relatively long-lived, it
is sensible to periodically refresh the encryption and authentication
keys; this is referred to as "rekeying". When the key lifetime
reaches 95% of the configured value, identified in the KeyLifetime
timer (see Section 12), the rekeying will proceed as follows:
o The WTP creates RK0 through the previously defined KDF algorithm:
RK0 = KDF-256{SK1D, "LWAPP PSK Top K0" || Session ID || WTP-MAC ||
AC-MAC}. Note that the difference in this specific instance is
that SK1D that was previously generated is used instead of the
PSK. Note this is used in both the certificate and pre-shared key
modes. The resulting RK0 creates RK0E, RK0M.
o The remaining steps used are identical to the join process, with
the exception that the rekey messages are used instead of join
messages, and the fact that the messages are encrypted using the
previously created SK1E. This means the Join Request is replaced
with the Rekey Request, the Join Response is replaced with the
Rekey Response, etc. The two differences between the rekey and
the join process are:
o The Certificate-WTP and Certificate-AC are not included in the
Rekey-Request and Rekey-Response, respectively.
o Regardless of whether certificates or pre-shared keys were used
in the initial key derivation, the process now uses the pre-
shared key mode only, using SK1D as the "PSK".
o The Key Update Request is sent to the AC.
o The newly created SK1E is now plumbed into the AC and WTP's crypto
engine as the AES-CCM LWAPP control encryption session key.
Furthermore, the new random IV is used as the base Initialization
Vector. From this point on, all control protocol payloads between
the WTP and AC are encrypted and authenticated using the new
session key.
If either the WTP or the AC do not receive an expected response by
the time the ResponseTimeout timer expires (see Section 12), the
WTP MUST delete the new and old session information, and reset the
state machine to the Idle state.
Following a rekey process, both the WTP and the AC keep the
previous encryption for 5-10 seconds in order to be able to
process packets that arrive out of order.
10.4. Certificate Usage
Validation of the certificates by the AC and WTP is required so that
only an AC may perform the functions of an AC and that only a WTP may
perform the functions of a WTP. This restriction of functions to the
AC or WTP requires that the certificates used by the AC MUST be
distinguishable from the certificate used by the WTP. To accomplish
this differentiation, the x.509v3 certificates MUST include the
Extensions field [10] and MUST include the NetscapeComment [11]
extension.
For an AC, the value of the NetscapeComment extension MUST be the
string "CAPWAP AC Device Certificate". For a WTP, the value of the
NetscapeComment extension MUST be the string "CAPWAP WTP Device
Certificate".
Part of the LWAPP certificate validation process includes ensuring
that the proper string is included in the NetscapeComment extension,
and only allowing the LWAPP session to be established if the
extension does not represent the same role as the device validating
the certificate. For instance, a WTP MUST NOT accept a certificate
whose NetscapeComment field is set to "CAPWAP WTP Device
Certificate".
11. IEEE 802.11 Binding
This section defines the extensions required for the LWAPP protocol
to be used with the IEEE 802.11 protocol.
11.1. Division of Labor
The LWAPP protocol, when used with IEEE 802.11 devices, requires a
specific behavior from the WTP and the AC, specifically in terms of
which 802.11 protocol functions are handled.
For both the Split and Local MAC approaches, the CAPWAP functions, as
defined in the taxonomy specification, reside in the AC.
11.1.1. Split MAC
This section shows the division of labor between the WTP and the AC in a Split MAC architecture. Figure 3 shows the clear separation of functionality among LWAPP components. Function Location Distribution Service AC Integration Service AC Beacon Generation WTP Probe Response WTP Power Mgmt/Packet Buffering WTP Fragmentation/Defragmentation WTP Assoc/Disassoc/Reassoc AC 802.11e Classifying AC Scheduling WTP/AC Queuing WTP 802.11i 802.1X/EAP AC Key Management AC 802.11 Encryption/Decryption WTP or AC Figure 3: Mapping of 802.11 Functions for Split MAC Architecture The Distribution and Integration services reside on the AC, and therefore all user data is tunneled between the WTP and the AC. As noted above, all real-time 802.11 services, including the control protocol and the beacon and Probe Response frames, are handled on the WTP. All remaining 802.11 MAC management frames are supported on the AC, including the Association Request, which allows the AC to be involved in the access policy enforcement portion of the 802.11 protocol. The 802.1X and 802.11i key management function are also located on the AC. While the admission control component of 802.11e resides on the AC, the real-time scheduling and queuing functions are on the WTP. Note that this does not exclude the AC from providing additional policing and scheduling functionality. Note that in the following figure, the use of '( - )' indicates that processing of the frames is done on the WTP.
Client WTP AC Beacon <----------------------------- Probe Request ----------------------------( - )-------------------------> Probe Response <----------------------------- 802.11 AUTH/Association <---------------------------------------------------------> Add Mobile (Clear Text, 802.1X Only) <-------------------------> 802.1X Authentication & 802.11i Key Exchange <---------------------------------------------------------> Add Mobile (AES-CCMP, PTK=x) <-------------------------> 802.11 Action Frames <---------------------------------------------------------> 802.11 DATA (1) <---------------------------( - )-------------------------> Figure 4: Split MAC Message Flow Figure 4 provides an illustration of the division of labor in a Split MAC architecture. In this example, a WLAN has been created that is configured for 802.11i, using AES-CCMP for privacy. The following process occurs: o The WTP generates the 802.11 beacon frames, using information provided to it through the Add WLAN (see Section 11.8.1.1) message element. o The WTP processes the Probe Request and responds with a corresponding Probe Response. The problem request is then forwarded to the AC for optional processing. o The WTP forwards the 802.11 Authentication and Association frames to the AC, which is responsible for responding to the client. o Once the association is complete, the AC transmits an LWAPP Add Mobile Request to the WTP (see Section 11.7.1.1). In the above example, the WLAN is configured for 802.1X, and therefore the '802.1X only' policy bit is enabled. o If the WTP is providing encryption/decryption services, once the client has completed the 802.11i key exchange, the AC transmits another Add Mobile Request to the WTP, stating the security policy to enforce for the client (in this case AES-CCMP), as well as the
encryption key to use. If encryption/decryption is handled in the
AC, the Add Mobile Request would have the encryption policy set to
"Clear Text".
o The WTP forwards any 802.11 Action frames received to the AC.
o All client data frames are tunneled between the WTP and the AC.
Note that the WTP is responsible for encrypting and decrypting
frames, if it was indicated in the Add Mobile Request.
11.1.2. Local MAC
This section shows the division of labor between the WTP and the AC
in a Local MAC architecture. Figure 5 shows the clear separation of
functionality among LWAPP components.
Function Location
Distribution Service WTP
Integration Service WTP
Beacon Generation WTP
Probe Response WTP
Power Mgmt/Packet Buffering WTP
Fragmentation/Defragmentation WTP
Assoc/Disassoc/Reassoc WTP
802.11e
Classifying WTP
Scheduling WTP
Queuing WTP
802.11i
802.1X/EAP AC
Key Management AC
802.11 Encryption/Decryption WTP
Figure 5: Mapping of 802.11 Functions for Local AP Architecture
Given that Distribution and Integration Services exist on the WTP,
client data frames are not forwarded to the AC, with the exception
listed in the following paragraphs.
While the MAC is terminated on the WTP, it is necessary for the AC to
be aware of mobility events within the WTPs. As a consequence, the
WTP MUST forward the 802.11 Association Requests to the AC, and the
AC MAY reply with a failed Association Response if it deems it
necessary.
The 802.1X and 802.11i Key Management function resides in the AC. Therefore, the WTP MUST forward all 802.1X/Key Management frames to the AC and forward the associated responses to the station. Note that in the following figure, the use of '( - )' indicates that processing of the frames is done on the WTP. Client WTP AC Beacon <----------------------------- Probe <----------------------------> 802.11 AUTH <----------------------------- 802.11 Association <---------------------------( - )-------------------------> Add Mobile (Clear Text, 802.1X Only) <-------------------------> 802.1X Authentication & 802.11i Key Exchange <---------------------------------------------------------> 802.11 Action Frames <---------------------------------------------------------> Add Mobile (AES-CCMP, PTK=x) <-------------------------> 802.11 DATA <-----------------------------> Figure 6: Local MAC Message Flow Figure 6 provides an illustration of the division of labor in a Local MAC architecture. In this example, a WLAN has been created that is configured for 802.11i, using AES-CCMP for privacy. The following process occurs: o The WTP generates the 802.11 beacon frames, using information provided to it through the Add WLAN (see Section 11.8.1.1) message element. o The WTP processes the Probe Request and responds with a corresponding Probe Response. o The WTP forwards the 802.11 Authentication and Association frames to the AC, which is responsible for responding to the client.
o Once the association is complete, the AC transmits an LWAPP Add
Mobile Request to the WTP (see Section 11.7.1.1. In the above
example, the WLAN is configured for 802.1X, and therefore the
'802.1X only' policy bit is enabled.
o The WTP forwards all 802.1X and 802.11i key exchange messages to
the AC for processing.
o The AC transmits another Add Mobile Request to the WTP, stating
the security policy to enforce for the client (in this case, AES-
CCMP), as well as the encryption key to use. The Add Mobile
Request MAY include a VLAN name, which when present is used by the
WTP to identify the VLAN on which the user's data frames are to be
bridged.
o The WTP forwards any 802.11 Action frames received to the AC.
o The WTP locally bridges all client data frames, and provides the
necessary encryption and decryption services.
11.2. Roaming Behavior and 802.11 Security
It is important that LWAPP implementations react properly to mobile
devices associating to the networks in how they generate Add Mobile
and Delete Mobile messages. This section expands upon the examples
provided in the previous section, and describes how the LWAPP control
protocol is used in order to provide secure roaming.
Once a client has successfully associated with the network in a
secure fashion, it is likely to attempt to roam to another access
point. Figure 7 shows an example of a currently associated station
moving from its "Old WTP" to a new "WTP". The figure is useful for
multiple different security policies, including standard 802.1X and
dynamic WEP keys, WPA or even WPA2 both with key caching (where the
802.1x exchange would be bypassed) and without.
Client Old WTP WTP AC Association Request/Response <--------------------------------------( - )--------------> Add Mobile (Clear Text, 802.1X Only) <----------------> 802.1X Authentication (if no key cache entry exists) <--------------------------------------( - )--------------> 802.11i 4-way Key Exchange <--------------------------------------( - )--------------> Delete Mobile <----------------------------------> Add Mobile (AES-CCMP, PTK=x) <----------------> Figure 7: Client Roaming Example11.3. Transport-Specific Bindings
All LWAPP transports have the following IEEE 802.11 specific bindings:11.3.1. Status and WLANS Field
The interpretation of this 16-bit field depends on the direction of transmission of the packet. Refer to the figure in Section 3.1. Status When an LWAPP packet is transmitted from a WTP to an AC, this field is called the Status field and indicates radio resource information associated with the frame. When the message is an LWAPP control message this field is transmitted as zero. The Status field is divided into the signal strength and signal-to- noise ratio with which an IEEE 802.11 frame was received, encoded in the following manner: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RSSI | SNR | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ RSSI: RSSI is a signed, 8-bit value. It is the received signal strength indication, in dBm.
SNR: SNR is a signed, 8-bit value. It is the signal-to-noise ratio
of the received IEEE 802.11 frame, in dB.
WLANs field: When an LWAPP data message is transmitted from an AC
to a WTP, this 16-bit field indicates on which WLANs the
encapsulated IEEE 802.11 frame is to be transmitted. For unicast
packets, this field is not used by the WTP. For broadcast or
multicast packets, the WTP might require this information if it
provides encryption services.
Given that a single broadcast or multicast packet might need to be
sent to multiple wireless LANs (presumably each with a different
broadcast key), this field is defined as a bit field. A bit set
indicates a WLAN ID (see Section 11.8.1.1), which will be sent the
data. The WLANS field is encoded in the following manner:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| WLAN ID(s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
11.4. BSSID to WLAN ID Mapping
The LWAPP protocol makes assumptions regarding the BSSIDs used on the
WTP. It is a requirement for the WTP to use a contiguous block of
BSSIDs. The WLAN Identifier field, which is managed by the AC, is
used as an offset into the BSSID list.
For instance, if a WTP had a base BSSID address of 00:01:02:00:00:00,
and the AC sent an Add WLAN message with a WLAN Identifier of 2 (see
Section 11.8.1.1), the BSSID for the specific WLAN on the WTP would
be 00:01:02:00:00:02.
The WTP communicates the maximum number of BSSIDs that it supports
during the Config Request within the IEEE 802.11 WTP WLAN Radio
Configuration message element (see Section 11.9.1).
11.5. Quality of Service
It is recommended that 802.11 MAC management be sent by both the AC
and the WTP with appropriate Quality-of-Service (QoS) values,
ensuring that congestion in the network minimizes occurrences of
packet loss. Therefore, a QoS-enabled LWAPP device should use:
802.1P: The precedence value of 6 SHOULD be used for all 802.11 MAC
management messages, except for Probe Requests, which SHOULD use
4.
DSCP: The DSCP tag value of 46 SHOULD be used for all 802.11 MAC
management messages, except for Probe Requests, which SHOULD use
34.
11.6. Data Message Bindings
There are no LWAPP data message bindings for IEEE 802.11.
11.7. Control Message Bindings
The IEEE 802.11 binding has the following control message
definitions.
11.7.1. Mobile Config Request
This section contains the 802.11-specific message elements that are
used with the Mobile Config Request.
11.7.1.1. Add Mobile
The Add Mobile Request is used by the AC to inform a WTP that it
should forward traffic from a particular mobile station. The Add
Mobile Request may also include security parameters that must be
enforced by the WTP for the particular mobile.
When the AC sends an Add Mobile Request, it includes any security
parameters that may be required. An AC that wishes to update a
mobile's policy on a WTP may do so by simply sending a new Add Mobile
message element.
When a WTP receives an Add Mobile message element, it must first
override any existing state it may have for the mobile station in
question. The latest Add Mobile overrides any previously received
messages. If the Add Mobile message element's EAP-Only bit is set,
the WTP MUST drop all 802.11 packets that do not contain EAP packets.
Note that when EAP Only is set, the Encryption Policy field MAY have
additional values, and therefore it is possible to inform a WTP to
only accept encrypted EAP packets. Once the mobile station has
successfully completed EAP authentication, the AC must send a new Add
Mobile message element to push the session key down to the WTP as
well as to remove the EAP Only restriction.
If the QoS field is set, the WTP MUST observe and provide policing of
the 802.11e priority tag to ensure that it does not exceed the value
provided by the AC.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | Association ID | MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address |E|C| Encryption Policy |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Encrypt Policy | Session Key... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pairwise TSC... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pairwise RSC... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Capabilities | WLAN ID | WME Mode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 802.11e Mode | Qos | Supported Rates |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Supported Rates |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VLAN Name...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 29 for Add Mobile
Length: 36
Radio ID: An 8-bit value representing the radio.
Association ID: A 16-bit value specifying the 802.11 Association
Identifier.
MAC Address: The mobile station's MAC address.
E: The 1-bit field is set by the AC to inform the WTP that it MUST
NOT accept any 802.11 data frames, other than 802.1X frames. This
is the equivalent of the WTP's 802.1X port for the mobile station
to be in the closed state. When set, the WTP MUST drop any
non-802.1X packets it receives from the mobile station.
C: The 1-bit field is set by the AC to inform the WTP that
encryption services will be provided by the AC. When set, the WTP
SHOULD police frames received from stations to ensure that they
comply to the stated encryption policy, but does not need to take
specific cryptographic action on the frame. Similarly, for
transmitted frames, the WTP only needs to forward already
encrypted frames.
Encryption Policy: The policy field informs the WTP how to handle
packets from/to the mobile station. The following values are
supported:
0 - Encrypt WEP 104: All packets to/from the mobile station must
be encrypted using a standard 104-bit WEP.
1 - Clear Text: All packets to/from the mobile station do not
require any additional crypto processing by the WTP.
2 - Encrypt WEP 40: All packets to/from the mobile station must
be encrypted using a standard 40-bit WEP.
3 - Encrypt WEP 128: All packets to/from the mobile station must
be encrypted using a standard 128-bit WEP.
4 - Encrypt AES-CCMP 128: All packets to/from the mobile station
must be encrypted using a 128-bit AES-CCMP [7].
5 - Encrypt TKIP-MIC: All packets to/from the mobile station must
be encrypted using Temporal Key Integrity Protocol (TKIP) and
authenticated using Michael [16].
Session Key: A 32-octet session key the WTP is to use when
encrypting traffic to or decrypting traffic from the mobile
station. The type of key is determined based on the Encryption
Policy field.
Pairwise TSC: The TKIP Sequence Counter (TSC) to use for unicast
packets transmitted to the mobile.
Pairwise RSC: The Receive Sequence Counter (RSC) to use for unicast
packets received from the mobile.
Capabilities: A 16-bit field containing the 802.11 capabilities to
use with the mobile.
WLAN ID: An 8-bit value specifying the WLAN Identifier.
WME Mode: An 8-bit Boolean used to identify whether the station is
WME capable. A value of zero is used to indicate that the station
is not Wireless Multimedia Extension (WME) capable, while a value
of one means that the station is WME capable.
802.11e Mode: An 8-bit Boolean used to identify whether the station
is 802.11e-capable. A value of zero is used to indicate that the
station is not 802.11e-capable, while a value of one means that
the station is 802.11e-capable.
QoS: An 8-bit value specifying the QoS policy to enforce for the
station. The following values are supported: PRC: TO CHECK
0 - Silver (Best Effort)
1 - Gold (Video)
2 - Platinum (Voice)
3 - Bronze (Background)
Supported Rates: The supported rates to be used with the mobile
station.
VLAN Name: An optional variable string containing the VLAN Name on
which the WTP is to locally bridge user data. Note that this
field is only valid with Local MAC WTPs.
11.7.1.2. IEEE 802.11 Mobile Session Key
The Mobile Session Key Payload message element is sent when the AC
determines that encryption of a mobile station must be performed in
the WTP. This message element MUST NOT be present without the Add
Mobile message element, and MUST NOT be sent if the WTP had not
specifically advertised support for the requested encryption scheme
(see Section 11.7.1.1).
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address | Encryption Policy |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encryption Policy | Session Key... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 105 for IEEE 802.11 Mobile Session Key
Length: >= 11
MAC Address: The mobile station's MAC address.
Encryption Policy: The policy field informs the WTP how to handle
packets from/to the mobile station. The following values are
supported:
0 - Encrypt WEP 104: All packets to/from the mobile station must
be encrypted using a standard 104-bit WEP.
1 - Clear Text: All packets to/from the mobile station do not
require any additional crypto processing by the WTP.
2 - Encrypt WEP 40: All packets to/from the mobile station must
be encrypted using a standard 40-bit WEP.
3 - Encrypt WEP 128: All packets to/from the mobile station must
be encrypted using a standard 128-bit WEP.
4 - Encrypt AES-CCMP 128: All packets to/from the mobile station
must be encrypted using a 128-bit AES-CCMP [7].
5 - Encrypt TKIP-MIC: All packets to/from the mobile station must
be encrypted using TKIP and authenticated using Michael [16].
Session Key: The session key the WTP is to use when encrypting
traffic to/from the mobile station.
11.7.1.3. Station QoS Profile
The Station QoS Profile Payload message element contains the maximum
802.11e priority tag that may be used by the station. Any packets
received that exceed the value encoded in this message element must
either be dropped or tagged using the maximum value permitted to the
user. The priority tag must be between zero (0) and seven (7).
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address | 802.1P Precedence Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 140 for IEEE 802.11 Station QoS Profile
Length: 12
MAC Address: The mobile station's MAC address.
802.1P Precedence Tag: The maximum 802.1P precedence value that the
WTP will allow in the Traffic Identifier (TID) field in the
extended 802.11e QoS Data header.
11.7.1.4. IEEE 802.11 Update Mobile QoS
The Update Mobile QoS message element is used to change the Quality- of-Service policy on the WTP for a given mobile station. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Radio ID | Association ID | MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC Address | QoS Profile | Vlan Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DSCP Tag | 802.1P Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 106 for IEEE 802.11 Update Mobile QoS Length: 14 Radio ID: The Radio Identifier, typically refers to some interface index on the WTP. Association ID: The 802.11 Association Identifier. MAC Address: The mobile station's MAC address. QoS Profile: An 8-bit value specifying the QoS policy to enforce for the station. The following values are supported: 0 - Silver (Best Effort) 1 - Gold (Video) 2 - Platinum (Voice) 3 - Bronze (Background) VLAN Identifier: PRC. DSCP Tag: The DSCP label to use if packets are to be DSCP tagged. 802.1P Tag: The 802.1P precedence value to use if packets are to be 802.1P-tagged.
11.7.2. WTP Event Request
This section contains the 802.11-specific message elements that are used with the WTP Event Request message.11.7.2.1. IEEE 802.11 Statistics
The Statistics message element is sent by the WTP to transmit its current statistics. The value contains the following fields: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Radio ID | Tx Fragment Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Tx Fragment Cnt| Multicast Tx Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mcast Tx Cnt | Failed Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Failed Count | Retry Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Retry Count | Multiple Retry Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Multi Retry Cnt| Frame Duplicate Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Frame Dup Cnt | RTS Success Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |RTS Success Cnt| RTS Failure Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |RTS Failure Cnt| ACK Failure Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |ACK Failure Cnt| Rx Fragment Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Rx Fragment Cnt| Multicast RX Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mcast Rx Cnt | FCS Error Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FCS Error Cnt| Tx Frame Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tx Frame Cnt | Decryption Errors | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Decryption Errs| +-+-+-+-+-+-+-+-+ Type: 38 for Statistics Length: 57
Radio ID: An 8-bit value representing the radio.
Tx Fragment Count: A 32-bit value representing the number of
fragmented frames transmitted.
Multicast Tx Count: A 32-bit value representing the number of
multicast frames transmitted.
Failed Count: A 32-bit value representing the transmit excessive
retries.
Retry Count: A 32-bit value representing the number of transmit
retries.
Multiple Retry Count: A 32-bit value representing the number of
transmits that required more than one retry.
Frame Duplicate Count: A 32-bit value representing the duplicate
frames received.
RTS Success Count: A 32-bit value representing the number of
successfully transmitted Ready To Send (RTS).
RTS Failure Count: A 32-bit value representing the failed
transmitted RTS.
ACK Failure Count: A 32-bit value representing the number of failed
acknowledgements.
Rx Fragment Count: A 32-bit value representing the number of
fragmented frames received.
Multicast RX Count: A 32-bit value representing the number of
multicast frames received.
FCS Error Count: A 32-bit value representing the number of Frame
Check Sequence (FCS) failures.
Decryption Errors: A 32-bit value representing the number of
Decryption errors that occurred on the WTP. Note that this field
is only valid in cases where the WTP provides encryption/
decryption services.
(page 97 continued on part 5)
