tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 5412

 
 
 

Lightweight Access Point Protocol

Part 5 of 5, p. 97 to 125
Prev RFC Part

 


prevText      Top      Up      ToC       Page 97 
11.8.  802.11 Control Messages

   This section will define LWAPP control messages that are specific to
   the IEEE 802.11 binding.

Top      Up      ToC       Page 98 
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:

Top      Up      ToC       Page 99 
       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.

Top      Up      ToC       Page 100 
      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)

Top      Up      ToC       Page 101 
      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:

Top      Up      ToC       Page 102 
       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.

Top      Up      ToC       Page 103 
   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

Top      Up      ToC       Page 104 
   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).

Top      Up      ToC       Page 105 
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                               X

11.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 |
      +-+-+-+-+-+-+-+-+

Top      Up      ToC       Page 106 
   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

Top      Up      ToC       Page 107 
   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

Top      Up      ToC       Page 108 
   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

Top      Up      ToC       Page 109 
      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:

Top      Up      ToC       Page 110 
       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.

Top      Up      ToC       Page 111 
       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:

Top      Up      ToC       Page 112 
       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:

Top      Up      ToC       Page 113 
       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:

Top      Up      ToC       Page 114 
       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      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Top      Up      ToC       Page 115 
   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

Top      Up      ToC       Page 116 
   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.

Top      Up      ToC       Page 117 
   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].

Top      Up      ToC       Page 118 
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: 30

12.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: 60

12.4.  EchoInterval

   The minimum time, in seconds, between sending Echo Requests to the AC
   with which the WTP has joined.

   Default: 30

12.5.  DiscoveryInterval

   The minimum time, in seconds, that a WTP MUST wait after receiving a
   Discovery Response, before sending a Join Request.

   Default: 5

Top      Up      ToC       Page 119 
12.6.  RetransmitInterval

   The minimum time, in seconds, that a non-acknowledged LWAPP packet
   will be retransmitted.

   Default: 3

12.7.  ResponseTimeout

   The minimum time, in seconds, in which an LWAPP Request message must
   be responded to.

   Default: 1

12.8.  KeyLifetime

   The maximum time, in seconds, that an LWAPP session key is valid.

   Default: 28800

13.  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: 10

13.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.

Top      Up      ToC       Page 120 
13.4.  MaxRetransmit

   The maximum number of retransmissions for a given LWAPP packet before
   the link layer considers the peer dead.

   Default: 5

14.  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/

Top      Up      ToC       Page 121 
   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.

Top      Up      ToC       Page 122 
   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.

Top      Up      ToC       Page 123 
   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.

Top      Up      ToC       Page 124 
   [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.

Top      Up      ToC       Page 125 
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