tech-invite   World Map     

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

RFC 5412

 
 
 

Lightweight Access Point Protocol

Part 4 of 5, p. 66 to 97
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 66 
8.  Device Management Operations

   This section defines LWAPP operations responsible for debugging,
   gathering statistics, logging, and firmware management.

8.1.  Image Data Request

   The Image Data Request is used to update firmware on the WTP.  This
   message and its companion response are used by the AC to ensure that
   the image being run on each WTP is appropriate.

   Image Data Requests are exchanged between the WTP and the AC to
   download a new program image to a WTP.

   When a WTP or AC receives an Image Data Request, it will respond with

Top      Up      ToC       Page 67 
   an Image Data Response.

   The format of the Image Data and Image Download message elements are
   described in the following subsections.

8.1.1.  Image Download

   The Image Download message element is sent by the WTP to the AC and
   contains the image filename.  The value is a variable-length byte
   string.  The string is NOT zero terminated.

8.1.2.  Image Data

   The Image Data message element is present when sent by the AC and
   contains the following fields.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Opcode    |           Checksum            |  Image Data   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Image Data ...                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:   33 for Image Data

   Length:   >= 5

   Opcode:   An 8-bit value representing the transfer opcode.  The
      following values are supported:

      3 -  Image Data is included.

      5 -  An error occurred.  Transfer is aborted.

   Checksum:   A 16-bit value containing a checksum of the Image Data
      that follows.

   Image Data:   The Image Data field contains 1024 characters, unless
      the payload being sent is the last one (end of file).

Top      Up      ToC       Page 68 
8.2.  Image Data Response

   The Image Data Response acknowledges the Image Data Request.

   An Image Data Responses is sent in response to an Image Data Request.
   Its purpose is to acknowledge the receipt of the Image Data Request
   packet.

   The Image Data Response carries no message elements.

   No action is necessary on receipt.

8.3.  Reset Request

   The Reset Request is used to cause a WTP to reboot.

   Reset Requests are sent by an AC to cause a WTP to reinitialize its
   operation.

   The Reset Request carries no message elements.

   When a WTP receives a Reset Request it will respond with a Reset
   Response and then reinitialize itself.

8.4.  Reset Response

   The Reset Response acknowledges the Reset Request.

   Reset Responses are sent by a WTP after receiving a Reset Request.

   The Reset Response carries no message elements.  Its purpose is to
   acknowledge the receipt of the Reset Request.

   When an AC receives a Reset Response, it is notified that the WTP
   will now reinitialize its operation.

8.5.  WTP Event Request

   The WTP Event Request is used by a WTP to send information to its AC.
   These types of events may be periodical, or some asynchronous event
   on the WTP.  For instance, a WTP collects statistics and uses the WTP
   Event Request to transmit this information to the AC.

   When an AC receives a WTP Event Request, it will respond with a WTP
   Event Request.

Top      Up      ToC       Page 69 
   The WTP Event Request message MUST contain one of the following
   message element described in the next subsections, or a message
   element that is defined for a specific technology.

8.5.1.  Decryption Error Report

   The Decryption Error Report message element value is used by the WTP
   to inform the AC of decryption errors that have occurred since the
   last report.

       0                   1                   2
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Radio ID    |Num Of Entries |      Mobile MAC Address       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Mobile MAC Address[]                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:   39 for Decryption Error Report

   Length:   >= 8

   Radio ID:   The Radio Identifier, typically refers to some interface
      index on the WTP.

   Num Of Entries:   An 8-bit unsigned integer indicating the number of
      mobile MAC addresses.

   Mobile MAC Address:   An array of mobile station MAC addresses that
      have caused decryption errors.

8.5.2.  Duplicate IPv4 Address

   The Duplicate IPv4 Address message element is used by a WTP to inform
   an AC that it has detected another host using the same IP address it
   is currently using.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          IP Address                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          MAC Address                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          MAC Address          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:   77 for Duplicate IPv4 Address

Top      Up      ToC       Page 70 
   Length:   10

   IP Address:   The IP address currently used by the WTP.

   MAC Address:   The MAC address of the offending device.

8.5.3.  Duplicate IPv6 Address

   The Duplicate IPv6 Address message element is used by a WTP to inform
   an AC that it has detected another host using the same IP address it
   is currently using.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          IP Address                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          IP Address                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          IP Address                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          IP Address                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          MAC Address                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          MAC Address          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:   77 for Duplicate IPv6 Address

   Length:   10

   IP Address:   The IP address currently used by the WTP.

   MAC Address:   The MAC address of the offending device.

8.6.  WTP Event Response

   The WTP Event Response acknowledges the WTP Event Request.

   WTP Event Responses are sent by an AC after receiving a WTP Event
   Request.

   The WTP Event Response carries no message elements.

Top      Up      ToC       Page 71 
8.7.  Data Transfer Request

   The Data Transfer Request is used to upload debug information from
   the WTP to the AC.

   Data Transfer Requests are sent by the WTP to the AC when it
   determines that it has important information to send to the AC.  For
   instance, if the WTP detects that its previous reboot was caused by a
   system crash, it would want to send the crash file to the AC.  The
   remote debugger function in the WTP also uses the Data Transfer
   Request in order to send console output to the AC for debugging
   purposes.

   When an AC receives a Data Transfer Request, it will respond with a
   Data Transfer Response.  The AC may log the information received as
   it sees fit.

   The Data Transfer Request message MUST contain ONE of the following
   message element described in the next subsection.

8.7.1.  Data Transfer Mode

   The Data Transfer Mode message element is used by the AC to request
   information from the WTP for debugging purposes.

       0
       0 1 2 3 4 5 6 7
      +-+-+-+-+-+-+-+-+
      |   Data  Type   |
      +-+-+-+-+-+-+-+-+

   Type:   52 for Data Transfer Mode

   Length:   1

   Data Type:   An 8-bit value describing the type of information being
      requested.  The following values are supported:

      1 -  WTP Crash Data

      2 -  WTP Memory Dump

