RFC 5412
Lightweight Access Point Protocol
11.8. 802.11 Control Messages
This section will define LWAPP control messages that are specific to the IEEE 802.11 binding.
11.8.1. IEEE 802.11 WLAN Config Request
The IEEE 802.11 WLAN Configuration Request is sent by the AC to the WTP in order to change services provided by the WTP. This control message is used to either create, update, or delete a WLAN on the WTP. The IEEE 802.11 WLAN Configuration Request is sent as a result of either some manual administrative process (e.g., deleting a WLAN), or automatically to create a WLAN on a WTP. When sent automatically to create a WLAN, this control message is sent after the LWAPP Configuration Request message has been received by the WTP. Upon receiving this control message, the WTP will modify the necessary services, and transmit an IEEE 802.11 WLAN Configuration Response. An WTP MAY provide service for more than one WLAN: therefore, every WLAN is identified through a numerical index. For instance, a WTP that is capable of supporting up to 16 SSIDs could accept up to 16 IEEE 802.11 WLAN Configuration Request messages that include the Add WLAN message element. Since the index is the primary identifier for a WLAN, an AC SHOULD attempt to ensure that the same WLAN is identified through the same index number on all of its WTPs. An AC that does not follow this approach MUST find some other means of maintaining a WLAN Identifier to SSID mapping table. The following subsections define the message elements that are of value for this LWAPP operation. Only one message MUST be present.11.8.1.1. IEEE 802.11 Add WLAN
The Add WLAN message element is used by the AC to define a wireless LAN on the WTP. The value contains the following format:
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 | WLAN Capability | WLAN ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encryption Policy |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Index | Shared Key | WPA Data Len |WPA IE Data ...|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RSN Data Len |RSN IE Data ...| Reserved .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| WME Data Len |WME IE Data ...| 11e Data Len |11e IE Data ...|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QoS | Auth Type |Broadcast SSID | Reserved... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSID ... |
+-+-+-+-+-+-+-+-+
Type: 7 for IEEE 802.11 Add WLAN
Length: >= 298
Radio ID: An 8-bit value representing the radio.
WLAN Capability: A 16-bit value containing the capabilities to be
advertised by the WTP within the Probe and Beacon messages.
WLAN ID: A 16-bit value specifying the WLAN Identifier.
Encryption Policy: A 32-bit value specifying the encryption scheme
to apply to traffic to and from 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].
6 - Encrypt CKIP: All packets to/from the mobile station must be
encrypted using Cisco TKIP.
Key: A 32-byte session key to use with the encryption policy.
Key-Index: The Key Index associated with the key.
Shared Key: A 1-byte Boolean that specifies whether the key
included in the Key field is a shared WEP key. A value of zero is
used to state that the key is not a shared WEP key, while a value
of one is used to state that the key is a shared WEP key.
WPA Data Len: Length of the WPA Information Element (IE).
WPA IE: A 32-byte field containing the WPA Information Element.
RSN Data Len: Length of the Robust Security Network (RSN) IE.
RSN IE: A 64-byte field containing the RSN Information Element.
Reserved: A 49-byte reserved field, which MUST be set to zero (0).
WME Data Len: Length of the WME IE.
WME IE: A 32-byte field containing the WME Information Element.
DOT11E Data Len: Length of the 802.11e IE.
DOT11E IE: A 32-byte field containing the 802.11e Information
Element.
QOS: 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)
Auth Type: An 8-bit value specifying the station's authentication
type.
The following values are supported:
0 - Open System
1 - WEP Shared Key
2 - WPA/WPA2 802.1X
3 - WPA/WPA2 PSK
Broadcast SSID: A Boolean indicating whether the SSID is to be
broadcast by the WTP. A value of zero disables SSID broadcast,
while a value of one enables it.
Reserved: A 40-byte reserved field.
SSID: The SSID attribute is the service set identifier that will be
advertised by the WTP for this WLAN.
11.8.1.2. IEEE 802.11 Delete WLAN
The Delete WLAN message element is used to inform the WTP that a
previously created WLAN is to be deleted. The value contains the
following fields:
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 | WLAN ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 28 for IEEE 802.11 Delete WLAN
Length: 3
Radio ID: An 8-bit value representing the radio
WLAN ID: A 16-bit value specifying the WLAN Identifier
11.8.1.3. IEEE 802.11 Update WLAN
The Update WLAN message element is used by the AC to define a
wireless LAN on the WTP. The value contains the following format:
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 | WLAN ID |Encrypt Policy |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encryption Policy | Key... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Index | Shared Key | WLAN Capability |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 34 for IEEE 802.11 Update WLAN
Length: 43
Radio ID: An 8-bit value representing the radio.
WLAN ID: A 16-bit value specifying the WLAN Identifier.
Encryption Policy: A 32-bit value specifying the encryption scheme
to apply to traffic to and from 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].
6 - Encrypt CKIP: All packets to/from the mobile station must be
encrypted using Cisco TKIP.
Key: A 32-byte session key to use with the encryption policy.
Key-Index: The Key Index associated with the key.
Shared Key: A 1-byte Boolean that specifies whether the key
included in the Key field is a shared WEP key. A value of zero
means that the key is not a shared WEP key, while a value of one
is used to state that the key is a shared WEP key.
WLAN Capability: A 16-bit value containing the capabilities to be
advertised by the WTP within the Probe and Beacon messages.
11.8.2. IEEE 802.11 WLAN Config Response
The IEEE 802.11 WLAN Configuration Response is sent by the WTP to the
AC as an acknowledgement of the receipt of an IEEE 802.11 WLAN
Configuration Request.
This LWAPP control message does not include any message elements.
11.8.3. IEEE 802.11 WTP Event
The IEEE 802.11 WTP Event LWAPP message is used by the WTP in order
to report asynchronous events to the AC. There is no reply message
expected from the AC, except that the message is acknowledged via the
reliable transport.
When the AC receives the IEEE 802.11 WTP Event, it will take whatever
action is necessary, depending upon the message elements present in
the message.
The IEEE 802.11 WTP Event message MUST contain one of the following
message elements described in the next subsections.
11.8.3.1. IEEE 802.11 MIC Countermeasures
The MIC Countermeasures message element is sent by the WTP to the AC
to indicate the occurrence of a MIC failure.
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 | WLAN ID | MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 61 for IEEE 802.11 MIC Countermeasures
Length: 8
Radio ID: The Radio Identifier, typically refers to some interface
index on the WTP.
WLAN ID: This 8-bit unsigned integer includes the WLAN Identifier,
on which the MIC failure occurred.
MAC Address: The MAC address of the mobile station that caused the
MIC failure.
11.8.3.2. IEEE 802.11 WTP Radio Fail Alarm Indication
The WTP Radio Fail Alarm Indication message element is sent by the
WTP to the AC when it detects a radio failure.
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 | Type | Status | Pad |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 95 for WTP Radio Fail Alarm Indication
Length: 4
Radio ID: The Radio Identifier, typically refers to some interface
index on the WTP.
Type: The type of radio failure detected. The following values are
supported:
1 - Receiver
2 - Transmitter
Status: An 8-bit Boolean indicating whether the radio failure is
being reported or cleared. A value of zero is used to clear the
event, while a value of one is used to report the event.
Pad: Reserved field MUST be set to zero (0).
11.9. Message Element Bindings
The IEEE 802.11 Message Element binding has the following definitions: Conf Conf Conf Add Req Resp Upd Mobile IEEE 802.11 WTP WLAN Radio Configuration X X X IEEE 802.11 Rate Set X X IEEE 802.11 Multi-domain Capability X X X IEEE 802.11 MAC Operation X X X IEEE 802.11 Tx Power X X X IEEE 802.11 Tx Power Level X IEEE 802.11 Direct Sequence Control X X X IEEE 802.11 OFDM Control X X X IEEE 802.11 Supported Rates X X IEEE 802.11 Antenna X X X IEEE 802.11 CFP Status X X IEEE 802.11 Broadcast Probe Mode X X IEEE 802.11 WTP Mode and Type X? X IEEE 802.11 WTP Quality of Service X X IEEE 802.11 MIC Error Report From Mobile X IEEE 802.11 Update Mobile QoS X IEEE 802.11 Mobile Session Key X11.9.1. IEEE 802.11 WTP WLAN Radio Configuration
The WTP WLAN radio configuration is used by the AC to configure a Radio on the WTP. The message element 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 | Reserved | Occupancy Limit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CFP Per | CFP Maximum Duration | BSS ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BSS ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BSS ID | Beacon Period | DTIM Per | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Country String | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Num Of BSSIDs | +-+-+-+-+-+-+-+-+
Type: 8 for IEEE 802.11 WTP WLAN Radio Configuration
Length: 20
Radio ID: An 8-bit value representing the radio to configure.
Reserved: MUST be set to zero
Occupancy Limit: This attribute indicates the maximum amount of
time, in Time Units (TUs), that a point coordinator MAY control
the usage of the wireless medium without relinquishing control for
long enough to allow at least one instance of Distributed
Coordination Function (DCF) access to the medium. The default
value of this attribute SHOULD be 100, and the maximum value
SHOULD be 1000.
CFP Period: The attribute describes the number of DTIM intervals
between the start of Contention-Free Periods (CFPs).
CFP Maximum Duration: The attribute describes the maximum duration
of the CFP in TU that MAY be generated by the Point Coordination
Function (PCF).
BSSID: The WLAN Radio's base MAC address. For WTPs that support
more than a single WLAN, the value of the WLAN Identifier is added
to the last octet of the BSSID. Therefore, a WTP that supports 16
WLANs MUST have 16 MAC addresses reserved for it, and the last
nibble is used to represent the WLAN ID.
Beacon Period: This attribute specifies the number of TUs that a
station uses for scheduling Beacon transmissions. This value is
transmitted in Beacon and Probe Response frames.
DTIM Period: This attribute specifies the number of Beacon
intervals that elapses between transmission of Beacons frames
containing a TIM element whose DTIM Count field is 0. This value
is transmitted in the DTIM Period field of Beacon frames.
Country Code: This attribute identifies the country in which the
station is operating. The first two octets of this string is the
two-character country code as described in document ISO/IEC 3166-
1. The third octet MUST be one of the following:
1. an ASCII space character, if the regulations under which the
station is operating encompass all environments in the country,
2. an ASCII 'O' character, if the regulations under which the station
is operating are for an outdoor environment only, or
3. an ASCII 'I' character, if the regulations under which the station
is operating are for an indoor environment only.
Number of BSSIDs: This attribute contains the maximum number of
BSSIDs supported by the WTP. This value restricts the number of
logical networks supported by the WTP.
11.9.2. IEEE 802.11 Rate Set
The Rate Set message element value is sent by the AC and contains the
supported operational rates. It 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 | Rate Set |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 16 for IEEE 802.11 Rate Set
Length: 4
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
in its Beacon and Probe messages.
11.9.3. IEEE 802.11 Multi-Domain Capability
The Multi-Domain Capability message element is used by the AC to
inform the WTP of regulatory limits. 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 | Reserved | First Channel # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Channels | Max Tx Power Level |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 10 for IEEE 802.11 Multi-Domain Capability
Length: 8
Radio ID: An 8-bit value representing the radio to configure.
Reserved: MUST be set to zero
First Channel #: This attribute indicates the value of the lowest
channel number in the subband for the associated domain country
string.
Number of Channels: This attribute indicates the value of the total
number of channels allowed in the subband for the associated
domain country string.
Max Tx Power Level: This attribute indicates the maximum transmit
power, in dBm, allowed in the subband for the associated domain
country string.
11.9.4. IEEE 802.11 MAC Operation
The MAC Operation message element is sent by the AC to set the 802.11
MAC parameters on the WTP. 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 | Reserved | RTS Threshold |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Short Retry | Long Retry | Fragmentation Threshold |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tx MSDU Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rx MSDU Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 11 for IEEE 802.11 MAC Operation
Length: 16
Radio ID: An 8-bit value representing the radio to configure.
Reserved: MUST be set to zero
RTS Threshold: This attribute indicates the number of octets in a
Management Protocol Data Unit (MPDU), below which an RTS/CTS
(clear to send) handshake MUST NOT be performed. An RTS/CTS
handshake MUST be performed at the beginning of any frame exchange
sequence where the MPDU is of type Data or Management, the MPDU
has an individual address in the Address1 field, and the length of
the MPDU is greater than this threshold. Setting this attribute
to be larger than the maximum MAC Service Data Unit (MSDU) size
MUST have the effect of turning off the RTS/CTS handshake for
frames of Data or Management type transmitted by this Station
(STA). Setting this attribute to zero MUST have the effect of
turning on the RTS/CTS handshake for all frames of Data or
Management type transmitted by this STA. The default value of
this attribute MUST be 2347.
Short Retry: This attribute indicates the maximum number of
transmission attempts of a frame, the length of which is less than
or equal to RTSThreshold, that MUST be made before a failure
condition is indicated. The default value of this attribute MUST
be 7.
Long Retry: This attribute indicates the maximum number of
transmission attempts of a frame, the length of which is greater
than dot11RTSThreshold, that MUST be made before a failure
condition is indicated. The default value of this attribute MUST
be 4.
Fragmentation Threshold: This attribute specifies the current
maximum size, in octets, of the MPDU that MAY be delivered to the
PHY. An MSDU MUST be broken into fragments if its size exceeds
the value of this attribute after adding MAC headers and trailers.
An MSDU or MAC Management Protocol Data Unit (MMPDU) MUST be
fragmented when the resulting frame has an individual address in
the Address1 field, and the length of the frame is larger than
this threshold. The default value for this attribute MUST be the
lesser of 2346 or the aMPDUMaxLength of the attached PHY and MUST
never exceed the lesser of 2346 or the aMPDUMaxLength of the
attached PHY. The value of this attribute MUST never be less than
256.
Tx MSDU Lifetime: This attribute specifies the elapsed time in TU,
after the initial transmission of an MSDU, after which, further
attempts to transmit the MSDU MUST be terminated. The default
value of this attribute MUST be 512.
Rx MSDU Lifetime: This attribute specifies the elapsed time, in TU,
after the initial reception of a fragmented MMPDU or MSDU, after
which, further attempts to reassemble the MMPDU or MSDU MUST be
terminated. The default value MUST be 512.
11.9.5. IEEE 802.11 Tx Power
The Tx Power message element value is bi-directional. When sent by
the WTP, it contains the current power level of the radio in
question. When sent by the AC, it contains the power level to which
the WTP MUST adhere:
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 | Reserved | Current Tx Power |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 12 for IEEE 802.11 Tx Power
Length: 4
Radio ID: An 8-bit value representing the radio to configure.
Reserved: MUST be set to zero
Current Tx Power: This attribute contains the transmit output power
in mW.
11.9.6. IEEE 802.11 Tx Power Level
The Tx Power Level message element is sent by the WTP and contains
the different power levels supported. 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 | Num Levels | Power Level [n] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 13 for IEEE 802.11 Tx Power Level
Length: >= 4
Radio ID: An 8-bit value representing the radio to configure.
Num Levels: The number of power level attributes.
Power Level: Each power level fields contains a supported power
level, in mW.
11.9.7. IEEE 802.11 Direct Sequence Control
The Direct Sequence Control message element is a bi-directional
element. When sent by the WTP, it contains the current state. When
sent by the AC, the WTP MUST adhere to the values. This element is
only used for 802.11b radios. The value has 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 | Reserved | Current Chan | Current CCA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Energy Detect Threshold |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 14 for IEEE 802.11 Direct Sequence Control
Length: 8
Radio ID: An 8-bit value representing the radio to configure.
Reserved: MUST be set to zero
Current Channel: This attribute contains the current operating
frequency channel of the Direct Sequence Spread Spectrum (DSSS)
PHY.
Current CCA: The current Controlled Channel Access (CCA) method in
operation. Valid values are:
1 - energy detect only (edonly)
2 - carrier sense only (csonly)
4 - carrier sense and energy detect (edandcs)
8 - carrier sense with timer (cswithtimer)
16 - high-rate carrier sense and energy detect (hrcsanded)
Energy Detect Threshold: The current Energy Detect Threshold being
used by the DSSS PHY.
11.9.8. IEEE 802.11 OFDM Control
The Orthogonal Frequency Division Multiplexing (OFDM) Control message
element is a bi-directional element. When sent by the WTP, it
contains the current state. When sent by the AC, the WTP MUST adhere
to the values. This element is only used for 802.11a radios. 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 | Reserved | Current Chan | Band Support |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TI Threshold |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 15 for IEEE 802.11 OFDM Control
Length: 8
Radio ID: An 8-bit value representing the radio to configure.
Reserved: MUST be set to zero
Current Channel: This attribute contains the current operating
frequency channel of the OFDM PHY.
Band Supported: The capability of the OFDM PHY implementation to
operate in the three U-NII bands. Coded as an integer value of a
3-bit field as follows:
Bit 0 - capable of operating in the lower (5.15-5.25 GHz) U-NII
band
Bit 1 - capable of operating in the middle (5.25-5.35 GHz) U-NII
band
Bit 2 - capable of operating in the upper (5.725-5.825 GHz) U-NII
band
For example, for an implementation capable of operating in the
lower and mid bands, this attribute would take the value.
TI Threshold: The threshold being used to detect a busy medium
(frequency). CCA MUST report a busy medium upon detecting the
RSSI above this threshold.
11.9.9. IEEE 802.11 Antenna
The Antenna message element is communicated by the WTP to the AC to
provide information on the antennas available. The AC MAY use this
element to reconfigure the WTP's antennas. 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 | Diversity | Combiner | Antenna Cnt |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Antenna Selection [0..N] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 41 for IEEE 802.11 Antenna
Length: >= 8
Radio ID: An 8-bit value representing the radio to configure.
Diversity: An 8-bit value specifying whether the antenna is to
provide receive diversity. The following values are supported:
0 - Disabled
1 - Enabled (may only be true if the antenna can be used as a
receive antenna)
Combiner: An 8-bit value specifying the combiner selection. The
following values are supported:
1 - Sectorized (Left)
2 - Sectorized (Right)
3 - Omni
4 - Mimo
Antenna Count: An 8-bit value specifying the number of Antenna
Selection fields.
Antenna Selection: One 8-bit antenna configuration value per
antenna in the WTP. The following values are supported:
1 - Internal Antenna
2 - External Antenna
11.9.10. IEEE 802.11 Supported Rates
The Supported Rates message element is sent by the WTP to indicate
the rates that it supports. 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 | Supported Rates |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 16 for IEEE 802.11 Supported Rates
Length: 4
Radio ID: An 8-bit value representing the radio.
Supported Rates: The WTP includes the Supported Rates that its
hardware supports. The format is identical to the Rate Set
message element.
11.9.11. IEEE 802.11 CFP Status
The CFP Status message element is sent to provide the CF Polling
configuration.
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 48 for IEEE 802.11 CFP Status
Length: 2
Radio ID: The Radio Identifier, typically refers to some interface
index on the WTP.
Status: An 8-bit Boolean containing the status of the CF Polling
feature. A value of zero disables CFP Status, while a value of
one enables it.
11.9.12. IEEE 802.11 WTP Mode and Type
The WTP Mode and Type message element is used to configure a WTP to
operate in a specific mode.
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mode | Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 54 for IEEE 802.11 WTP Mode and Type
Length: 2
Mode: An 8-bit value describing the type of information being sent.
The following values are supported:
0 - Split MAC
2 - Local MAC
Type: The type field is not currently used.
11.9.13. IEEE 802.11 Broadcast Probe Mode
The Broadcast Probe Mode message element indicates whether a WTP will
respond to NULL SSID Probe requests. Since broadcast NULL Probes are
not sent to a specific BSSID, the WTP cannot know which SSID the
sending station is querying. Therefore, this behavior must be global
to the WTP.
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Status |
+-+-+-+-+-+-+-+-+
Type: 51 for IEEE 802.11 Broadcast Probe Mode
Length: 1
Status: An 8-bit Boolean indicating the status of whether a WTP
shall respond to a NULL SSID Probe request. A value of zero
disables the NULL SSID Probe response, while a value of one
enables it.
11.9.14. IEEE 802.11 WTP Quality of Service
The WTP Quality of Service message element value is sent by the AC to
the WTP to communicate quality-of-service configuration information.
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | Tag Packets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 57 for IEEE 802.11 WTP Quality of Service
Length: 12
Radio ID: The Radio Identifier, typically refers to some interface
index on the WTP.
Tag Packets: A value indicating whether LWAPP packets should be
tagged for QoS purposes. The following values are currently
supported:
0 - Untagged
1 - 802.1P
2 - DSCP
Immediately following the above header is the following data
structure. This data structure will be repeated five times, once
for every QoS profile. The order of the QoS profiles is Uranium,
Platinum, Gold, Silver, and Bronze.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Queue Depth | CWMin | CWMax |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CWMax | AIFS | CBR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Dot1P Tag | DSCP Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Queue Depth: The number of packets that can be on the specific QoS
transmit queue at any given time.
CWMin: The Contention Window minimum value for the QoS transmit
queue.
CWMax: The Contention Window maximum value for the QoS transmit
queue.
AIFS: The Arbitration Inter Frame Spacing to use for the QoS
transmit queue.
CBR: The Constant Bit Rate (CBR) value to observe for the QoS
transmit queue.
Dot1P Tag: The 802.1P precedence value to use if packets are to be
802.1P tagged.
DSCP Tag: The DSCP label to use if packets are to be DSCP tagged.11.9.15. IEEE 802.11 MIC Error Report From Mobile
The MIC Error Report From Mobile message element is sent by an AC to a WTP when it receives a MIC failure notification via the Error bit in the EAP over LAN (EAPOL)-Key frame. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Client MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Client MAC Address | BSSID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BSSID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Radio ID | WLAN ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 79 for IEEE 802.11 MIC Error Report From Mobile Length: 14 Client MAC Address: The Client MAC address of the station reporting the MIC failure. BSSID: The BSSID on which the MIC failure is being reported. Radio ID: The Radio Identifier, typically refers to some interface index on the WTP. WLAN ID: The WLAN ID on which the MIC failure is being reported.11.10. IEEE 802.11 Message Element Values
This section lists IEEE 802.11-specific values for any generic LWAPP message elements that include fields whose values are technology- specific. IEEE 802.11 uses the following values: 4 - Encrypt AES-CCMP 128: WTP supports AES-CCMP, as defined in [7]. 5 - Encrypt TKIP-MIC: WTP supports TKIP and Michael, as defined in [16].
12. LWAPP Protocol Timers
A WTP or AC that implements LWAPP discovery MUST implement the following timers.12.1. MaxDiscoveryInterval
The maximum time allowed between sending Discovery Requests from the interface, in seconds. Must be no less than 2 seconds and no greater than 180 seconds. Default: 20 seconds.12.2. SilentInterval
The minimum time, in seconds, a WTP MUST wait after failing to receive any responses to its Discovery Requests, before it MAY again send Discovery Requests. Default: 3012.3. NeighborDeadInterval
The minimum time, in seconds, a WTP MUST wait without having received Echo Responses to its Echo Requests, before the destination for the Echo Request may be considered dead. Must be no less than 2*EchoInterval seconds and no greater than 240 seconds. Default: 6012.4. EchoInterval
The minimum time, in seconds, between sending Echo Requests to the AC with which the WTP has joined. Default: 3012.5. DiscoveryInterval
The minimum time, in seconds, that a WTP MUST wait after receiving a Discovery Response, before sending a Join Request. Default: 5
12.6. RetransmitInterval
The minimum time, in seconds, that a non-acknowledged LWAPP packet will be retransmitted. Default: 312.7. ResponseTimeout
The minimum time, in seconds, in which an LWAPP Request message must be responded to. Default: 112.8. KeyLifetime
The maximum time, in seconds, that an LWAPP session key is valid. Default: 2880013. LWAPP Protocol Variables
A WTP or AC that implements LWAPP discovery MUST allow for the following variables to be configured by system management; default values are specified so as to make it unnecessary to configure any of these variables in many cases.13.1. MaxDiscoveries
The maximum number of Discovery Requests that will be sent after a WTP boots. Default: 1013.2. DiscoveryCount
The number of discoveries transmitted by a WTP to a single AC. This is a monotonically increasing counter.13.3. RetransmitCount
The number of retransmissions for a given LWAPP packet. This is a monotonically increasing counter.
13.4. MaxRetransmit
The maximum number of retransmissions for a given LWAPP packet before the link layer considers the peer dead. Default: 514. NAT Considerations
There are two specific situations where a NAT system may be used in conjunction with LWAPP. The first consists of a configuration where the WTP is behind a NAT system. Given that all communication is initiated by the WTP, and all communication is performed over IP using a single UDP port, the protocol easily traverses NAT systems in this configuration. The second configuration is one where the AC sits behind a NAT, and there are two main issues that exist in this situation. First, an AC communicates its interfaces and associated WTP load on these interfaces, through the WTP Manager Control IP Address. This message element is currently mandatory, and if NAT compliance became an issue, it would be possible to either: 1. make the WTP Manager Control IP Address optional, allowing the WTP to simply use the known IP address. However, note that this approach would eliminate the ability to perform load balancing of WTP across ACs, and therefore is not the recommended approach. 2. allow an AC to be able to configure a NAT'ed address for every associated AC that would generally be communicated in the WTP Manager Control IP Address message element. 3. require that if a WTP determines that the AC List message element consists of a set of IP addresses that are different from the AC's IP address it is currently communicating with, then assume that NAT is being enforced, and require that the WTP communicate with the original AC's IP address (and ignore the WTP Manager Control IP Address message element(s)). Another issue related to having an AC behind a NAT system is LWAPP's support for the CAPWAP Objective to allow the control and data plane to be separated. In order to support this requirement, the LWAPP protocol defines the WTP Manager Data IP Address message element, which allows the AC to inform the WTP that the LWAPP data frames are to be forwarded to a separate IP address. This feature MUST be disabled when an AC is behind a NAT. However, there is no easy way to provide some default mechanism that satisfies both the data/
control separation and NAT objectives, as they directly conflict with each other. As a consequence, user intervention will be required to support such networks. LWAPP has a feature that allows for all of the AC's identities supporting a group of WTPs to be communicated through the AC List message element. This feature must be disabled when the AC is behind a NAT and the IP address that is embedded would be invalid. The LWAPP protocol has a feature that allows an AC to configure a static IP address on a WTP. The WTP Static IP Address Information message element provides such a function; however, this feature SHOULD NOT be used in NAT'ed environments, unless the administrator is familiar with the internal IP addressing scheme within the WTP's private network, and does not rely on the public address seen by the AC. When a WTP detects the duplicate address condition, it generates a message to the AC, which includes the Duplicate IP Address message element. Once again, it is important to note that the IP address embedded within this message element would be different from the public IP address seen by the AC.15. Security Considerations
LWAPP uses either an authenticated key exchange or key agreement mechanism to ensure peer authenticity and establish fresh session keys to protect the LWAPP communications. The LWAPP protocol defines a join phase, which allows a WTP to bind a session with an AC. During this process, a session key is mutually derived, and secured either through an X.509 certificate or a pre- shared key. The resulting key exchange generates an encryption session key, which is used to encrypt the LWAPP control packets, and a key derivation key. During the established secure communication, the WTP and AC may rekey using the key update process, which is identical to the join phase, meaning the session keys are mutually derived. However, the exchange described for pre-shared session keys is always used for the key update, with the pre-shared key set to the derivation key created either during the join, or the last key update if one has occurred. The key update results in a new derivation key, which is used in the next key update, as well as an encryption session key to encrypt the LWAPP control packets.
Replay protection of the Join Request is handled through an exchange of nonces during the join (or key update) phase. The Join Request includes an XNonce, which is included in the AC's authenticated Join Reply's encrypted ANonce message element, allowing for the two messages to be bound. Upon receipt of the Join Reply, the WTP generates the WNonce, and generates a set of session keys using a KDF function. One of these keys is used to MIC the Join ACK. The AC responds with a Join Confirm, which must also include a MIC, and therefore be capable of deriving the same set of session keys. In both the X.509 certificate and pre-shared key modes, an initialization vector is created through the above mentioned KDF function. The IV and the KDF created encryption key are used to encrypt the LWAPP control frames. Given that authentication in the Join exchange does not occur until the WTP transmits the Join ACK message, it is crucial that an AC not delete any state for a WTP it is servicing until an authentication Join ACK has been received. Otherwise, a potential Denial-of-Service attack exists, whereby sending a spoofed Join Request for a valid WTP would cause the AC to reset the WTP's connection. It is important to note that Perfect Forward Secrecy is not a requirement for the LWAPP protocol. Note that the LWAPP protocol does not add any new vulnerabilities to 802.11 infrastructure that makes use of WEP for encryption purposes. However, implementors SHOULD discourage the use of WEP to allow the market to move towards technically sound cryptographic solutions, such as 802.11i.15.1. Certificate-Based Session Key Establishment
LWAPP uses public key cryptography to ensure trust between the WTP and the AC. One question that periodically arises is why the Join Request is not signed. Signing this request would not be optimal for the following reasons: 1. The Join Request is replayable, so a signature doesn't provide much protection unless the switches keep track of all previous Join Requests from a given WTP. 2. Replay detection is handled during the Join Reply and Join ACK messages. 3. A signed Join Request provides a potential Denial-of-Service attack on the AC, which would have to authenticate each (potentially malicious) message.
The WTP-Certificate that is included in the Join Request MUST be validated by the AC. It is also good practice that the AC perform some form of authorization, ensuring that the WTP in question is allowed to establish an LWAPP session with it.15.2. PSK-Based Session Key Establishment
Use of a fixed shared secret of limited entropy (for example, a PSK that is relatively short, or was chosen by a human and thus may contain less entropy than its length would imply) may allow an attacker to perform a brute-force or dictionary attack to recover the secret. It is RECOMMENDED that implementations that allow the administrator to manually configure the PSK also provide a functionality for generating a new random PSK, taking RFC 1750 [4] into account. Since the key generation does not expose the nonces in plaintext, there are no practical passive attacks possible.16. Acknowledgements
The authors wish to thank Michael Vakulenko for contributing text that describes how LWAPP can be used over a Layer 3 (IP) network. The authors would also like to thanks Russ Housley and Charles Clancy for their assistance in providing a security review of the LWAPP specification. Charles' review can be found in [12].17. References
17.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] National Institute of Standards and Technology, "Advanced Encryption Standard (AES)", FIPS PUB 197, November 2001, <http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf>. [3] Whiting, D., Housley, R., and N. Ferguson, "Counter with CBC- MAC (CCM)", RFC 3610, September 2003. [4] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005. [5] Manner, J., Ed., and M. Kojo, Ed., "Mobility Related Terminology", RFC 3753, June 2004.
[6] "Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications", IEEE Standard 802.11, 2007, <http://standards.ieee.org/getieee802/download/802.11-2007.pdf> [7] "Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications Amendment 6: Medium Access Control (MAC) Security Enhancements", IEEE Standard 802.11i, July 2004, http://standards.ieee.org/getieee802/download/802.11i-2004.pdf [8] Clark, D., "IP datagram reassembly algorithms", RFC 815, July 1982. [9] Schaad, J. and R. Housley, "Advanced Encryption Standard (AES) Key Wrap Algorithm", RFC 3394, September 2002. [10] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008. [11] "Netscape-Defined Certificate Extensions", <http://www.redhat.com/docs/manuals/cert- system/admin/7.1/app_ext.html#35336>. [12] Clancy, C., "Security Review of the Light-Weight Access Point Protocol", May 2005, <http://www.cs.umd.edu/~clancy/docs/lwapp-review.pdf>.17.2. Informative References
[13] Reynolds, J., Ed., "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", RFC 3232, January 2002. [14] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [15] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997. [16] "WiFi Protected Access (WPA) rev 1.6", April 2003.
Authors' Addresses
Pat R. Calhoun Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 Phone: +1 408-853-5269 EMail: pcalhoun@cisco.com Rohit Suri Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 Phone: +1 408-853-5548 EMail: rsuri@cisco.com Nancy Cam-Winget Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 Phone: +1 408-853-0532 EMail: ncamwing@cisco.com Scott Kelly EMail: scott@hyperthought.com Michael Glenn Williams GWhiz Arts & Sciences 1560 Newbury Road, Suite 1-204 Newbury Park, CA 91320 Phone: +1 805-499-1994 EMail: gwhiz@gwhiz.com Sue Hares Phone: +1 734-604-0332 EMail: shares@ndzh.com Bob O'Hara EMail: bob.ohara@computer.org