tech-invite   World Map     

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

RFC 5415

 
 
 

Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Specification

Part 6 of 6, p. 131 to 155
Prev RFC Part

 


prevText      Top      Up      ToC       Page 131 
10.  Station Session Management

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

10.1.  Station Configuration Request

   The Station Configuration Request message is used to create, modify,
   or delete station session state on a WTP.  The message is sent by the
   AC to the WTP, and MAY contain one or more message elements.  The
   message elements for this CAPWAP Control message include information
   that is generally highly technology specific.  Refer to the
   appropriate binding document for definitions of the messages elements
   that are included in this control message.

   The Station Configuration Request message is sent by the AC when in
   the Run state.  The WTP does not transmit this message.

Top      Up      ToC       Page 132 
   The following CAPWAP Control message elements MAY be included in the
   Station Configuration Request message.  More than one of each message
   element listed MAY be included in the Station Configuration Request
   message:

   o  Add Station, see Section 4.6.8

   o  Delete Station, see Section 4.6.20

   o  Vendor Specific Payload, see Section 4.6.39

10.2.  Station Configuration Response

   The Station Configuration Response message is used to acknowledge a
   previously received Station Configuration Request message.

   The Station Configuration Response message is sent by the WTP when in
   the Run state.  The AC does not transmit this message.

   The following message element MUST be present in the Station
   Configuration Response message:

   o  Result Code, see Section 4.6.35

   The following message element MAY be included in the Station
   Configuration Response message:

   o  Vendor Specific Payload, see Section 4.6.39

   The Result Code message element indicates that the requested
   configuration was successfully applied, or that an error related to
   processing of the Station Configuration Request message occurred on
   the WTP.

11.  NAT Considerations

   There are three specific situations in which a NAT deployment may be
   used in conjunction with a CAPWAP-enabled deployment.  The first
   consists of a configuration in which a single WTP is behind a NAT
   system.  Since all communication is initiated by the WTP, and all
   communication is performed over IP using two UDP ports, the protocol
   easily traverses NAT systems in this configuration.

   In the second case, two or more WTPs are deployed behind the same NAT
   system.  Here, the AC would receive multiple connection requests from
   the same IP address, and therefore cannot use the WTP's IP address
   alone to bind the CAPWAP Control and Data channel.  The CAPWAP Data
   Check state, which establishes the data plane connection and

Top      Up      ToC       Page 133 
   communicates the CAPWAP Data Channel Keep-Alive, includes the Session
   Identifier message element, which is used to bind the control and
   data plane.  Use of the Session Identifier message element enables
   the AC to match the control and data plane flows from multiple WTPs
   behind the same NAT system (multiple WTPs sharing the same IP
   address).  CAPWAP implementations MUST also use DTLS session
   information on any encrypted CAPWAP channel to validate the source of
   both the control and data plane, as described in Section 12.2.

   In the third configuration, the AC is deployed behind a NAT.  In this
   case, the AC is not reachable by the WTP unless a specific rule has
   been configured on the NAT to translate the address and redirect
   CAPWAP messages to the AC.  This deployment presents two issues.
   First, an AC communicates its interfaces and corresponding WTP load
   using the CAPWAP Control IPv4 Address and CAPWAP Control IPv6 Address
   message elements.  This message element is mandatory, but contains IP
   addresses that are only valid in the private address space used by
   the AC, which is not reachable by the WTP.  The WTP MUST NOT utilize
   the information in these message elements if it detects a NAT (as
   described in the CAPWAP Transport Protocol message element in
   Section 4.6.14).  Second, since the addresses cannot be used by the
   WTP, this effectively disables the load-balancing capabilities (see
   Section 6.1) of the CAPWAP protocol.  Alternatively, the AC could
   have a configured NAT'ed address, which it would include in either of
   the two control address message elements, and the NAT would need to
   be configured accordingly.

   In order for a CAPWAP WTP or AC to detect whether a middlebox is
   present, both the Join Request (see Section 6.1) and the Join
   Response (see Section 6.2) include either the CAPWAP Local IPv4
   Address (see Section 4.6.11) or the CAPWAP Local IPv6 Address (see
   Section 4.6.12) message element.  Upon receiving one of these
   messages, if the packet's source IP address differs from the address
   found in either one of these message elements, it indicates that a
   middlebox is present.

   In order for CAPWAP to be compatible with potential middleboxes in
   the network, CAPWAP implementations MUST send return traffic from the
   same port on which it received traffic from a given peer.  Further,
   any unsolicited requests generated by a CAPWAP node MUST be sent on
   the same port.

   Note that this middlebox detection technique is not foolproof.  If
   the public IP address assigned to the NAT is identical to the private
   IP address used by the AC, detection by the WTP would fail.  This
   failure can lead to various protocol errors, so it is therefore
   necessary for deployments to ensure that the NAT's IP address is not
   the same as the ACs.

Top      Up      ToC       Page 134 
   The CAPWAP protocol allows for all of the AC identities supporting a
   group of WTPs to be communicated through the AC List message element.
   This feature MUST be ignored by the WTP when it detects the AC is
   behind a middlebox.

   The CAPWAP protocol allows an AC to configure a static IP address on
   a WTP using the WTP Static IP Address Information message element.
   This message element 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.  The IP address embedded within this message element is
   different from the public IP address seen by the AC.

12.  Security Considerations

   This section describes security considerations for the CAPWAP
   protocol.  It also provides security recommendations for protocols
   used in conjunction with CAPWAP.

12.1.  CAPWAP Security

   As it is currently specified, the CAPWAP protocol sits between the
   security mechanisms specified by the wireless link layer protocol
   (e.g., IEEE 802.11i) and Authentication, Authorization, and
   Accounting (AAA).  One goal of CAPWAP is to bootstrap trust between
   the STA and WTP using a series of preestablished trust relationships:

         STA            WTP           AC            AAA
         ==============================================

                            DTLS Cred     AAA Cred
                         <------------><------------->

                         EAP Credential
          <------------------------------------------>

           wireless link layer
           (e.g., 802.11 PTK)
          <--------------> or
          <--------------------------->
              (derived)

                       Figure 12: STA Session Setup