8.7.2.  Data Transfer Data

   The Data Transfer Data message element is used by the WTP to provide
   information to the AC for debugging purposes.

Top      Up      ToC       Page 72 
       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Data Type   |  Data Length  |    Data ....
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:   53 for Data Transfer Data

   Length:   >= 3

   Data Type:   An 8-bit value describing the type of information being
      sent.  The following values are supported:

      1 -  WTP Crash Data

      2 -  WTP Memory Dump

   Data Length:   Length of data field.

   Data:   Debug information.

8.8.  Data Transfer Response

   The Data Transfer Response acknowledges the Data Transfer Request.

   A Data Transfer Response is sent in response to a Data Transfer
   Request.  Its purpose is to acknowledge the receipt of the Data
   Transfer Request packet.

   The Data Transfer Response carries no message elements.

   Upon receipt of a Data Transfer Response, the WTP transmits more
   information, if any is available.

9.  Mobile Session Management

   Messages in this section are used by the AC to create, modify, or
   delete mobile station session state on the WTPs.

9.1.  Mobile Config Request

   The Mobile Config Request message is used to create, modify, or
   delete mobile session state on a WTP.  The message is sent by the AC
   to the WTP, and may contain one or more message elements.  The

Top      Up      ToC       Page 73 
   message elements for this LWAPP control message include information
   that is generally highly technology-specific.  Therefore, please
   refer to the appropriate binding section or document for the
   definitions of the messages elements that may be used in this control
   message.

   This section defines the format of the Delete Mobile message element,
   since it does not contain any technology-specific information.

9.1.1.  Delete Mobile

   The Delete Mobile message element is used by the AC to inform a WTP
   that it should no longer provide service to a particular mobile
   station.  The WTP must terminate service immediately upon receiving
   this message element.

   The transmission of a Delete Mobile message element could occur for
   various reasons, including administrative reasons, as a result of the
   fact that the mobile has roamed to another WTP, etc.

   Once access has been terminated for a given station, any future
   packets received from the mobile must result in a deauthenticate
   message, as specified in [6].

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Radio ID   |                  MAC Address                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  MAC Address                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:   30 for Delete Mobile

   Length:   7

   Radio ID:   An 8-bit value representing the radio

   MAC Address:   The mobile station's MAC address

9.2.  Mobile Config Response

   The Mobile Configuration Response is used to acknowledge a previously
   received Mobile Configuration Request, and includes a Result Code
   message element that indicates whether an error occurred on the WTP.

   This message requires no special processing and is only used to
   acknowledge the Mobile Configuration Request.

Top      Up      ToC       Page 74 
   The Data Transfer Request message MUST contain the message elements
   described in the next subsection.

9.2.1.  Result Code

   The Result Code message element is defined in Section 6.2.1.

10.  LWAPP Security

   Note: This version only defines a certificate and a shared-secret-
   based mechanism to secure control LWAPP traffic exchanged between the
   WTP and the AC.

10.1.  Securing WTP-AC Communications

   While it is generally straightforward to produce network
   installations in which the communications medium between the WTP and
   AC is not accessible to the casual user (e.g., these LAN segments are
   isolated, and no RJ45 or other access ports exist between the WTP and
   the AC), this will not always be the case.  Furthermore, a determined
   attacker may resort to various, more sophisticated monitoring and/or
   access techniques, thereby compromising the integrity of this
   connection.

   In general, a certain level of threat on the local (wired) LAN is
   expected and accepted in most computing environments.  That is, it is
   expected that in order to provide users with an acceptable level of
   service and maintain reasonable productivity levels, a certain amount
   of risk must be tolerated.  It is generally believed that a certain
   perimeter is maintained around such LANs, that an attacker must have
   access to the building(s) in which such LANs exist, and that they
   must be able to "plug in" to the LAN in order to access the network.

   With these things in mind, we can begin to assess the general
   security requirements for AC-WTP communications.  While an in-depth
   security analysis of threats and risks to these communications is
   beyond the scope of this document, some discussion of the motivation
   for various security-related design choices is useful.  The
   assumptions driving the security design thus far include the
   following:

   o  WTP-AC communications take place over a wired connection that may
      be accessible to a sophisticated attacker.

   o  access to this connection is not trivial for an outsider (i.e.,
      someone who does not "belong" in the building) to access.

Top      Up      ToC       Page 75 
   o  if authentication and/or privacy of end-to-end traffic for which
      the WTP and AC are intermediaries is required, this may be
      provided via IPsec [14].

   o  privacy and authentication for at least some WTP-AC control
      traffic is required (e.g., Wired Equivalent Privacy (WEP) keys for
      user sessions, passed from the AC to the WTP).

   o  the AC can be trusted to generate strong cryptographic keys.

   The AC-WTP traffic can be considered to consist of two types: data
   traffic (e.g., to or from an end user), and control traffic, which is
   strictly between the AC and WTP.  Since data traffic may be secured
   using IPsec (or some other end-to-end security mechanism), we confine
   our solution to control traffic.  The resulting security consists of
   two components: an authenticated key exchange and control traffic
   security encapsulation.  The security encapsulation is accomplished
   using AES-CCM, described in [3].  This encapsulation provides for
   strong AES-based authentication and encryption [2].  The exchange of
   cryptographic keys used for CCM is described below.

10.2.  LWAPP Frame Encryption

   While the LWAPP protocol uses AES-CCM to encrypt control traffic, it
   is important to note that not all control frames are encrypted.  The
   LWAPP discovery and join phase are not encrypted.  The Discovery
   messages are sent in the clear since there does not exist a security
   association between the WTP and the AC during the discovery phase.
   The join phase is an authenticated exchange used to negotiate
   symmetric session keys (see Section 10.3).

   Once the join phase has been successfully completed, the LWAPP state
   machine Figure 2 will move to the Configure state, at which time all
   LWAPP control frames are encrypted using AES-CCM.

   Encryption of a control message begins at the Message Element field:
   meaning the Msg Type, Seq Num, Msg Element Length, and Session ID
   fields are left intact (see Section 4.2.1).

   The AES-CCM 12-byte authentication data is appended to the end of the
   message.  The authentication data is calculated from the start of the
   LWAPP packet and includes the complete LWAPP control header (see
   Section 4.2.1).

