RFC 5415
Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Specification
Pages: 155
Proposed Standard
→ Errata
Obsoletes: 5414
Updated by: 8553 8996
Proposed Standard
→ Errata
Obsoletes: 5414
Updated by: 8553 8996
Part 6 of 6 – Pages 131 to 155
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.
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.3910.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
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.
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
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
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.
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.
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:
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.
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
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.
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.
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.
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 Document15.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 Value15.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
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 Reference15.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 Reference15.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
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 Reference15.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 Reference15.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 Reference15.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
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 Reference15.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 Reference15.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 Reference15.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
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 Reference15.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 Reference15.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 Reference15.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
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 Reference15.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 Reference15.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 Reference15.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
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 Reference15.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 Reference15.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 Reference15.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
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 Reference15.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 Reference16. 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.
[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.
[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.
[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.
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