Top      Up      ToC       Page 135 
   Within CAPWAP, DTLS is used to secure the link between the WTP and
   AC.  In addition to securing control messages, it's also a link in
   this chain of trust for establishing link layer keys.  Consequently,
   much rests on the security of DTLS.

   In some CAPWAP deployment scenarios, there are two channels between
   the WTP and AC: the control channel, carrying CAPWAP Control
   messages, and the data channel, over which client data packets are
   tunneled between the AC and WTP.  Typically, the control channel is
   secured by DTLS, while the data channel is not.

   The use of parallel protected and unprotected channels deserves
   special consideration, but does not create a threat.  There are two
   potential concerns: attempting to convert protected data into
   unprotected data and attempting to convert un-protected data into
   protected data.  These concerns are addressed below.

12.1.1.  Converting Protected Data into Unprotected Data

   Since CAPWAP does not support authentication-only ciphers (i.e., all
   supported ciphersuites include encryption and authentication), it is
   not possible to convert protected data into unprotected data.  Since
   encrypted data is (ideally) indistinguishable from random data, the
   probability of an encrypted packet passing for a well-formed packet
   is effectively zero.

12.1.2.  Converting Unprotected Data into Protected Data (Insertion)

   The use of message authentication makes it impossible for the
   attacker to forge protected records.  This makes conversion of
   unprotected records to protected records impossible.

12.1.3.  Deletion of Protected Records

   An attacker could remove protected records from the stream, though
   not undetectably so, due the built-in reliability of the underlying
   CAPWAP protocol.  In the worst case, the attacker would remove the
   same record repeatedly, resulting in a CAPWAP session timeout and
   restart.  This is effectively a DoS attack, and could be accomplished
   by a man in the middle regardless of the CAPWAP protocol security
   mechanisms chosen.

12.1.4.   Insertion of Unprotected Records

   An attacker could inject packets into the unprotected channel, but
   this may become evident if sequence number desynchronization occurs
   as a result.  Only if the attacker is a man in the middle (MITM) can

Top      Up      ToC       Page 136 
   packets be inserted undetectably.  This is a consequence of that
   channel's lack of protection, and not a new threat resulting from the
   CAPWAP security mechanism.

12.1.5.  Use of MD5

   The Image Information message element (Section 4.6.28) makes use of
   MD5 to compute the hash field.  The authenticity and integrity of the
   image file is protected by DTLS, and in this context, MD5 is not used
   as a cryptographically secure hash, but just as a basic checksum.
   Therefore, the use of MD5 is not considered a security vulnerability,
   and no mechanisms for algorithm agility are provided.

12.1.6.  CAPWAP Fragmentation

   RFC 4963 [RFC4963] describes a possible security vulnerability where
   a malicious entity can "corrupt" a flow by injecting fragments.  By
   sending "high" fragments (those with offset greater than zero) with a
   forged source address, the attacker can deliberately cause
   corruption.  The use of DTLS on the CAPWAP Data channel can be used
   to avoid this possible vulnerability.

12.2.  Session ID Security

   Since DTLS does not export a unique session identifier, there can be
   no explicit protocol binding between the DTLS layer and CAPWAP layer.
   As a result, implementations MUST provide a mechanism for performing
   this binding.  For example, an AC MUST NOT associate decrypted DTLS
   control packets with a particular WTP session based solely on the
   Session ID in the packet header.  Instead, identification should be
   done based on which DTLS session decrypted the packet.  Otherwise,
   one authenticated WTP could spoof another authenticated WTP by
   altering the Session ID in the encrypted CAPWAP Header.

   It should be noted that when the CAPWAP Data channel is unencrypted,
   the WTP Session ID is exposed and possibly known to adversaries and
   other WTPs.  This would allow the forgery of the source of data-
   channel traffic.  This, however, should not be a surprise for
   unencrypted data channels.  When the data channel is encrypted, the
   Session ID is not exposed, and therefore can safely be used to
   associate a data and control channel.  The 128-bit length of the
   Session ID mitigates online guessing attacks where an adversarial,
   authenticated WTP tries to correlate his own data channel with
   another WTP's control channel.  Note that for encrypted data
   channels, the Session ID should only be used for correlation for the
   first packet immediately after the initial DTLS handshake.  Future
   correlation should instead be done via identification of a packet's
   DTLS session.

Top      Up      ToC       Page 137 
12.3.  Discovery or DTLS Setup Attacks

   Since the Discovery Request messages are sent in the clear, it is
   important that AC implementations NOT assume that receiving a
   Discovery Request message from a WTP implies that the WTP has
   rebooted, and consequently tear down any active DTLS sessions.
   Discovery Request messages can easily be spoofed by malicious
   devices, so it is important that the AC maintain two separate sets of
   states for the WTP until the DTLSSessionEstablished notification is
   received, indicating that the WTP was authenticated.  Once a new DTLS
   session is successfully established, any state referring to the old
   session can be cleared.

   Similarly, when the AC is entering the DTLS Setup phase, it SHOULD
   NOT assume that the WTP has reset, and therefore should not discard
   active state until the DTLS session has been successfully
   established.  While the HelloVerifyRequest provides some protection
   against denial-of-service (DoS) attacks on the AC, an adversary
   capable of receiving packets at a valid address (or a malfunctioning
   or misconfigured WTP) may repeatedly attempt DTLS handshakes with the
   AC, potentially creating a resource shortage.  If either the
   FailedDTLSSessionCount or the FailedDTLSAuthFailCount counter reaches
   the value of MaxFailedDTLSSessionRetry variable (see Section 4.8),
   implementations MAY choose to rate-limit new DTLS handshakes for some
   period of time.  It is RECOMMENDED that implementations choosing to
   implement rate-limiting use a random discard technique, rather than
   mimicking the WTP's sulking behavior.  This will ensure that messages
   from valid WTPs will have some probability of eliciting a response,
   even in the face of a significant DoS attack.

   Some CAPWAP implementations may wish to restrict the DTLS setup
   process to only those peers that have been configured in the access
   control list, authorizing only those clients to initiate a DTLS
   handshake.  Note that the impact of this on mitigating denial-of-
   service attacks against the DTLS layer is minimal, because DTLS
   already uses client-side cookies to minimize processor consumption
   attacks.