Top      Up      ToC       Page 76 
   The AES-CCM block cipher protocol requires an initialization vector.
   The LWAPP protocol requires that the WTP and the AC maintain two
   separate IVs, one for transmission and one for reception.  The IV
   derived during the key exchange phase by both the WTP and the AC is
   used as the base for all encrypted packets with a new key.

10.3.  Authenticated Key Exchange

   This section describes the key management component of the LWAPP
   protocol.  There are two modes supported by LWAPP: certificate and
   pre-shared key.

10.3.1.  Terminology

   This section details the key management protocol that makes use of
   pre-shared secrets.

   The following notations are used throughout this section:

   o  PSK - the pre-shared key shared between the WTP and the AC.

   o  Kpriv - the private key of a public-private key pair.

   o  Kpub - the public key of the pair.

   o  SessionID - a randomly generated LWAPP session identifier,
      provided by the WTP in the Join Request.

   o  E-x{Kpub, M} - RSA encryption of M using X's public key.

   o  D-x{Kpriv, C} - RSA decryption of C using X's private key.

   o  AES-CMAC(key, packet) - A message integrity check, using AES-CMAC
      and key, of the complete LWAPP packet, with the Sequence Number
      field and the payload of the PSK-MIC message element set to zero.

   o  AES-E(key, plaintext) - Plaintext is encrypted with key, using
      AES.

   o  AES-D(key, ciphertext) - ciphertext is decrypted with key, using
      AES.

   o  Certificate-AC - AC's Certificate.

   o  Certificate-WTP - WTP's Certificate.

   o  WTP-MAC - The WTP's MAC address.

Top      Up      ToC       Page 77 
   o  AC-MAC - The AC's MAC address.

   o  RK0 - the root key, which is created through a Key Derivation
      Function (KDF) function.

   o  RK0E - the root Encryption key, derived from RK0.

   o  RK0M - the root MIC key, derived from RK0.

   o  SK1 - the session key.

   o  SK1C - the session confirmation key, derived from SK.

   o  SK1E - the session encryption key, derived from SK.

   o  SK1W - the session keywrap key, derived from SK (see RFC 3394
      [9]).

   o  WNonce - The WTP's randomly generated nonce.

   o  ANonce - The AC's randomly generated nonce.

   o  EWNonce - The payload of the WNonce message element, which
      includes the WNonce.

   o  EANonce - The payload of the ANonce message element, which
      includes the ANonce.

10.3.2.  Initial Key Generation

   The AC and WTP accomplish mutual authentication and a cryptographic
   key exchange in a dual round trip using the Join Request, Join
   Response, Join ACK, and Join Confirm (see Section 6.1).

   The following text describes the exchange between the WTP and the AC
   that creates a session key, which is used to secure LWAPP control
   messages.

   o  The WTP creates a Join Request using the following process:

      o  If certificate-based security is used, the WTP adds the
         Certificate message element (see Section 6.1.6) with its
         contents set to Certificate-WTP.

      o  The WTP adds the Session ID message element (see Section 6.1.7)
         with the contents set to a randomly generated session
         identifier (see RFC 1750 [4]).  The WTP MUST save the Session
         ID in order to validate the Join Response.

Top      Up      ToC       Page 78 
      o  The WTP creates a random nonce, included in the XNonce message
         element (see Section 6.1.9).  The WTP MUST save the XNonce to
         validate the Join Response.

      o  The WTP transmits the Join Request to the AC.

   o  Upon receiving the Join Request, the AC uses the following
      process:

      o  The AC creates the Join Response, and ensures that the Session
         ID message element matches the value found in the Join Request.

      o  If certificate-based security is used, the AC:

         o  adds the Certificate-AC to the Certificate message element.

         o  creates a random 'AC Nonce' and encrypts it using the
            following algorithm E-wtp(Kpub, XNonce XOR 'AC Nonce').  The
            encrypted contents are added to the ANonce's message element
            payload.

      o  If a pre-shared-key-based security is used, the AC:

         o  creates RK0 through the following algorithm: RK0 = KDF-
            256{PSK, "LWAPP PSK Top K0" || Session ID || WTP-MAC || AC-
            MAC}, where WTP-MAC is the WTP's MAC address in the form
            "xx:xx:xx:xx:xx:xx".  Similarly, the AC-MAC is an ASCII
            encoding of the AC's MAC address, of the form "xx:xx:xx:xx:
            xx:xx".  The resulting K0 is split into the following:

            o  The first 16 octets are known as RK0E, and are used as an
               encryption key.

            o  The second 16 octets are known as RK0M, and are used for
               MIC'ing purposes.

         o  The AC creates a random 'AC Nonce' and encrypts it using the
            following algorithm: AES-E(RK0E, XNonce XOR 'AC Nonce').
            The encrypted contents are added to the ANonce's message
            element payload.

         o  The AC adds a MIC to the contents of the Join Response using
            AES-CMAC(RK0M, Join Response) and adds the resulting hash to
            the PSK-MIC (Section 6.2.9) message element.

   o  Upon receiving the Join Response, the WTP uses the following
      process:

