what data could be reported or collected.
LWAPP
Statistics are sent by the WTP using an "Event Request" message.
LWAPP defines an 802.11 statistics message that covers 802.11 MAC
layer properties. LWAPP is compliant.
SLAPP
WLAN statistics transport is supplied via the control channel and
encoded in SLAPP-defined TLVs called information elements. 802.11
configuration and statistics information elements are supplied in
[SLAPP] 6.1.3.1. These are extendable and include vendor-specific
extensions.
CTP
CTP defines a control message called "CTP Stats-Notify". This
control message contains statistics in the form of SNMP OIDs and is
sent from the WTP to AC. This approach is novel because it leverages
the use of standard SNMP.
Section 5.3.10 of [CTP] recommends the use of 802.11 MIBs where
applicable. However, the proposal acknowledges that additional
configuration and statistics information is required, but does not
specify these MIB extensions. CTP needs to add these extensions to
the proposal. Also, this minimum set of statistics and configuration
OIDs must become requirements in order to fully meet the objective.
WiCoP
The feedback control message sent by the WTP contains many
statistics. WiCoP specifies 15 statistics that the WTP needs to send
to the AC. New versions of WiCoP can address any new statistics that
the AC needs to monitor the WTP. WiCoP meets this objective.
6.7. Resource Control
LWAPP:C, SLAPP:P, CTP:P, WiCoP:P
The evaluation team interpreted the resource control objective to
mean that the CAPWAP protocol must map 802.11e QoS markings to the
wired network. This mapping must include any encapsulation or
tunneling of user data defined by the CAPWAP protocol. Of particular
note, the evaluation team agreed that the CAPWAP protocol should
supply an explicit capability to configure this mapping. Since most
of the protocols relied only on the 802.11e statically defined
mapping, most received a partial compliance.
LWAPP
LWAPP defines its own custom TLV structure, which consists of an
8-bit type or class of information value and an additional 8-bit
value that indexes to a specific variable.
LWAPP allows the mobile station-based QoS configuration in each Add
Mobile Request sent by AC to WTP for each new mobile station that is
attached. Packet prioritization is left to individual WTPs. 4
different QoS policies for each station to enforce can be configured.
Update Mobile QoS message element can be used to change QoS policy at
the WTP for a given mobile station. LWAPP should support 8 QoS
policies as this matches 802.11e 802.1p and IP TOS, but for this
objective, 4 classes is compliant.
Overall, LWAPP conforms to the resource control objective. It
enables QoS configuration and mapping. The control can be applied on
a logical group basis and also enables the wireless traffic to be
flexibly mapped to the wired segment.
SLAPP
Although 802.11e specifies 802.1p and Differentiated Service Code
Point (DSCP) mappings, there is no explicit support for 802.11e in
SLAPP. SLAPP must be updated to add 802.11e as one of the standard
capabilities that a WTP could support and specify a mechanism that
would allow configuration of mapping the QoS classes.
CTP
CTP requires that the WTP and AC copy the QoS marking of user data to
the data message encapsulation. This mapping is accomplished by the
CTP Header’s 1-byte policy field. However, no configuration of QoS
mapping other than copying the user data’s already existing markings
is defined in CTP. It seems clear that SNMP could be used to
configure the mapping to occur differently, but no OIDs are defined
that would enable this. Partial compliance is assigned to CTP for
this objective.
WiCoP
Note: WiCoP rating for resource control objectives has been upgraded
from Failed to Partial. After an additional review of the WiCoP
protocol proposal, it was determined that the protocol partially
meets resource control objectives.
WiCoP protocol starts its QoS configuration with 802.11e capability
exchange between the WTP and AC. The QoS capabilities primitives are
included in the capability messages.
WiCoP defines the QoS-Value message that contains 802.11e
configuration parameters. This is sent for each group supported by
the WTP. WiCoP does not provide an explicit method for configuration
of DSCP tags and 802.1P precedence values. It is possible to
configure these parameters through SNMP OID configuration method, but
WiCoP does not explicitly identify any specific MIBs. Overall, WiCoP
partially meets resource control CAPWAP objectives. In order to be
fully compliant with the given objective, the protocol needs to
identify a clear method to configure 802.1p and DSCP mappings.
6.8. Protocol Security
LWAPP:C, SLAPP:C, CTP:F, WiCoP:F
For the purposes of the protocol security objective, the evaluation
team primarily considered whether or not the candidate protocols
implement the security features required by the CAPWAP objectives.
Please refer to the Security Considerations section of this document.
LWAPP
It appears that the security mechanisms, including the key management
portions in LWAPP, are correct. One third-party security review has
been performed. However, further security review is warranted since
a CAPWAP-specific key exchange mechanism is defined. LWAPP is
compliant with the objective.
SLAPP
The SLAPP protocol implements authentication of the WTP by the AC
using the DTLS protocol. This behavior is defined in both the
discovery process and the 802.11 control process. SLAPP allows
mutual and asymmetric authentication. SLAPP also gives informative
examples of how to properly use the authentication. SLAPP should add
another informative example for authentication of the AC by the WTP.
SLAPP is compliant with the objective.
CTP
The original presentation at IETF63 of the preliminary findings of
the evaluation team reported that CTP failed this objective. This
was on the basis of asymmetric authentication not being supported by
CTP. This was due to a misunderstanding of what was meant by
asymmetric authentication by the evaluation team. The definitions of
the terminology used in [OBJ] were clarified on the CAPWAP mailing
list. CTP in fact does implement a form of asymmetric authentication
through the use of public keys.
However, CTP still fails to comply with the objective for two
reasons:
First, CTP does not mutually derive session keys. Second, CTP does
not perform explicit mutual authentication because the 2 parties
authenticating do not confirm the keys.
WiCoP
There is not enough specific information to implement WiCoP protocol
security features. Although in concept EAP and IPsec make sense,
there is no explicit description on how these methods would be used.
6.9. System-Wide Security
LWAPP:C, SLAPP:C, CTP:F, WiCoP:F
LWAPP
LWAPP wraps all control and management communication in its
authenticated and encrypted control channel. LWAPP does not seem
particularly vulnerable to Denial of Service (DoS). LWAPP should
make a recommendation that the Join method be throttled to reduce the
impact of DoS attacks against it. Use of an established security
mechanism such as IPsec would be preferred. However, LWAPP’s
independent security review lent enough confidence to declare LWAPP
compliant with the objective.
SLAPP
SLAPP is compliant due to wrapping all control and management
communication in DTLS. SLAPP also recommends measures to protect
against discovery request DoS attacks. DTLS has undergone security
review and has at least one known implementation outside of SLAPP.
At the time of this writing, DTLS is pending proposed standard status
in the IETF.
CTP
CTP introduces a new, unestablished mechanism for AC-to-WTP
authentication. For complete compliance, use of an established
security mechanism with detailed specifications for its use in CTP is
preferred. Alternatively, a detailed security review could be
performed. CTP does not point out or recommend or specify any DoS
attack mitigation requirements against Reg-Req and Auth-Req floods,
such as a rate limiter. Because CTP received an ’F’ on its protocol
security objective, it follows that system-wide security must also be
rated ’F’.
WiCoP
WiCop does not address DoS attack threats. Also, as with the
protocol security objective, the protocol needs to explicitly
describe its tunnel and authentication methods.
6.10. 802.11i Considerations
LWAPP:C, SLAPP:C, CTP:F, WiCoP:P
LWAPP
LWAPP explicitly defines mechanisms for handling 802.11i in its modes
with encryption terminated at the WTP. In order to accomplish this,
the AC sends the Pairwise Transient Key (PTK) using the encrypted
control channel to the WTP using the Add Mobile message. When
encryption is terminated at the AC, there are no special
requirements. LWAPP is compliant.
SLAPP
SLAPP defines a control message to send the PTK and Group Temporal
Key (GTK) to the WTP when the WTP is the encryption endpoint. This
control message is carried on the DTLS protected control channel.
SLAPP is compliant.
CTP
CTP lacks a specification for a control message to send 802.11i PTK
and GTK keys to a WTP when the WTP is an encryption endpoint. Based
on this, CTP fails compliance for this objective. This requirement
could be addressed either by defining new control channel information
elements or by simply defining SNMP OIDs. The transport of these
OIDs would be contained in the secure control channel and therefore
protected.
WiCoP
WiCoP lacks documentation on how to handle 4-way handshake. The case
for encryption at the AC needs clarification.
6.11. Interoperability
LWAPP:C, SLAPP:C, CTP:C, WiCoP:C
LWAPP
LWAPP supports both split- and local-MAC architectures and is
therefore compliant to the letter of the objectives. LWAPP is
particularly rich in its support of the split-MAC architecture.
However, LWAPP’s support of local-MAC is somewhat limited and could
be expanded. LWAPP is lacking a mode that allows local-MAC data
frames to be tunneled back to the AC. A discussion of possible
extensions and issues is discussed in the recommendations section of
this evaluation.
SLAPP
SLAPP is compliant.
CTP
CTP is compliant.
WiCoP
WiCoP is compliant.
6.12. Protocol Specifications
LWAPP:C, SLAPP:P, CTP:P, WiCoP:P
LWAPP
LWAPP is nearly fully documented. Only a few sections are noted as
incomplete. Detailed descriptions are often given to explain the
purpose of the protocol primitives defined that should encourage
interoperable implementations.
SLAPP
SLAPP is largely implementable from its specification. It contains
enough information to perform an interoperable implementation for its
basic elements; however, additional informative references or
examples should be provided covering use of information elements,
configuring multiple logical groups, and so on.
CTP
As noted earlier, there are a few areas where CTP lacks a complete
specification, primarily due to the lack of specific MIB definitions.
WiCoP
Due to the lack of specific tunnel specifications and authentication
specifications, WiCoP is only partially compliant.
6.13. Vendor Independence
LWAPP:C, SLAPP:C, CTP:C, WiCoP:C
LWAPP
LWAPP is compliant.
SLAPP
SLAPP is compliant.
CTP
CTP is compliant.
WiCoP
WiCoP is compliant.
6.14. Vendor Flexibility
LWAPP:C, SLAPP:C, CTP:C, WiCoP:C
LWAPP
LWAPP is compliant.
SLAPP
SLAPP is compliant.
CTP
CTP is compliant.
WiCoP
WiCoP is compliant.
6.15. NAT Traversal
LWAPP:C, SLAPP:C, CTP:C, WiCoP:C
LWAPP
LWAPP may require special considerations due to it carrying the IP
address of the AC and data termination points in the payload of
encrypted control messages. To overcome Network Address Translation
(NAT), static NAT mappings may need to be created at the NAT’ing
device if the AC or data termination points addresses are translated
from the point of view of the WTP. A WTP should be able to function
in the hidden address space of a NAT’d network.
SLAPP
SLAPP places no out-of-the-ordinary constraints regarding NAT. A WTP
could function in the hidden address space of a NAT’d network without
any special configuration.
CTP
CTP places no out-of-the-ordinary constraints regarding NAT. A WTP
could function in the hidden address space of a NAT’d network without
any special configuration.
WiCoP
WiCoP places no out-of-the-ordinary constraints regarding NAT. A WTP
could function in the hidden address space of a NAT’d network without
any special configuration.
7. Desirable Objective Compliance Evaluation
7.1. Multiple Authentication
LWAPP:C, SLAPP:C, CTP:C, WiCoP:C
LWAPP
LWAPP allows for multiple STA authentication mechanisms.
SLAPP
SLAPP does not constrain other authentication techniques from being
deployed.
CTP
CTP supports multiple STA authentication mechanisms.
WiCoP
WiCoP allows for multiple STA authentication mechanisms.
7.2. Future Wireless Technologies
LWAPP:C, SLAPP:C, CTP:C, WiCoP:C
LWAPP
LWAPP could be used for other wireless technologies. However, LWAPP
defines very few primitives that are independent of the 802.11 layer.
SLAPP
SLAPP could be used for other wireless technologies. However, SLAPP
defines very few primitives that are independent of the 802.11 layer.
CTP
CTP supplies STA control abstraction, methods for extending the
forwarding of multiple types of native wireless management frames,
and many options for user data tunneling. Configuration management
is an extension of SNMP, to which new MIBs could, in concept, be
easily plugged in. This helps makes CTP a particularly flexible
proposal for supporting future wireless technologies. In addition,
CTP has already defined multiple wireless protocol types in addition
to 802.11.
WiCoP
WiCoP could be used for other wireless technologies.
7.3. New IEEE Requirements
LWAPP:C, SLAPP:C, CTP:C, WiCoP:C
LWAPP
LWAPP’s extensive use of native 802.11 frame forwarding allows it to
be transparent to many 802.11 changes. It, however, shifts the
burden of adapting MAC layer changes to the packet processing
capabilities of the AC.
SLAPP
SLAPP’s use of native 802.11 frames for control and management allows
SLAPP a measure of transparency to changes in 802.11. Because SLAPP
also supports a mode that tunnels user data as 802.3 frames, it has
additional architectural options for adapting to changes on the
wireless infrastructure.
CTP
CTP has perhaps the greatest ability to adapt to changes in IEEE
requirements. Architecturally speaking, CTP has several options
available for adapting to change. SNMP OIDs are easily extended for
additional control and management functions. Native wireless frames
can be forwarded directly to the AC if necessary. Wireless frames
can be bridged to 802.3 frames and tunneled back to the AC to protect
the AC from changes at the wireless MAC layer. These options allow
many possible ways to adapt to change of the wireless MAC layer.
WiCoP
Because WiCoP uses 802.11 frames for the data transport, it is
transparent to most IEEE changes. Any new IEEE requirements may need
new configuration and new capability messages between the WTP and AC.
The AC would need to be modified to handle new 802.11 control and
management frames.
7.4. Interconnection (IPv6)
LWAPP:C, SLAPP:C, CTP:C, WiCoP:C
LWAPP
LWAPP explicitly defines measures for accommodating IPv6. LWAPP is
more sensitive to this in part because it carries IP addresses in two
control messages.
SLAPP
SLAPP is transparent to the interconnection layer. DTLS and GRE will
both operate over IPv6.
CTP
CTP is transparent to the interconnection layer. CTP should be able
to operate over IPv6 without any changes.
WiCoP
WiCoP is transparent to the interconnection layer and should be able
to operate over IPv6 without changes.
7.5. Access Control
LWAPP:C, SLAPP:C, CTP:C, WiCoP:C
LWAPP
LWAPP uses native 802.11 management frames forwarded to the AC for
the purpose of performing STA access control. WTPs are authenticated
in LWAPP’s control protocol Join phase.
SLAPP
SLAPP has support for multiple authentication methods for WTPs. In
addition, SLAPP can control STA access via 802.11 management frames
forwarded to the AC or via SLAPP’s information element primitives.
CTP
CTP specifies STA access control primitives.
WiCoP
WiCoP specifies access control in [WICOP] section 5.2.2.
8. Evaluation Summary and Conclusions
See Figure 1 (section numbers correspond to RFC 4564 [OBJ]).
---------------------------------------------------------------
| CAPWAP Evaluation | LWAPP | SLAPP | CTP | WiCoP |
|---------------------------------------------------------------|
| 5.1.1 Logical Groups | C | C | C | C |
| 5.1.2 Traffic Separation | C | C | P | P |
| 5.1.3 STA Transparency | C | C | C | C |
| 5.1.4 Config Consistency | C | C | C | C |
| 5.1.5 Firmware Trigger | P | P | P | C |
| 5.1.6 Monitor System | C | C | P | C |
| 5.1.7 Resource Control | C | P | P | P |
| 5.1.8 Protocol Security | C | C | F | F |
| 5.1.9 System Security | C | C | F | F |
| 5.1.10 802.11i Consideration | C | C | F | P |
|---------------------------------------------------------------|
| 5.1.11 Interoperability | C | C | C | C |
| 5.1.12 Protocol Specifications | C | P | P | P |
| 5.1.13 Vendor Independence | C | C | C | C |
| 5.1.14 Vendor Flexibility | C | C | C | C |
| 5.1.15 NAT Traversal | C | C | C | C |
|---------------------------------------------------------------|
| Desirable |
|---------------------------------------------------------------|
| 5.2.1 Multiple Authentication | C | C | C | C |
| 5.2.2 Future Wireless | C | C | C | C |
| 5.2.3 New IEEE Requirements | C | C | C | C |
| 5.2.4 Interconnection (IPv6) | C | C | C | C |
| 5.2.5 Access Control | C | C | C | C |
---------------------------------------------------------------
Figure 1: Summary Results
9. Protocol Recommendation
The proposals presented offer a variety of novel features that
together would deliver a full-featured, flexible, and extensible
CAPWAP protocol. The most novel of these features leverage existing
standards where feasible. It is this evaluation team’s opinion that
a mix of the capabilities of the proposals will produce the best
CAPWAP protocol.
The recommended features are described below. Many of these novel
capabilities come from CTP and SLAPP and WiCoP. However, LWAPP has
the most complete base protocol and is flexible enough to be extended
or modified by the working group. We therefore recommend that LWAPP
be used as the basis for the CAPWAP protocol.
The evaluation team recommends that the working group carefully
consider the following issues and recommended changes. The
evaluation team believes that a more complete CAPWAP protocol will be
delivered by addressing these issues and changes.
9.1. High-Priority Recommendations Relevant to Mandatory Objectives
9.1.1. Information Elements
LWAPP’s attribute value pair system meets the objectives as defined
by the working group. However, it has only 8 bits assigned for
attribute types, with an additional 8 bits for a specific element
within an attribute type. The evaluation team strongly recommends
that a larger number of bits be assigned for attribute types and
information elements.
9.1.2. Control Channel Security
LWAPP’s security mechanisms appear satisfactory and could serve
CAPWAP going forward. However, the evaluation team recommends
adoption of a standard security protocol for the control channel.
There are several motivations for a standards-based security
protocol, but the primary disadvantage of a new security protocol is
that it will take longer and be more difficult to standardize than
reusing an existing IETF standard. First, a new security protocol
will face a longer, slower approval processes from the Security Area
Directorate and the IESG. The new CAPWAP security protocol will need
to pass several tests including the following:
What is uniquely required by CAPWAP that is not available from an
existing standard protocol? How will CAPWAP’s security protocol meet
security area requirements for extensibility, such as the ability to
support future cipher suites and new key exchange methods? How does
this ability compare to established security protocols that have
these capabilities?
Points such as these are continually receiving more attention in the
industry and in the IETF. Extensibility of key exchange methods and
cipher suites are becoming industry standard best practices. These
issues are important topics in the IETF Security Area Advisory Group
(SAAG) and the SecMech BOF, held during the 63rd IETF meeting.
These issues could be nullified by adopting an appropriate existing
standard security protocol. IPsec or DTLS could be a standards
alternative to LWAPP’s specification. DTLS presents a UDP variant of
Transport Layer Security (TLS). Although DTLS is relatively new, TLS
is a heavily used, tried-and-tested security protocol.
The evaluation team recommends that whatever security protocol is
specified for CAPWAP, its use cases must be described in detail.
LWAPP does a good job of this with its proposed, proprietary method.
If an updated specification is developed, it should contain at least
one mandatory authentication and cipher method. For example, pre-
shared key and x.509 certificates could be specified as mandatory
authentication methods, and Advanced Encryption Standard (AES)
Counter Mode with CBC-MAC Protocol (CCMP) could be selected as a
mandatory cipher.
Given the possibilities for code reuse, industry reliance on TLS, and
the future for TLS, DTLS may be a wise alternative to a security
method specific to CAPWAP. In addition, use of DTLS would likely
expedite the approval of CAPWAP as a proposed standard over the use
of CAPWAP-specific security mechanisms.
9.1.3. Data Tunneling Modes
9.1.3.1. Support for Local MAC User Data Tunneling
The issue of data encapsulation is closely related to the split- and
local-MAC architectures. The split-MAC architecture requires some
form of data tunneling. All the proposals except LWAPP offer a
method of tunneling in local-MAC mode as well. By local-MAC data
tunneling, we mean the tunneling of user data as 802.3 Ethernet
frames back to the AC from a WTP that is otherwise in local-MAC mode.
Tunneling data in local-MAC mode offers the ability for implementers