12.4.  Interference with a DTLS Session

   If a WTP or AC repeatedly receives packets that fail DTLS
   authentication or decryption, this could indicate a DTLS
   desynchronization between the AC and WTP, a link prone to
   undetectable bit errors, or an attacker trying to disrupt a DTLS
   session.

Top      Up      ToC       Page 138 
   In the state machine (section 2.3), transitions to the DTLS Tear Down
   (TD) state can be triggered by frequently receiving DTLS packets with
   authentication or decryption errors.  The threshold or technique for
   deciding when to move to the tear down state should be chosen
   carefully.  Being able to easily transition to DTLS TD allows easy
   detection of malfunctioning devices, but allows for denial-of-service
   attacks.  Making it difficult to transition to DTLS TD prevents
   denial-of-service attacks, but makes it more difficult to detect and
   reset a malfunctioning session.  Implementers should set this policy
   with care.

12.5.  CAPWAP Pre-Provisioning

   In order for CAPWAP to establish a secure communication with a peer,
   some level of pre-provisioning on both the WTP and AC is necessary.
   This section will detail the minimal number of configuration
   parameters.

   When using pre-shared keys, it is necessary to configure the pre-
   shared key for each possible peer with which a DTLS session may be
   established.  To support this mode of operation, one or more entries
   of the following table may be configured on either the AC or WTP:

   o  Identity: The identity of the peering AC or WTP.  This format MAY
      be in the form of either an IP address or host name (the latter of
      which needs to be resolved to an IP address using DNS).

   o  Key: The pre-shared key for use with the peer when establishing
      the DTLS session (see Section 12.6 for more information).

   o  PSK Identity: Identity hint associated with the provisioned key
      (see Section 2.4.4.4 for more information).

   When using certificates, the following items need to be pre-
   provisioned:

   o  Device Certificate: The local device's certificate (see
      Section 12.7 for more information).

   o  Trust Anchor: Trusted root certificate chain used to validate any
      certificate received from CAPWAP peers.  Note that one or more
      root certificates MAY be configured on a given device.

   Regardless of the authentication method, the following item needs to
   be pre-provisioned:

Top      Up      ToC       Page 139 
   o  Access Control List: The access control list table contains the
      identities of one or more CAPWAP peers, along with a rule.  The
      rule is used to determine whether communication with the peer is
      permitted (see Section 2.4.4.3 for more information).

12.6.  Use of Pre-Shared Keys in CAPWAP

   While use of pre-shared keys may provide deployment and provisioning
   advantages not found in public-key-based deployments, it also
   introduces a number of operational and security concerns.  In
   particular, because the keys must typically be entered manually, it
   is common for people to base them on memorable words or phrases.
   These are referred to as "low entropy passwords/passphrases".

   Use of low-entropy pre-shared keys, coupled with the fact that the
   keys are often not frequently updated, tends to significantly
   increase exposure.  For these reasons, the following recommendations
   are made:

   o  When DTLS is used with a pre-shared key (PSK) ciphersuite, each
      WTP SHOULD have a unique PSK.  Since WTPs will likely be widely
      deployed, their physical security is not guaranteed.  If PSKs are
      not unique for each WTP, key reuse would allow the compromise of
      one WTP to result in the compromise of others.

   o  Generating PSKs from low entropy passwords is NOT RECOMMENDED.

   o  It is RECOMMENDED that implementations that allow the
      administrator to manually configure the PSK also provide a
      capability for generation of new random PSKs, taking RFC 4086
      [RFC4086] into account.

   o  Pre-shared keys SHOULD be periodically updated.  Implementations
      MAY facilitate this by providing an administrative interface for
      automatic key generation and periodic update, or it MAY be
      accomplished manually instead.

   Every pairwise combination of WTP and AC on the network SHOULD have a
   unique PSK.  This prevents the domino effect (see "Guidance for
   Authentication, Authorization, and Accounting (AAA) Key Management"
   [RFC4962]).  If PSKs are tied to specific WTPs, then knowledge of the
   PSK implies a binding to a specified identity that can be authorized.

   If PSKs are shared, this binding between device and identity is no
   longer possible.  Compromise of one WTP can yield compromise of
   another WTP, violating the CAPWAP security hierarchy.  Consequently,
   sharing keys between WTPs is NOT RECOMMENDED.

Top      Up      ToC       Page 140 
12.7.  Use of Certificates in CAPWAP

   For public-key-based DTLS deployments, each device SHOULD have unique
   credentials, with an extended key usage authorizing the device to act
   as either a WTP or AC.  If devices do not have unique credentials, it
   is possible that by compromising one device, any other device using
   the same credential may also be considered to be compromised.

   Certificate validation involves checking a large variety of things.
   Since the necessary things to validate are often environment-
   specific, many are beyond the scope of this document.  In this
   section, we provide some basic guidance on certificate validation.

   Each device is responsible for authenticating and authorizing devices
   with which they communicate.  Authentication entails validation of
   the chain of trust leading to the peer certificate, followed by the
   peer certificate itself.  Implementations SHOULD also provide a
   secure method for verifying that the credential in question has not
   been revoked.

   Note that if the WTP relies on the AC for network connectivity (e.g.,
   the AC is a Layer 2 switch to which the WTP is directly connected),
   the WTP may not be able to contact an Online Certificate Status
   Protocol (OCSP) server or otherwise obtain an up-to-date Certificate
   Revocation List (CRL) if a compromised AC doesn't explicitly permit
   this.  This cannot be avoided, except through effective physical
   security and monitoring measures at the AC.

   Proper validation of certificates typically requires checking to
   ensure the certificate has not yet expired.  If devices have a real-
   time clock, they SHOULD verify the certificate validity dates.  If no
   real-time clock is available, the device SHOULD make a best-effort
   attempt to validate the certificate validity dates through other
   means.  Failure to check a certificate's temporal validity can make a
   device vulnerable to man-in-the-middle attacks launched using
   compromised, expired certificates, and therefore devices should make
   every effort to perform this validation.