Top      Up      ToC       Page 79 
      o  If a pre-shared key is used, the WTP authenticates the Join
         Response's PSK-MIC message element.  If authentication fails,
         the packet is dropped.

      o  The WTP decrypts the ANonce message element and XOR's the value
         with XNonce to retrieve the 'AC Nonce'.  The ANonce payload is
         referred to as ciphertext below:

         o  If a pre-shared key is used, use AES-D(RK0E, ciphertext).
            The 'AC Nonce' is then recovered using XNonce XOR plaintext.

         o  If certificates are used, use d-wtp(Kpriv, ciphertext).  The
            'AC Nonce' is then recovered using XNonce XOR plaintext.

      o  The WTP creates a random 'WTP Nonce'.

      o  The WTP uses the KDF function to create a 64-octet session key
         (SK).  The KDF function used is as follows: KDF-512{'WTP Nonce'
         || 'AC Nonce', "LWAPP Key Generation", WTP-MAC || AC-MAC}.  The
         KDF function is defined in [7].

      o  SK is then broken down into three separate session keys with
         different purposes:

         o  The first 16 octets are known as SK1C, and are used as a
            confirmation key.

         o  The second 16 octets are known as SK1E, and are as the
            encryption key.

         o  The third 16 octets are known as SK1D, and are used as the
            keywrap key.

         o  The fourth 16 octets are known as IV, and are used as the
            Initialization Vector during encryption.

      o  The WTP creates the Join ACK message.

      o  If certificate-based security is used, the AC:

         o  encrypts the 'WTP Nonce' using the following algorithm: E-
            ac(Kpub, 'WTP Nonce').  The encrypted contents are added to
            the WNonce's message element payload.

      o  If a pre-shared-key-based security is used, the AC:

Top      Up      ToC       Page 80 
         o  encrypts the 'WTP Nonce' using the following algorithm:
            AES-E(RK0E, 'WTP Nonce').  The encrypted contents are added
            to the WNonce's message element payload.

      o  The WTP adds a MIC to the contents of the Join ACK using
         AES-CMAC(SK1M, Join ACK) and adds the resulting hash to the
         PSK-MIC (Section 6.2.9) message element.

      o  The WTP then transmits the Join ACK to the AC.

   o  Upon receiving the Join ACK, the AC uses the following process:

      o  The AC authenticates the Join ACK through the PSK-MIC message
         element.  If authentic, the AC decrypts the WNonce message
         element to retrieve the 'WTP Nonce'.  If the Join ACK cannot be
         authenticated, the packet is dropped.

      o  The AC decrypts the WNonce message element to retrieve the 'WTP
         Nonce'.  The WNonce payload is referred to as ciphertext below:

         o  If a pre-shared key is used, use AES-D(RK0E, ciphertext).
            The plaintext is then considered the 'WTP Nonce'.

         o  If certificates are used, use d-ac(Kpriv, ciphertext).  The
            plaintext is then considered the 'WTP Nonce'.

      o  The AC then uses the KDF function to create a 64-octet session
         key (SK).  The KDF function used is as follows: KDF-512{'WTP
         Nonce' || 'AC Nonce', "LWAPP Key Generation", WTP-MAC ||
         AC-MAC}.  The KDF function is defined in [7].  The SK is split
         into SK1C, SK1E, SK1D, and IV, as previously noted.

      o  The AC creates the Join Confirm.

      o  The AC adds a MIC to the contents of the Join Confirm using
         AES-CMAC(SK1M, Join Confirm) and adds the resulting hash to the
         MIC (Section 6.2.9) message element.

      o  The AC then transmits the Join Confirm to the WTP.

   o  Upon receiving the Join Confirm, the WTP uses the following
      process:

      o  The WTP authenticates the Join Confirm through the PSK-MIC
         message element.  If the Join Confirm cannot be authenticated,
         the packet is dropped.

Top      Up      ToC       Page 81 
   o  SK1E is now plumbed into the AC and WTP's crypto engine as the
      AES-CCM LWAPP control encryption session key.  Furthermore, the
      random IV is used as the base Initialization Vector.  From this
      point on, all control protocol payloads between the WTP and AC are
      encrypted and authenticated using the new session key.

10.3.3.  Refreshing Cryptographic Keys

   Since AC-WTP associations will tend to be relatively long-lived, it
   is sensible to periodically refresh the encryption and authentication
   keys; this is referred to as "rekeying".  When the key lifetime
   reaches 95% of the configured value, identified in the KeyLifetime
   timer (see Section 12), the rekeying will proceed as follows:

   o  The WTP creates RK0 through the previously defined KDF algorithm:
      RK0 = KDF-256{SK1D, "LWAPP PSK Top K0" || Session ID || WTP-MAC ||
      AC-MAC}.  Note that the difference in this specific instance is
      that SK1D that was previously generated is used instead of the
      PSK.  Note this is used in both the certificate and pre-shared key
      modes.  The resulting RK0 creates RK0E, RK0M.

   o  The remaining steps used are identical to the join process, with
      the exception that the rekey messages are used instead of join
      messages, and the fact that the messages are encrypted using the
      previously created SK1E.  This means the Join Request is replaced
      with the Rekey Request, the Join Response is replaced with the
      Rekey Response, etc.  The two differences between the rekey and
      the join process are:

      o  The Certificate-WTP and Certificate-AC are not included in the
         Rekey-Request and Rekey-Response, respectively.

      o  Regardless of whether certificates or pre-shared keys were used
         in the initial key derivation, the process now uses the pre-
         shared key mode only, using SK1D as the "PSK".

   o  The Key Update Request is sent to the AC.

   o  The newly created SK1E is now plumbed into the AC and WTP's crypto
      engine as the AES-CCM LWAPP control encryption session key.
      Furthermore, the new random IV is used as the base Initialization
      Vector.  From this point on, all control protocol payloads between
      the WTP and AC are encrypted and authenticated using the new
      session key.

Top      Up      ToC       Page 82 
      If either the WTP or the AC do not receive an expected response by
      the time the ResponseTimeout timer expires (see Section 12), the
      WTP MUST delete the new and old session information, and reset the
      state machine to the Idle state.

      Following a rekey process, both the WTP and the AC keep the
      previous encryption for 5-10 seconds in order to be able to
      process packets that arrive out of order.

10.4.  Certificate Usage

   Validation of the certificates by the AC and WTP is required so that
   only an AC may perform the functions of an AC and that only a WTP may
   perform the functions of a WTP.  This restriction of functions to the
   AC or WTP requires that the certificates used by the AC MUST be
   distinguishable from the certificate used by the WTP.  To accomplish
   this differentiation, the x.509v3 certificates MUST include the
   Extensions field [10] and MUST include the NetscapeComment [11]
   extension.

   For an AC, the value of the NetscapeComment extension MUST be the
   string "CAPWAP AC Device Certificate".  For a WTP, the value of the
   NetscapeComment extension MUST be the string "CAPWAP WTP Device
   Certificate".

   Part of the LWAPP certificate validation process includes ensuring
   that the proper string is included in the NetscapeComment extension,
   and only allowing the LWAPP session to be established if the
   extension does not represent the same role as the device validating
   the certificate.  For instance, a WTP MUST NOT accept a certificate
   whose NetscapeComment field is set to "CAPWAP WTP Device
   Certificate".

11.  IEEE 802.11 Binding

   This section defines the extensions required for the LWAPP protocol
   to be used with the IEEE 802.11 protocol.

11.1.  Division of Labor

   The LWAPP protocol, when used with IEEE 802.11 devices, requires a
   specific behavior from the WTP and the AC, specifically in terms of
   which 802.11 protocol functions are handled.

   For both the Split and Local MAC approaches, the CAPWAP functions, as
   defined in the taxonomy specification, reside in the AC.

Top      Up      ToC       Page 83 
11.1.1.  Split MAC

   This section shows the division of labor between the WTP and the AC
   in a Split MAC architecture.  Figure 3 shows the clear separation of
   functionality among LWAPP components.

       Function                               Location
           Distribution Service                      AC
           Integration Service                       AC
           Beacon Generation                         WTP
           Probe Response                            WTP
           Power Mgmt/Packet Buffering               WTP
           Fragmentation/Defragmentation             WTP
           Assoc/Disassoc/Reassoc                    AC

      802.11e
           Classifying                               AC
           Scheduling                                WTP/AC
           Queuing                                   WTP

      802.11i
           802.1X/EAP                                AC
           Key Management                            AC
           802.11 Encryption/Decryption              WTP or AC

       Figure 3: Mapping of 802.11 Functions for Split MAC Architecture

   The Distribution and Integration services reside on the AC, and
   therefore all user data is tunneled between the WTP and the AC.  As
   noted above, all real-time 802.11 services, including the control
   protocol and the beacon and Probe Response frames, are handled on the
   WTP.

   All remaining 802.11 MAC management frames are supported on the AC,
   including the Association Request, which allows the AC to be involved
   in the access policy enforcement portion of the 802.11 protocol.  The
   802.1X and 802.11i key management function are also located on the
   AC.

   While the admission control component of 802.11e resides on the AC,
   the real-time scheduling and queuing functions are on the WTP.  Note
   that this does not exclude the AC from providing additional policing
   and scheduling functionality.

   Note that in the following figure, the use of '( - )' indicates that
   processing of the frames is done on the WTP.

Top      Up      ToC       Page 84 
      Client                       WTP                        AC

               Beacon
      <-----------------------------
            Probe Request
      ----------------------------( - )------------------------->
            Probe Response
      <-----------------------------
                       802.11 AUTH/Association
      <--------------------------------------------------------->
                         Add Mobile (Clear Text, 802.1X Only)
                                      <------------------------->
             802.1X Authentication & 802.11i Key Exchange
      <--------------------------------------------------------->
                                  Add Mobile (AES-CCMP, PTK=x)
                                      <------------------------->
                        802.11 Action Frames
      <--------------------------------------------------------->
                            802.11 DATA (1)
      <---------------------------( - )------------------------->

                       Figure 4: Split MAC Message Flow

   Figure 4 provides an illustration of the division of labor in a Split
   MAC architecture.  In this example, a WLAN has been created that is
   configured for 802.11i, using AES-CCMP for privacy.  The following
   process occurs:

   o  The WTP generates the 802.11 beacon frames, using information
      provided to it through the Add WLAN (see Section 11.8.1.1) message
      element.

   o  The WTP processes the Probe Request and responds with a
      corresponding Probe Response.  The problem request is then
      forwarded to the AC for optional processing.

   o  The WTP forwards the 802.11 Authentication and Association frames
      to the AC, which is responsible for responding to the client.

   o  Once the association is complete, the AC transmits an LWAPP Add
      Mobile Request to the WTP (see Section 11.7.1.1).  In the above
      example, the WLAN is configured for 802.1X, and therefore the
      '802.1X only' policy bit is enabled.

   o  If the WTP is providing encryption/decryption services, once the
      client has completed the 802.11i key exchange, the AC transmits
      another Add Mobile Request to the WTP, stating the security policy
      to enforce for the client (in this case AES-CCMP), as well as the

Top      Up      ToC       Page 85 
      encryption key to use.  If encryption/decryption is handled in the
      AC, the Add Mobile Request would have the encryption policy set to
      "Clear Text".

   o  The WTP forwards any 802.11 Action frames received to the AC.

   o  All client data frames are tunneled between the WTP and the AC.
      Note that the WTP is responsible for encrypting and decrypting
      frames, if it was indicated in the Add Mobile Request.

11.1.2.  Local MAC

   This section shows the division of labor between the WTP and the AC
   in a Local MAC architecture.  Figure 5 shows the clear separation of
   functionality among LWAPP components.

       Function                               Location
           Distribution Service                      WTP
           Integration Service                       WTP
           Beacon Generation                         WTP
           Probe Response                            WTP
           Power Mgmt/Packet Buffering               WTP
           Fragmentation/Defragmentation             WTP
           Assoc/Disassoc/Reassoc                    WTP

      802.11e
           Classifying                               WTP
           Scheduling                                WTP
           Queuing                                   WTP

      802.11i
           802.1X/EAP                                AC
           Key Management                            AC
           802.11 Encryption/Decryption              WTP

      Figure 5: Mapping of 802.11 Functions for Local AP Architecture

   Given that Distribution and Integration Services exist on the WTP,
   client data frames are not forwarded to the AC, with the exception
   listed in the following paragraphs.

   While the MAC is terminated on the WTP, it is necessary for the AC to
   be aware of mobility events within the WTPs.  As a consequence, the
   WTP MUST forward the 802.11 Association Requests to the AC, and the
   AC MAY reply with a failed Association Response if it deems it
   necessary.