12.8.  Use of MAC Address in CN Field

   The CAPWAP protocol is an evolution of an existing protocol [LWAPP],
   which is implemented on a large number of already deployed ACs and
   WTPs.  Every one of these devices has an existing X.509 certificate,
   which is provisioned at the time of manufacturing.  These X.509
   certificates use the device's MAC address in the Common Name (CN)
   field.  It is well understood that encoding the MAC address in the CN
   field is less than optimal, and using the SubjectAltName field would
   be preferable.  However, at the time of publication, there is no URN

Top      Up      ToC       Page 141 
   specification that allows for the MAC address to be used in the
   SubjectAltName field.  As such a specification is published by the
   IETF, future versions of the CAPWAP protocol MAY require support for
   the new URN scheme.

12.9.  AAA Security

   The AAA protocol is used to distribute Extensible Authentication
   Protocol (EAP) keys to the ACs, and consequently its security is
   important to the overall system security.  When used with Transport
   Layer Security (TLS) or IPsec, security guidelines specified in RFC
   3539 [RFC3539] SHOULD be followed.

   In general, the link between the AC and AAA server SHOULD be secured
   using a strong ciphersuite keyed with mutually authenticated session
   keys.  Implementations SHOULD NOT rely solely on Basic RADIUS shared
   secret authentication as it is often vulnerable to dictionary
   attacks, but rather SHOULD use stronger underlying security
   mechanisms.

12.10.  WTP Firmware

   The CAPWAP protocol defines a mechanism by which the AC downloads new
   firmware to the WTP.  During the session establishment process, the
   WTP provides information about its current firmware to the AC.  The
   AC then decides whether the WTP's firmware needs to be updated.  It
   is important to note that the CAPWAP specification makes the explicit
   assumption that the WTP is providing the correct firmware version to
   the AC, and is therefore not lying.  Further, during the firmware
   download process, the CAPWAP protocol does not provide any mechanisms
   to recognize whether the WTP is actually storing the firmware for
   future use.

13.  Operational Considerations

   The CAPWAP protocol assumes that it is the only configuration
   interface to the WTP to configure parameters that are specified in
   the CAPWAP specifications.  While the use of a separate management
   protocol MAY be used for the purposes of monitoring the WTP directly,
   configuring the WTP through a separate management interface is not
   recommended.  Configuring the WTP through a separate protocol, such
   as via a command line interface (CLI) or Simple Network Management
   Protocol (SNMP), could lead to the AC state being out of sync with
   the WTP.

Top      Up      ToC       Page 142 
   The CAPWAP protocol does not deal with the management of the ACs.
   The AC is assumed to be configured through some separate management
   interface, which could be via a proprietary CLI, SNMP, Network
   Configuration Protocol (NETCONF), or some other management protocol.

   The CAPWAP protocol's control channel is fairly lightweight from a
   traffic perspective.  Once the WTP has been configured, the WTP sends
   periodic statistics.  Further, the specification calls for a keep-
   alive packet to be sent on the protocol's data channel to make sure
   that any possible middleboxes (e.g., NAT) maintain their UDP state.
   The overhead associated with the control and data channel is not
   expected to impact network traffic.  That said, the CAPWAP protocol
   does allow for the frequency of these packets to be modified through
   the DataChannelKeepAlive and StatisticsTimer (see Section 4.7.2 and
   Section 4.7.14, respectively).

14.  Transport Considerations

   The CAPWAP WG carefully considered the congestion control
   requirements of the CAPWAP protocol, both for the CAPWAP Control and
   Data channels.

   CAPWAP specifies a single-threaded command/response protocol to be
   used on the control channel, and we have specified that an
   exponential back-off algorithm should be used when commands are
   retransmitted.  When CAPWAP runs in its default mode (Local MAC), the
   control channel is the only CAPWAP channel.

   However, CAPWAP can also be run in Split MAC mode, in which case
   there will be a DTLS-encrypted data channel between each WTP and the
   AC.  The WG discussed various options for providing congestion
   control on this channel.  However, due to performance problems with
   TCP when it is run over another congestion control mechanism and the
   fact that the vast majority of traffic run over the CAPWAP Data
   channel is likely to be congestion-controlled IP traffic, the CAPWAP
   WG felt that specifying a congestion control mechanism for the CAPWAP
   Data channel would be more likely to cause problems than to resolve
   any.

   Because there is no congestion control mechanism specified for the
   CAPWAP Data channel, it is RECOMMENDED that non-congestion-controlled
   traffic not be tunneled over CAPWAP.  When a significant amount of
   non-congestion-controlled traffic is expected to be present on a
   WLAN, the CAPWAP connection between the AC and the WTP for that LAN
   should be configured to remain in Local MAC mode with Distribution
   function at the WTP.

Top      Up      ToC       Page 143 
   The lock step nature of the CAPWAP protocol's control channel can
   cause the firmware download process to take some time, depending upon
   the round-trip time (RTT).  This is not expected to be a problem
   since the CAPWAP protocol allows firmware to be downloaded while the
   WTP provides service to wireless clients/devices.

   It is necessary for the WTP and AC to configure their MTU based on
   the capabilities of the path.  See Section 3.5 for more information.

   The CAPWAP protocol mandates support of the Explicit Congestion
   Notification (ECN) through a mode of operation named "limited
   functionality option", detailed in section 9.1.1 of [RFC3168].
   Future versions of the CAPWAP protocol should consider mandating
   support for the "full functionality option".