Top      Up      ToC       Page 86 
   The 802.1X and 802.11i Key Management function resides in the AC.
   Therefore, the WTP MUST forward all 802.1X/Key Management frames to
   the AC and forward the associated responses to the station.

   Note that in the following figure, the use of '( - )' indicates that
   processing of the frames is done on the WTP.


      Client                       WTP                        AC

               Beacon
      <-----------------------------
                Probe
      <---------------------------->
             802.11 AUTH
      <-----------------------------
                          802.11 Association
      <---------------------------( - )------------------------->
                         Add Mobile (Clear Text, 802.1X Only)
                                      <------------------------->
             802.1X Authentication & 802.11i Key Exchange
      <--------------------------------------------------------->
                        802.11 Action Frames
      <--------------------------------------------------------->
                                  Add Mobile (AES-CCMP, PTK=x)
                                      <------------------------->
              802.11 DATA
      <----------------------------->

                       Figure 6: Local MAC Message Flow

   Figure 6 provides an illustration of the division of labor in a Local
   MAC architecture.  In this example, a WLAN has been created that is
   configured for 802.11i, using AES-CCMP for privacy.  The following
   process occurs:

   o  The WTP generates the 802.11 beacon frames, using information
      provided to it through the Add WLAN (see Section 11.8.1.1) message
      element.

   o  The WTP processes the Probe Request and responds with a
      corresponding Probe Response.

   o  The WTP forwards the 802.11 Authentication and Association frames
      to the AC, which is responsible for responding to the client.

Top      Up      ToC       Page 87 
   o  Once the association is complete, the AC transmits an LWAPP Add
      Mobile Request to the WTP (see Section 11.7.1.1.  In the above
      example, the WLAN is configured for 802.1X, and therefore the
      '802.1X only' policy bit is enabled.

   o  The WTP forwards all 802.1X and 802.11i key exchange messages to
      the AC for processing.

   o  The AC transmits another Add Mobile Request to the WTP, stating
      the security policy to enforce for the client (in this case, AES-
      CCMP), as well as the encryption key to use.  The Add Mobile
      Request MAY include a VLAN name, which when present is used by the
      WTP to identify the VLAN on which the user's data frames are to be
      bridged.

   o  The WTP forwards any 802.11 Action frames received to the AC.

   o  The WTP locally bridges all client data frames, and provides the
      necessary encryption and decryption services.

11.2.  Roaming Behavior and 802.11 Security

   It is important that LWAPP implementations react properly to mobile
   devices associating to the networks in how they generate Add Mobile
   and Delete Mobile messages.  This section expands upon the examples
   provided in the previous section, and describes how the LWAPP control
   protocol is used in order to provide secure roaming.

   Once a client has successfully associated with the network in a
   secure fashion, it is likely to attempt to roam to another access
   point.  Figure 7 shows an example of a currently associated station
   moving from its "Old WTP" to a new "WTP".  The figure is useful for
   multiple different security policies, including standard 802.1X and
   dynamic WEP keys, WPA or even WPA2 both with key caching (where the
   802.1x exchange would be bypassed) and without.

Top      Up      ToC       Page 88 
      Client              Old WTP              WTP              AC

                    Association Request/Response
       <--------------------------------------( - )-------------->
                          Add Mobile (Clear Text, 802.1X Only)
                                                <---------------->
       802.1X Authentication (if no key cache entry exists)
       <--------------------------------------( - )-------------->
                     802.11i 4-way Key Exchange
       <--------------------------------------( - )-------------->
                                   Delete Mobile
                              <---------------------------------->
                                   Add Mobile (AES-CCMP, PTK=x)
                                                <---------------->

                       Figure 7: Client Roaming Example

11.3.  Transport-Specific Bindings

   All LWAPP transports have the following IEEE 802.11 specific
   bindings:

11.3.1.  Status and WLANS Field

   The interpretation of this 16-bit field depends on the direction of
   transmission of the packet.  Refer to the figure in Section 3.1.

   Status

   When an LWAPP packet is transmitted from a WTP to an AC, this field
   is called the Status field and indicates radio resource information
   associated with the frame.  When the message is an LWAPP control
   message this field is transmitted as zero.

   The Status field is divided into the signal strength and signal-to-
   noise ratio with which an IEEE 802.11 frame was received, encoded in
   the following manner:

       0                   1
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     RSSI      |     SNR       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   RSSI:   RSSI is a signed, 8-bit value.  It is the received signal
      strength indication, in dBm.

Top      Up      ToC       Page 89 
   SNR:   SNR is a signed, 8-bit value.  It is the signal-to-noise ratio
      of the received IEEE 802.11 frame, in dB.

   WLANs field:   When an LWAPP data message is transmitted from an AC
      to a WTP, this 16-bit field indicates on which WLANs the
      encapsulated IEEE 802.11 frame is to be transmitted.  For unicast
      packets, this field is not used by the WTP.  For broadcast or
      multicast packets, the WTP might require this information if it
      provides encryption services.

      Given that a single broadcast or multicast packet might need to be
      sent to multiple wireless LANs (presumably each with a different
      broadcast key), this field is defined as a bit field.  A bit set
      indicates a WLAN ID (see Section 11.8.1.1), which will be sent the
      data.  The WLANS field is encoded in the following manner:

       0                   1
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          WLAN ID(s)           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

11.4.  BSSID to WLAN ID Mapping

   The LWAPP protocol makes assumptions regarding the BSSIDs used on the
   WTP.  It is a requirement for the WTP to use a contiguous block of
   BSSIDs.  The WLAN Identifier field, which is managed by the AC, is
   used as an offset into the BSSID list.

   For instance, if a WTP had a base BSSID address of 00:01:02:00:00:00,
   and the AC sent an Add WLAN message with a WLAN Identifier of 2 (see
   Section 11.8.1.1), the BSSID for the specific WLAN on the WTP would
   be 00:01:02:00:00:02.

   The WTP communicates the maximum number of BSSIDs that it supports
   during the Config Request within the IEEE 802.11 WTP WLAN Radio
   Configuration message element (see Section 11.9.1).

11.5.  Quality of Service

   It is recommended that 802.11 MAC management be sent by both the AC
   and the WTP with appropriate Quality-of-Service (QoS) values,
   ensuring that congestion in the network minimizes occurrences of
   packet loss.  Therefore, a QoS-enabled LWAPP device should use:

   802.1P:   The precedence value of 6 SHOULD be used for all 802.11 MAC
      management messages, except for Probe Requests, which SHOULD use
      4.

Top      Up      ToC       Page 90 
   DSCP:   The DSCP tag value of 46 SHOULD be used for all 802.11 MAC
      management messages, except for Probe Requests, which SHOULD use
      34.

11.6.  Data Message Bindings

   There are no LWAPP data message bindings for IEEE 802.11.

11.7.  Control Message Bindings

   The IEEE 802.11 binding has the following control message
   definitions.

11.7.1.  Mobile Config Request

   This section contains the 802.11-specific message elements that are
   used with the Mobile Config Request.

11.7.1.1.  Add Mobile

   The Add Mobile Request is used by the AC to inform a WTP that it
   should forward traffic from a particular mobile station.  The Add
   Mobile Request may also include security parameters that must be
   enforced by the WTP for the particular mobile.

   When the AC sends an Add Mobile Request, it includes any security
   parameters that may be required.  An AC that wishes to update a
   mobile's policy on a WTP may do so by simply sending a new Add Mobile
   message element.

   When a WTP receives an Add Mobile message element, it must first
   override any existing state it may have for the mobile station in
   question.  The latest Add Mobile overrides any previously received
   messages.  If the Add Mobile message element's EAP-Only bit is set,
   the WTP MUST drop all 802.11 packets that do not contain EAP packets.
   Note that when EAP Only is set, the Encryption Policy field MAY have
   additional values, and therefore it is possible to inform a WTP to
   only accept encrypted EAP packets.  Once the mobile station has
   successfully completed EAP authentication, the AC must send a new Add
   Mobile message element to push the session key down to the WTP as
   well as to remove the EAP Only restriction.

   If the QoS field is set, the WTP MUST observe and provide policing of
   the 802.11e priority tag to ensure that it does not exceed the value
   provided by the AC.

Top      Up      ToC       Page 91 
       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Radio ID   |        Association ID         |  MAC Address  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          MAC Address                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  MAC Address  |E|C|            Encryption Policy              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Encrypt Policy |                Session Key...                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Pairwise TSC...                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Pairwise RSC...                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Capabilities         |   WLAN ID     |    WME Mode   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | 802.11e Mode  |      Qos      |        Supported Rates        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Supported Rates                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          VLAN Name...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:   29 for Add Mobile

   Length:   36

   Radio ID:   An 8-bit value representing the radio.

   Association ID:   A 16-bit value specifying the 802.11 Association
      Identifier.

   MAC Address:   The mobile station's MAC address.

   E:   The 1-bit field is set by the AC to inform the WTP that it MUST
      NOT accept any 802.11 data frames, other than 802.1X frames.  This
      is the equivalent of the WTP's 802.1X port for the mobile station
      to be in the closed state.  When set, the WTP MUST drop any
      non-802.1X packets it receives from the mobile station.

   C:   The 1-bit field is set by the AC to inform the WTP that
      encryption services will be provided by the AC.  When set, the WTP
      SHOULD police frames received from stations to ensure that they
      comply to the stated encryption policy, but does not need to take
      specific cryptographic action on the frame.  Similarly, for
      transmitted frames, the WTP only needs to forward already
      encrypted frames.

Top      Up      ToC       Page 92 
   Encryption Policy:   The policy field informs the WTP how to handle
      packets from/to the mobile station.  The following values are
      supported:

      0 -  Encrypt WEP 104: All packets to/from the mobile station must
           be encrypted using a standard 104-bit WEP.

      1 -  Clear Text: All packets to/from the mobile station do not
           require any additional crypto processing by the WTP.

      2 -  Encrypt WEP 40: All packets to/from the mobile station must
           be encrypted using a standard 40-bit WEP.

      3 -  Encrypt WEP 128: All packets to/from the mobile station must
           be encrypted using a standard 128-bit WEP.

      4 -  Encrypt AES-CCMP 128: All packets to/from the mobile station
           must be encrypted using a 128-bit AES-CCMP [7].

      5 -  Encrypt TKIP-MIC: All packets to/from the mobile station must
           be encrypted using Temporal Key Integrity Protocol (TKIP) and
           authenticated using Michael [16].

   Session Key:   A 32-octet session key the WTP is to use when
      encrypting traffic to or decrypting traffic from the mobile
      station.  The type of key is determined based on the Encryption
      Policy field.

   Pairwise TSC:   The TKIP Sequence Counter (TSC) to use for unicast
      packets transmitted to the mobile.

   Pairwise RSC:   The Receive Sequence Counter (RSC) to use for unicast
      packets received from the mobile.

   Capabilities:   A 16-bit field containing the 802.11 capabilities to
      use with the mobile.

   WLAN ID:   An 8-bit value specifying the WLAN Identifier.

   WME Mode:   An 8-bit Boolean used to identify whether the station is
      WME capable.  A value of zero is used to indicate that the station
      is not Wireless Multimedia Extension (WME) capable, while a value
      of one means that the station is WME capable.

   802.11e Mode:   An 8-bit Boolean used to identify whether the station
      is 802.11e-capable.  A value of zero is used to indicate that the
      station is not 802.11e-capable, while a value of one means that
      the station is 802.11e-capable.

Top      Up      ToC       Page 93 
   QoS:   An 8-bit value specifying the QoS policy to enforce for the
      station.  The following values are supported: PRC: TO CHECK

      0 -  Silver (Best Effort)

      1 -  Gold (Video)

      2 -  Platinum (Voice)

      3 -  Bronze (Background)

   Supported Rates:   The supported rates to be used with the mobile
      station.

   VLAN Name:   An optional variable string containing the VLAN Name on
      which the WTP is to locally bridge user data.  Note that this
      field is only valid with Local MAC WTPs.

11.7.1.2.  IEEE 802.11 Mobile Session Key

   The Mobile Session Key Payload message element is sent when the AC
   determines that encryption of a mobile station must be performed in
   the WTP.  This message element MUST NOT be present without the Add
   Mobile message element, and MUST NOT be sent if the WTP had not
   specifically advertised support for the requested encryption scheme
   (see Section 11.7.1.1).

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           MAC Address                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          MAC Address          |       Encryption Policy       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Encryption Policy       |        Session Key...         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:   105 for IEEE 802.11 Mobile Session Key

   Length:   >= 11

   MAC Address: The mobile station's MAC address.

   Encryption Policy: The policy field informs the WTP how to handle
      packets from/to the mobile station.  The following values are
      supported:

Top      Up      ToC       Page 94 
      0 -  Encrypt WEP 104: All packets to/from the mobile station must
           be encrypted using a standard 104-bit WEP.

      1 -  Clear Text: All packets to/from the mobile station do not
           require any additional crypto processing by the WTP.

      2 -  Encrypt WEP 40: All packets to/from the mobile station must
           be encrypted using a standard 40-bit WEP.

      3 -  Encrypt WEP 128: All packets to/from the mobile station must
           be encrypted using a standard 128-bit WEP.

      4 -  Encrypt AES-CCMP 128: All packets to/from the mobile station
           must be encrypted using a 128-bit AES-CCMP [7].

      5 -  Encrypt TKIP-MIC: All packets to/from the mobile station must
           be encrypted using TKIP and authenticated using Michael [16].

   Session Key: The session key the WTP is to use when encrypting
      traffic to/from the mobile station.

11.7.1.3.  Station QoS Profile

   The Station QoS Profile Payload message element contains the maximum
   802.11e priority tag that may be used by the station.  Any packets
   received that exceed the value encoded in this message element must
   either be dropped or tagged using the maximum value permitted to the
   user.  The priority tag must be between zero (0) and seven (7).

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           MAC Address                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          MAC Address          |     802.1P Precedence Tag     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:   140 for IEEE 802.11 Station QoS Profile

   Length:   12

   MAC Address:   The mobile station's MAC address.

   802.1P Precedence Tag:   The maximum 802.1P precedence value that the
      WTP will allow in the Traffic Identifier (TID) field in the
      extended 802.11e QoS Data header.

Top      Up      ToC       Page 95 
11.7.1.4.  IEEE 802.11 Update Mobile QoS

   The Update Mobile QoS message element is used to change the Quality-
   of-Service policy on the WTP for a given mobile station.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Radio ID    |        Association ID         |  MAC Address  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          MAC Address                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  MAC Address  |  QoS Profile  |        Vlan Identifier        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   DSCP Tag    |  802.1P Tag   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:   106 for IEEE 802.11 Update Mobile QoS

   Length:   14

   Radio ID:   The Radio Identifier, typically refers to some interface
      index on the WTP.

   Association ID:   The 802.11 Association Identifier.

   MAC Address:   The mobile station's MAC address.

   QoS Profile:   An 8-bit value specifying the QoS policy to enforce
      for the station.  The following values are supported:

      0 -  Silver (Best Effort)

      1 -  Gold (Video)

      2 -  Platinum (Voice)

      3 -  Bronze (Background)

   VLAN Identifier:   PRC.

   DSCP Tag:   The DSCP label to use if packets are to be DSCP tagged.

   802.1P Tag:   The 802.1P precedence value to use if packets are to be
      802.1P-tagged.

Top      Up      ToC       Page 96 
11.7.2.  WTP Event Request

   This section contains the 802.11-specific message elements that are
   used with the WTP Event Request message.

11.7.2.1.  IEEE 802.11 Statistics

   The Statistics message element is sent by the WTP to transmit its
   current statistics.  The value contains the following fields:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Radio ID   |               Tx Fragment Count               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Tx Fragment Cnt|               Multicast Tx Count              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Mcast Tx Cnt  |                  Failed Count                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Failed Count  |                  Retry Count                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Retry Count  |             Multiple Retry Count              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Multi Retry Cnt|             Frame Duplicate Count             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Frame Dup Cnt |               RTS Success Count               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |RTS Success Cnt|               RTS Failure Count               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |RTS Failure Cnt|               ACK Failure Count               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |ACK Failure Cnt|               Rx Fragment Count               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Rx Fragment Cnt|               Multicast RX Count              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Mcast Rx Cnt  |                FCS Error  Count               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | FCS Error  Cnt|                 Tx Frame Count                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Tx Frame Cnt  |               Decryption Errors               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Decryption Errs|
      +-+-+-+-+-+-+-+-+

   Type:   38 for Statistics

   Length:   57

Top      Up      ToC       Page 97 
   Radio ID:   An 8-bit value representing the radio.

   Tx Fragment Count:   A 32-bit value representing the number of
      fragmented frames transmitted.

   Multicast Tx Count:   A 32-bit value representing the number of
      multicast frames transmitted.

   Failed Count:   A 32-bit value representing the transmit excessive
      retries.

   Retry Count:   A 32-bit value representing the number of transmit
      retries.

   Multiple Retry Count:   A 32-bit value representing the number of
      transmits that required more than one retry.

   Frame Duplicate Count:   A 32-bit value representing the duplicate
      frames received.

   RTS Success Count:   A 32-bit value representing the number of
      successfully transmitted Ready To Send (RTS).

   RTS Failure Count:   A 32-bit value representing the failed
      transmitted RTS.

   ACK Failure Count:   A 32-bit value representing the number of failed
      acknowledgements.

   Rx Fragment Count:   A 32-bit value representing the number of
      fragmented frames received.

   Multicast RX Count:   A 32-bit value representing the number of
      multicast frames received.

   FCS Error Count:   A 32-bit value representing the number of Frame
      Check Sequence (FCS) failures.

   Decryption Errors:   A 32-bit value representing the number of
      Decryption errors that occurred on the WTP.  Note that this field
      is only valid in cases where the WTP provides encryption/
      decryption services.



(page 97 continued on part 5)

Next RFC Part