15.  IANA Considerations

   This section details the actions that IANA has taken in preparation
   for publication of the specification.  Numerous registries have been
   created, and the contents, document action (see [RFC5226], and
   registry format are all included below.  Note that in cases where bit
   fields are referred to, the bit numbering is left to right, where the
   leftmost bit is labeled as bit zero (0).

   For future registration requests where an Expert Review is required,
   a Designated Expert should be consulted, which is appointed by the
   responsible IESG Area Director.  The intention is that any allocation
   will be accompanied by a published RFC, but given that other SDOs may
   want to create standards built on top of CAPWAP, a document the
   Designated Expert can review is also acceptable.  IANA should allow
   for allocation of values prior to documents being approved for
   publication, so the Designated Expert can approve allocations once it
   seems clear that publication will occur.  The Designated Expert will
   post a request to the CAPWAP WG mailing list (or a successor
   designated by the Area Director) for comment and review.  Before a
   period of 30 days has passed, the Designated Expert will either
   approve or deny the registration request and publish a notice of the
   decision to the CAPWAP WG mailing list or its successor, as well as
   informing IANA.  A denial notice must be justified by an explanation,
   and in the cases where it is possible, concrete suggestions on how
   the request can be modified so as to become acceptable should be
   provided.

15.1.  IPv4 Multicast Address

   IANA has registered a new IPv4 multicast address called "capwap-ac"
   from the Internetwork Control Block IPv4 multicast address registry;
   see Section 3.3.

Top      Up      ToC       Page 144 
15.2.  IPv6 Multicast Address

   IANA has registered a new organization local multicast address called
   the "All ACs multicast address" in the Variable Scope IPv6 multicast
   address registry; see Section 3.3.

15.3.  UDP Port

   IANA registered two new UDP Ports, which are organization-local
   multicast addresses, in the registered port numbers registry; see
   Section 3.1.  The following values have been registered:

   Keyword         Decimal    Description                  References
   -------         -------    -----------                  ----------
   capwap-control  5246/udp   CAPWAP Control Protocol      This Document
   capwap-data     5247/udp   CAPWAP Data Protocol         This Document


15.4.  CAPWAP Message Types

   The Message Type field in the CAPWAP Header (see Section 4.5.1.1) is
   used to identify the operation performed by the message.  There are
   multiple namespaces, which are identified via the first three octets
   of the field containing the IANA Enterprise Number [RFC5226].

   IANA maintains the CAPWAP Message Types registry for all message
   types whose Enterprise Number is set to zero (0).  The namespace is 8
   bits (0-255), where the value of zero (0) is reserved and must not be
   assigned.  The values one (1) through 26 are allocated in this
   specification, and can be found in Section 4.5.1.1.  Any new
   assignments of a CAPWAP Message Type whose Enterprise Number is set
   to zero (0) requires an Expert Review.  The registry maintained by
   IANA has the following format:

           CAPWAP Control Message           Message Type     Reference
                                              Value

15.5.  CAPWAP Header Flags

   The Flags field in the CAPWAP Header (see Section 4.3) is 9 bits in
   length and is used to identify any special treatment related to the
   message.  This specification defines bits zero (0) through five (5),
   while bits six (6) through eight (8) are reserved.  There are
   currently three unused, reserved bits that are managed by IANA and
   whose assignment require an Expert Review.  IANA created the CAPWAP
   Header Flags registry, whose format is:

           Flag Field Name                   Bit Position    Reference

Top      Up      ToC       Page 145 
15.6.  CAPWAP Control Message Flags

   The Flags field in the CAPWAP Control Message header (see
   Section 4.5.1.4) is used to identify any special treatment related to
   the control message.  There are currently eight (8) unused, reserved
   bits.  The assignment of these bits is managed by IANA and requires
   an Expert Review.  IANA created the CAPWAP Control Message Flags
   registry, whose format is:

           Flag Field Name                   Bit Position    Reference

15.7.  CAPWAP Message Element Type

   The Type field in the CAPWAP Message Element header (see Section 4.6)
   is used to identify the data being transported.  The namespace is 16
   bits (0-65535), where the value of zero (0) is reserved and must not
   be assigned.  The values one (1) through 53 are allocated in this
   specification, and can be found in Section 4.5.1.1.

   The 16-bit namespace is further divided into blocks of addresses that
   are reserved for specific CAPWAP wireless bindings.  The following
   blocks are reserved:

         CAPWAP Protocol Message Elements                   1 - 1023
         IEEE 802.11 Message Elements                    1024 - 2047
         EPCGlobal Message Elements                      3072 - 4095

   This namespace is managed by IANA and assignments require an Expert
   Review.  IANA created the CAPWAP Message Element Type registry, whose
   format is:

           CAPWAP Message Element           Type Value       Reference

15.8.  CAPWAP Wireless Binding Identifiers

   The Wireless Binding Identifier (WBID) field in the CAPWAP Header
   (see Section 4.3) is used to identify the wireless technology
   associated with the packet.  This specification allocates the values
   one (1) and three (3).  Due to the limited address space available, a
   new WBID request requires Expert Review.  IANA created the CAPWAP
   Wireless Binding Identifier registry, whose format is:

           CAPWAP Wireless Binding Identifier  Type Value      Reference

Top      Up      ToC       Page 146 
15.9.  AC Security Types

   The Security field in the AC Descriptor message element (see
   Section 4.6.1) is 8 bits in length and is used to identify the
   authentication methods available on the AC.  This specification
   defines bits five (5) and six (6), while bits zero (0) through four
   (4) as well as bit seven (7) are reserved and unused.  These reserved
   bits are managed by IANA and assignment requires Standards Action.
   IANA created the AC Security Types registry, whose format is:

           AC Security Type                  Bit Position    Reference

15.10.  AC DTLS Policy

   The DTLS Policy field in the AC Descriptor message element (see
   Section 4.6.1) is 8 bits in length and is used to identify whether
   the CAPWAP Data Channel is to be secured.  This specification defines
   bits five (5) and six (6), while bits zero (0) through four (4) as
   well as bit seven (7) are reserved and unused.  These reserved bits
   are managed by IANA and assignment requires Standards Action.  IANA
   created the AC DTLS Policy registry, whose format is:

           AC DTLS Policy                    Bit Position    Reference

15.11.  AC Information Type

   The Information Type field in the AC Descriptor message element (see
   Section 4.6.1) is used to represent information about the AC.  The
   namespace is 16 bits (0-65535), where the value of zero (0) is
   reserved and must not be assigned.  This field, combined with the AC
   Information Vendor ID, allows vendors to use a private namespace.
   This specification defines the AC Information Type namespace when the
   AC Information Vendor ID is set to zero (0), for which the values
   four (4) and five (5) are allocated in this specification, and can be
   found in Section 4.6.1.  This namespace is managed by IANA and
   assignments require an Expert Review.  IANA created the AC
   Information Type registry, whose format is:

           AC Information Type              Type Value       Reference

15.12.  CAPWAP Transport Protocol Types

   The Transport field in the CAPWAP Transport Protocol message element
   (see Section 4.6.14) is used to identify the transport to use for the
   CAPWAP Data Channel.  The namespace is 8 bits (0-255), where the
   value of zero (0) is reserved and must not be assigned.  The values
   one (1) and two (2) are allocated in this specification, and can be

Top      Up      ToC       Page 147 
   found in Section 4.6.14.  This namespace is managed by IANA and
   assignments require an Expert Review.  IANA created the CAPWAP
   Transport Protocol Types registry, whose format is:

           CAPWAP Transport Protocol Type   Type Value       Reference

15.13.  Data Transfer Type

   The Data Type field in the Data Transfer Data message element (see
   Section 4.6.15) and Image Data message element (see Section 4.6.26)
   is used to provide information about the data being carried.  The
   namespace is 8 bits (0-255), where the value of zero (0) is reserved
   and must not be assigned.  The values one (1), two (2), and five (5)
   are allocated in this specification, and can be found in
   Section 4.6.15.  This namespace is managed by IANA and assignments
   require an Expert Review.  IANA created the Data Transfer Type
   registry, whose format is:

           Data Transfer Type               Type Value       Reference

15.14.  Data Transfer Mode

   The Data Mode field in the Data Transfer Data message element (see
   Section 4.6.15) and Data Transfer Mode message element (see
   Section 15.14) is used to provide information about the data being
   carried.  The namespace is 8 bits (0-255), where the value of zero
   (0) is reserved and must not be assigned.  The values one (1) and two
   (2) are allocated in this specification, and can be found in
   Section 15.14.  This namespace is managed by IANA and assignments
   require an Expert Review.  IANA created the Data Transfer Mode
   registry, whose format is:

           Data Transfer Mode               Type Value       Reference

15.15.  Discovery Types

   The Discovery Type field in the Discovery Type message element (see
   Section 4.6.21) is used by the WTP to indicate to the AC how it was
   discovered.  The namespace is 8 bits (0-255).  The values zero (0)
   through four (4) are allocated in this specification and can be found
   in Section 4.6.21.  This namespace is managed by IANA and assignments
   require an Expert Review.  IANA created the Discovery Types registry,
   whose format is:

           Discovery Types                  Type Value       Reference

Top      Up      ToC       Page 148 
15.16.  ECN Support

   The ECN Support field in the ECN Support message element (see
   Section 4.6.25) is used by the WTP to represent its ECN Support.  The
   namespace is 8 bits (0-255).  The values zero (0) and one (1) are
   allocated in this specification, and can be found in Section 4.6.25.
   This namespace is managed by IANA and assignments require an Expert
   Review.  IANA created the ECN Support registry, whose format is:

           ECN Support                      Type Value       Reference

15.17.  Radio Admin State

   The Radio Admin field in the Radio Administrative State message
   element (see Section 4.6.33) is used by the WTP to represent the
   state of its radios.  The namespace is 8 bits (0-255), where the
   value of zero (0) is reserved and must not be assigned.  The values
   one (1) and two (2) are allocated in this specification, and can be
   found in Section 4.6.33.  This namespace is managed by IANA and
   assignments require an Expert Review.  IANA created the Radio Admin
   State registry, whose format is:

           Radio Admin State                Type Value       Reference

15.18.  Radio Operational State

   The State field in the Radio Operational State message element (see
   Section 4.6.34) is used by the WTP to represent the operational state
   of its radios.  The namespace is 8 bits (0-255), where the value of
   zero (0) is reserved and must not be assigned.  The values one (1)
   and two (2) are allocated in this specification, and can be found in
   Section 4.6.34.  This namespace is managed by IANA and assignments
   require an Expert Review.  IANA created the Radio Operational State
   registry, whose format is:

           Radio Operational State          Type Value       Reference

15.19.  Radio Failure Causes

   The Cause field in the Radio Operational State message element (see
   Section 4.6.34) is used by the WTP to represent the reason a radio
   may have failed.  The namespace is 8 bits (0-255), where the value of
   zero (0) through three (3) are allocated in this specification, and
   can be found in Section 4.6.34.  This namespace is managed by IANA
   and assignments require an Expert Review.  IANA created the Radio
   Failure Causes registry, whose format is:

           Radio Failure Causes             Type Value       Reference

Top      Up      ToC       Page 149 
15.20.  Result Code

   The Result Code field in the Result Code message element (see
   Section 4.6.35) is used to indicate the success or failure of a
   CAPWAP Control message.  The namespace is 32 bits (0-4294967295),
   where the value of zero (0) through 22 are allocated in this
   specification, and can be found in Section 4.6.35.  This namespace is
   managed by IANA and assignments require an Expert Review.  IANA
   created the Result Code registry, whose format is:

           Result Code                      Type Value       Reference

15.21.  Returned Message Element Reason

   The Reason field in the Returned Message Element message element (see
   Section 4.6.36) is used to indicate the reason why a message element
   was not processed successfully.  The namespace is 8 bits (0-255),
   where the value of zero (0) is reserved and must not be assigned.
   The values one (1) through four (4) are allocated in this
   specification, and can be found in Section 4.6.36.  This namespace is
   managed by IANA and assignments require an Expert Review.  IANA
   created the Returned Message Element Reason registry, whose format
   is:

           Returned Message Element Reason  Type Value       Reference

15.22.  WTP Board Data Type

   The Board Data Type field in the WTP Board Data message element (see
   Section 4.6.40) is used to represent information about the WTP
   hardware.  The namespace is 16 bits (0-65535).  The WTP Board Data
   Type values zero (0) through four (4) are allocated in this
   specification, and can be found in Section 4.6.40.  This namespace is
   managed by IANA and assignments require an Expert Review.  IANA
   created the WTP Board Data Type registry, whose format is:

           WTP Board Data Type              Type Value       Reference

15.23.  WTP Descriptor Type

   The Descriptor Type field in the WTP Descriptor message element (see
   Section 4.6.41) is used to represent information about the WTP
   software.  The namespace is 16 bits (0-65535).  This field, combined
   with the Descriptor Vendor ID, allows vendors to use a private
   namespace.  This specification defines the WTP Descriptor Type
   namespace when the Descriptor Vendor ID is set to zero (0), for which
   the values zero (0) through three (3) are allocated in this

Top      Up      ToC       Page 150 
   specification, and can be found in Section 4.6.41.  This namespace is
   managed by IANA and assignments require an Expert Review.  IANA
   created the WTP Board Data Type registry, whose format is:

           WTP Descriptor Type              Type Value       Reference

15.24.  WTP Fallback Mode

   The Mode field in the WTP Fallback message element (see
   Section 4.6.42) is used to indicate the type of AC fallback mechanism
   the WTP should employ.  The namespace is 8 bits (0-255), where the
   value of zero (0) is reserved and must not be assigned.  The values
   one (1) and two (2) are allocated in this specification, and can be
   found in Section 4.6.42.  This namespace is managed by IANA and
   assignments require an Expert Review.  IANA created the WTP Fallback
   Mode registry, whose format is:

           WTP Fallback Mode                Type Value       Reference

15.25.  WTP Frame Tunnel Mode

   The Tunnel Type field in the WTP Frame Tunnel Mode message element
   (see Section 4.6.43) is 8 bits and is used to indicate the type of
   tunneling to use between the WTP and the AC.  This specification
   defines bits four (4) through six (6), while bits zero (0) through
   three (3) as well as bit seven (7) are reserved and unused.  These
   reserved bits are managed by IANA and assignment requires an Expert
   Review.  IANA created the WTP Frame Tunnel Mode registry, whose
   format is:

           WTP Frame Tunnel Mode             Bit Position    Reference

15.26.  WTP MAC Type

   The MAC Type field in the WTP MAC Type message element (see
   Section 4.6.44) is used to indicate the type of MAC to use in
   tunneled frames between the WTP and the AC.  The namespace is 8 bits
   (0-255), where the value of zero (0) through two (2) are allocated in
   this specification, and can be found in Section 4.6.44.  This
   namespace is managed by IANA and assignments require an Expert
   Review.  IANA created the WTP MAC Type registry, whose format is:

           WTP MAC Type                     Type Value       Reference

Top      Up      ToC       Page 151 
15.27.  WTP Radio Stats Failure Type

   The Last Failure Type field in the WTP Radio Statistics message
   element (see Section 4.6.46) is used to indicate the last WTP
   failure.  The namespace is 8 bits (0-255), where the value of zero
   (0) through three (3) as well as the value 255 are allocated in this
   specification, and can be found in Section 4.6.46.  This namespace is
   managed by IANA and assignments require an Expert Review.  IANA
   created the WTP Radio Stats Failure Type registry, whose format is:

           WTP Radio Stats Failure Type     Type Value       Reference

15.28.  WTP Reboot Stats Failure Type

   The Last Failure Type field in the WTP Reboot Statistics message
   element (see Section 4.6.47) is used to indicate the last reboot
   reason.  The namespace is 8 bits (0-255), where the value of zero (0)
   through five (5) as well as the value 255 are allocated in this
   specification, and can be found in Section 4.6.47.  This namespace is
   managed by IANA and assignments require an Expert Review.  IANA
   created the WTP Reboot Stats Failure Type registry, whose format is:

           WTP Reboot Stats Failure Type    Type Value       Reference

16.  Acknowledgments

   The following individuals are acknowledged for their contributions to
   this protocol specification: Puneet Agarwal, Abhijit Choudhury, Pasi
   Eronen, Saravanan Govindan, Peter Nilsson, David Perkins, and Yong
   Zhang.

   Michael Vakulenko contributed text to describe how CAPWAP can be used
   over Layer 3 (IP/UDP) networks.

17.  References

17.1.  Normative References

   [RFC1191]          Mogul, J. and S. Deering, "Path MTU discovery",
                      RFC 1191, November 1990.

   [RFC1321]          Rivest, R., "The MD5 Message-Digest Algorithm",
                      RFC 1321, April 1992.

   [RFC1305]          Mills, D., "Network Time Protocol (Version 3)
                      Specification, Implementation", RFC 1305,
                      March 1992.

Top      Up      ToC       Page 152 
   [RFC1981]          McCann, J., Deering, S., and J. Mogul, "Path MTU
                      Discovery for IP version 6", RFC 1981,
                      August 1996.

   [RFC2119]          Bradner, S., "Key words for use in RFCs to
                      Indicate Requirement Levels", BCP 14, RFC 2119,
                      March 1997.

   [RFC2460]          Deering, S. and R. Hinden, "Internet Protocol,
                      Version 6 (IPv6) Specification", RFC 2460,
                      December 1998.

   [RFC2474]          Nichols, K., Blake, S., Baker, F., and D. Black,
                      "Definition of the Differentiated Services Field
                      (DS Field) in the IPv4 and IPv6 Headers",
                      RFC 2474, December 1998.

   [RFC2782]          Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS
                      RR for specifying the location of services (DNS
                      SRV)", RFC 2782, February 2000.

   [RFC3168]          Ramakrishnan, K., Floyd, S., and D. Black, "The
                      Addition of Explicit Congestion Notification (ECN)
                      to IP", RFC 3168, September 2001.

   [RFC3539]          Aboba, B. and J. Wood, "Authentication,
                      Authorization and Accounting (AAA) Transport
                      Profile", RFC 3539, June 2003.

   [RFC3629]          Yergeau, F., "UTF-8, a transformation format of
                      ISO 10646", STD 63, RFC 3629, November 2003.

   [RFC3828]          Larzon, L-A., Degermark, M., Pink, S., Jonsson,
                      L-E., and G. Fairhurst, "The Lightweight User
                      Datagram Protocol (UDP-Lite)", RFC 3828,
                      July 2004.

   [RFC4086]          Eastlake, D., Schiller, J., and S. Crocker,
                      "Randomness Requirements for Security", BCP 106,
                      RFC 4086, June 2005.

   [RFC4279]          Eronen, P. and H. Tschofenig, "Pre-Shared Key
                      Ciphersuites for Transport Layer Security (TLS)",
                      RFC 4279, December 2005.

   [RFC5246]          Dierks, T. and E. Rescorla, "The Transport Layer
                      Security (TLS) Protocol Version 1.2", RFC 5246,
                      August 2008.

Top      Up      ToC       Page 153 
   [RFC4347]          Rescorla, E. and N. Modadugu, "Datagram Transport
                      Layer Security", RFC 4347, April 2006.

   [RFC4821]          Mathis, M. and J. Heffner, "Packetization Layer
                      Path MTU Discovery", RFC 4821, March 2007.

   [RFC4963]          Heffner, J., Mathis, M., and B. Chandler, "IPv4
                      Reassembly Errors at High Data Rates", RFC 4963,
                      July 2007.

   [RFC5226]          Narten, T. and H. Alvestrand, "Guidelines for
                      Writing an IANA Considerations Section in RFCs",
                      BCP 26, RFC 5226, May 2008.

   [RFC5280]          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.

   [ISO.9834-1.1993]  International Organization for Standardization,
                      "Procedures for the operation of OSI registration
                      authorities - part 1: general procedures",
                      ISO Standard 9834-1, 1993.

   [RFC5416]          Calhoun, P., Ed., Montemurro, M., Ed., and D.
                      Stanley, Ed., "Control And Provisioning of
                      Wireless Access Points (CAPWAP) Protocol Binding
                      for IEEE 802.11", RFC 5416, March 2009.

   [RFC5417]          Calhoun, P., "Control And Provisioning of Wireless
                      Access Points (CAPWAP) Access Controller DHCP
                      Option", RFC 5417, March 2009.

   [FRAME-EXT]        IEEE, "IEEE Standard 802.3as-2006", 2005.

17.2.  Informative References

   [RFC3232]          Reynolds, J., "Assigned Numbers: RFC 1700 is
                      Replaced by an On-line Database", RFC 3232,
                      January 2002.

   [RFC3753]          Manner, J. and M. Kojo, "Mobility Related
                      Terminology", RFC 3753, June 2004.

Top      Up      ToC       Page 154 
   [RFC4564]          Govindan, S., Cheng, H., Yao, ZH., Zhou, WH., and
                      L. Yang, "Objectives for Control and Provisioning
                      of Wireless Access Points (CAPWAP)", RFC 4564,
                      July 2006.

   [RFC4962]          Housley, R. and B. Aboba, "Guidance for
                      Authentication, Authorization, and Accounting
                      (AAA) Key Management", BCP 132, RFC 4962,
                      July 2007.

   [LWAPP]            Calhoun, P., O'Hara, B., Suri, R., Cam Winget, N.,
                      Kelly, S., Williams, M., and S. Hares,
                      "Lightweight Access Point Protocol", Work in
                      Progress, March 2007.

   [SLAPP]            Narasimhan, P., Harkins, D., and S. Ponnuswamy,
                      "SLAPP: Secure Light Access Point Protocol", Work
                      in Progress, May 2005.

   [DTLS-DESIGN]      Modadugu, et al., N., "The Design and
                      Implementation of Datagram TLS", Feb 2004.

   [EUI-48]           IEEE, "Guidelines for use of a 48-bit Extended
                      Unique Identifier", Dec 2005.

   [EUI-64]           IEEE, "GUIDELINES FOR 64-BIT GLOBAL IDENTIFIER
                      (EUI-64) REGISTRATION AUTHORITY".

   [EPCGlobal]        "See http://www.epcglobalinc.org/home".

   [PacketCable]      "PacketCable Security Specification PKT-SP-SEC-
                      I12-050812", August 2005, <PacketCable>.

   [CableLabs]        "OpenCable System Security Specification OC-SP-
                      SEC-I07-061031", October 2006, <CableLabs>.

   [WiMAX]            "WiMAX Forum X.509 Device Certificate Profile
                      Approved Specification V1.0.1", April 2008,
                      <WiMAX>.

   [RFC5418]          Kelly, S. and C. Clancy, "Control And Provisioning
                      for Wireless Access Points (CAPWAP) Threat
                      Analysis for IEEE 802.11 Deployments", RFC 5418,
                      March 2009.

Top      Up      ToC       Page 155 
Editors' Addresses

   Pat R. Calhoun (editor)
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA  95134

   Phone: +1 408-902-3240
   EMail: pcalhoun@cisco.com

   Michael P. Montemurro (editor)
   Research In Motion
   5090 Commerce Blvd
   Mississauga, ON  L4W 5M4
   Canada

   Phone: +1 905-629-4746 x4999
   EMail: mmontemurro@rim.com


   Dorothy Stanley (editor)
   Aruba Networks
   1322 Crossman Ave
   Sunnyvale, CA  94089

   Phone: +1 630-363-1389
   EMail: dstanley@arubanetworks.com