Network Working Group R. Gwee Internet-Draft Republic Polytechnic Expires: March 16, 2006 September 12, 2005 CAPWAP Comparative Analysis draft-gwee-capwap-comparative-analysis-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on March 16, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract The purpose of this document is to present a comparative evaluation of the Control and Provisioning of Wireless Access Points (CAPWAP) protocol proposals. To the date of this document, the following four protocols have been proposed, namely CAPWAP Tunneling Protocol (CTP), Light Weight Access Point Protocol (LWAPP), Secure Light Access Point Protocol (SLAPP), Wireless LAN Control Protocol (WiCoP). Each of these protocols has its own unique strengths in fulfilling the CAPWAP Objectives through their own mechanisms and functionalities. The final CAPWAP protocol should comprise all of these strengths. This Gwee Expires March 16, 2006 [Page 1] Internet-Draft Comparative Analysis September 2005 document gives a comparative study of the four proposed protocols based on the CAPWAP Objectives and makes recommendations on the combination of their strengths for the final CAPWAP protocol. Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Comparative Evaluation . . . . . . . . . . . . . . . . . . . . 7 4.1. Mandatory Objectives . . . . . . . . . . . . . . . . . . . 7 4.1.1. Logical Groups . . . . . . . . . . . . . . . . . . . . 7 4.1.2. Support for Traffic Separation . . . . . . . . . . . . 9 4.1.3. Wireless Terminal Transparency . . . . . . . . . . . . 10 4.1.4. Configuration Consistency . . . . . . . . . . . . . . 11 4.1.5. Firmware Trigger . . . . . . . . . . . . . . . . . . . 13 4.1.6. Monitoring and Exchange of System-wide Resource State . . . . . . . . . . . . . . . . . . . . . . . . 14 4.1.7. Resource Control Objective . . . . . . . . . . . . . . 16 4.1.8. CAPWAP Protocol Security . . . . . . . . . . . . . . . 18 4.1.9. System-wide Security . . . . . . . . . . . . . . . . . 19 4.1.10. IEEE 802.11i Considerations . . . . . . . . . . . . . 20 4.1.11. Interoperability Objective . . . . . . . . . . . . . . 21 4.1.12. Protocol Specifications . . . . . . . . . . . . . . . 23 4.1.13. Vendor Independence . . . . . . . . . . . . . . . . . 24 4.1.14. Vendor Flexibility . . . . . . . . . . . . . . . . . . 25 4.1.15. NAT Traversal . . . . . . . . . . . . . . . . . . . . 25 4.2. Desirable Objectives . . . . . . . . . . . . . . . . . . . 26 4.2.1. Multiple Authentication Mechanisms . . . . . . . . . . 27 4.2.2. Support for Future Wireless Technologies . . . . . . . 28 4.2.3. Support for New IEEE Requirements . . . . . . . . . . 29 4.2.4. Interconnection Objective . . . . . . . . . . . . . . 30 4.2.5. Access Control . . . . . . . . . . . . . . . . . . . . 30 5. Comparative Analysis . . . . . . . . . . . . . . . . . . . . . 32 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 35 7. Security Considerations . . . . . . . . . . . . . . . . . . . 36 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 37 Intellectual Property and Copyright Statements . . . . . . . . . . 38 Gwee Expires March 16, 2006 [Page 2] Internet-Draft Comparative Analysis September 2005 1. Requirements notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Gwee Expires March 16, 2006 [Page 3] Internet-Draft Comparative Analysis September 2005 2. Terminology This document follows the terminologies of [I-D.ietf-capwap-arch] and [I-D.ietf-capwap-objectives]. Gwee Expires March 16, 2006 [Page 4] Internet-Draft Comparative Analysis September 2005 3. Introduction With the popularity of wireless connectivity in today's markets, deployments of large number of wireless termination points (WTPs) in large wireless local area networks (WLANs) have become relatively common. The sheer size of such networks has led to scalability issues that have been described in the CAPWAP Problem Statement [I-D.ietf-capwap-problem-statement] . These issues can be summarized as: possible misconfiguration and improper operation of the WLAN; difficulty in distributing and maintaining a consistent configuration throughout the entire WLAN; ineffective handling of the dynamic nature of the wireless medium; challenges in ensuring security for the entire WLAN. In view of these challenging issues, different vendors have derived their own proprietary solutions. However, these solutions are not interoperable and thus the CAPWAP standardization is in process to provide an integral and interoperable solution to the above problems. The primary purpose of CAPWAP is to ensure effective handling of large WLANs. The Architecture Taxonomy [I-D.ietf-capwap-arch] has highlighted a centralized WLAN architecture in which an access controller (AC) provides centralized control and management for a group of WTPs. To achieve interoperability in the CAPWAP framework, critical objectives have been identified [I-D.ietf-capwap-objectives] and these will be used as the basis for the comparative evaluation in this document. The comparative study will only focus on the mandatory and desirable objectives for analysis. Non- objectives and Operator Requirements are out of scope for this document. It is of utmost importance that the final CAPWAP protocol will fulfill the main requirements for addressing the Problem Statement and hence be suitable for managing large WLANs effectively. To the date of this document, four protocols, namely CTP, LWAPP, SLAPP and WiCoP, have been proposed as candidate protocols for CAPWAP. CTP [I-D.singh-capwap-ctp] provides centralized control and provisioning of large WLANs and improves scalability by minimizing the configuration of the wired infrastructure. Its centralized operation helps in providing centralized security and policy management as well. As CTP assumes that the MAC layer of the wireless technology is fully implemented in the WTP, it is able to provide IP network services to users independent of the wireless technology used. This is possible by making use of the control channel binding between the WTP and AC to provide all the necessary signaling required for proper operation. LWAPP [I-D.ohara-capwap-lwapp] defines how the WTPs communicate with Gwee Expires March 16, 2006 [Page 5] Internet-Draft Comparative Analysis September 2005 AC by means of layer 2 protocols or a routed IP network. It concentrates on three goals. The first goal is to provide centralized control and functions for a wireless network. The second goal is to shift the higher level protocol processing burden from the WTP to the AC, resulting in lighter WTP. The third goal is to provide a generic encapsulation and transport mechanism. LWAPP claims to be independent of the layer 2 wireless technology. SLAPP [I-D.narasimhan-ietf-slapp] is unique in terms of its protocol design. It consists of a technology-independent component and a technology-dependent component. The former will perform the core functionalities of the protocol that is independent of the wireless technology used. The latter component is dependent on the type of wireless technology and provides control functionalities in the form of a relevant control protocol. These two components will form a complete solution. Through such a design, SLAPP is extensible to any future technologies or new methods. WiCoP [I-D.iino-capwap-wicop] provides a common platform for accommodating WLAN entities of different architectural designs. It allows interoperability between WTPs and ACs even if their architectural designs are different. Thus, it is able to provide cost-effective WLAN expansions and accommodate future development in WLAN technologies. WiCoP can also be used on shared infrastructure WLANs in which different logical groups are situated in a single physical WLAN. In such cases, tunnels will be used to separate traffic flows based on logical grouping. It can be inferred that each of the above protocols have their own strengths in certain aspects of WLAN management. It will be beneficial for the industry to have an effective protocol capable of addressing various aspects of WLAN management. Thus the final CAPWAP protocol should have the sum of the strengths of individual protocols. In this way, the industry can benefit by having the best of available solutions. This document takes inspiration from presentations made during IETF 63 and provides recommendations on the various protocols mechanisms. Gwee Expires March 16, 2006 [Page 6] Internet-Draft Comparative Analysis September 2005 4. Comparative Evaluation This section provides a comparative evaluation of the various protocols mechanisms for each CAPWAP objectives. For this document, only the Mandatory and Desirable Objectives are considered. The non- Objectives are not considered as they are deemed not essential for the final CAPWAP protocol. 4.1. Mandatory Objectives According to the CAPWAP Objectives, mandatory objectives are considered crucial for the control and provisioning of WTPs. They directly address the Problem Statement and must be realized by the final CAPWAP protocol. In the following, a comparison of the various protocols' mechanisms is made against each mandatory objective. A description of each objective and statements from the evaluation draft of each protocol are stated for reference. A final analysis and recommendation of the preferred mechanism among the four is given at the end of each objective. 4.1.1. Logical Groups "The CAPWAP protocol MUST be capable of controlling and managing physical WTPs in terms of logical groups including BSSID-based groups." 4.1.1.1. CTP Evaluation In CTP, physical and logical associations are enumerated by means of its discovery mechanism. Unique indices for the enumeration of radio and network are provided using Radio-Index and Network-Index respectively. Such enumerations are used in protocol exchange and state machine to support logical grouping of physical WTPs. 4.1.1.2. LWAPP Evaluation For LWAPP, BSSID/SSIDs are used to identify logical groups. Thus a single WTP is assumed to support multiple SSIDs. Logical groups can be created by the AC through the creation of WLANs. A WLAN will be identified through the SSID and can have a separate security policy and a unique BSSID. Thus each WLAN can be assumed as a separate network. Specific rules are given on the BSSID to WLAN Identifier mapping. One thing to note for Local MAC WTPs is that VLAN tags may be used to allow for bridging of data frames to a specific VLAN. This function will allow the support of logical groups in Local MAC mode. Gwee Expires March 16, 2006 [Page 7] Internet-Draft Comparative Analysis September 2005 4.1.1.3. SLAPP Evaluation The SLAPP protocol allows a WTP to define its logical groups supported through the use of BSSIDs. On the AC side, a logical group can be created by defining a WLAN with a specific BSSID, ESSID and associated parameters. Each logical group can have its own set of policies such as security, QoS etc. 4.1.1.4. WiCoP Evaluation WiCoP makes use of BSSIDs to create logical groups for the wireless medium segment and VLANs to create logical groups for the wired segment. Both logical groups are then mapped together using the BSSID-TunnelID. This mechanism supports both Split MAC and local MAC architectures. 4.1.1.5. Analysis From the objective statement, it is clear that logical groups must be supported across both wired and wireless aspects of the network regardless of the type of MAC architecture in WTP. Such grouping will provide advantages in terms of easier traffic management, better security. Thus it must be considered that the CAPWAP protocol should be able to fulfill this objective in an effective and efficient manner. From the above descriptions, LWAPP and SLAPP work similarly in the sense that they make use of BSSIDs and WLANs to define logical groups. The difference between these two protocols lies in the parameters used in the classifying of logical groups. However, SLAPP does not specify the use of VLAN for support of logical groups in Local MAC mode, unlike LWAPP. On the other hand, WiCoP makes use of BSSIDs and VLANs for identifying logical groups while CTP supports enumeration of logical association. 4.1.1.6. Recommendation From the above evaluations, all the four protocols' mechanisms do fulfill this objective in an effective manner. But in terms of efficiency and simplicity, the mechanism in WiCoP does appear to have an advantage in supporting the logical group objective. It explicitly includes logical group information in the WTP configuration phase and provides mappings for logical groups to cover both wireless and wireline segments. This makes WiCoP's approach to this objective highly structured. Gwee Expires March 16, 2006 [Page 8] Internet-Draft Comparative Analysis September 2005 4.1.2. Support for Traffic Separation "The CAPWAP Protocol MUST define transport control messages such that the transport of control messages is separate from the transport of data messages." 4.1.2.1. CTP Evaluation For CTP, data packets are always enumerated as CTP_DATA type. In addition, a logical WTP device has the option of transporting the data traffic via tunneling or bridging locally onto the wired network. On the other hand, control packets are handled separately from data packets and always terminated at the controller. 4.1.2.2. LWAPP Evaluation For LWAPP, a control packet is differentiated from a data packet by the definition of a 'C' bit in the LWAPP header. If the bit is set, the LWAPP frame is a control frame and if the bit is cleared, the LWAPP frame is a data frame. In split MAC mode, the frame is tunneled to the AC. However, in the local MAC mode, the frame can be locally bridged at the WTP. Both mechanisms help in keeping the control and data traffic separated. 4.1.2.3. SLAPP Evaluation In the draft specification of SLAPP, the IEEE 802.11 control protocol is used as an example. The IEEE 802.11 control protocol has two components which caters for control packets and data packets individually. Control packets will contain a SLAPP control protocol header and transmitted as UDP packets to the AC. Data packets will be tunneled via Generic Routing Encapsulation (GRE) to the AC. In this way, both control and data packets are uniquely identified and separated sufficiently. 4.1.2.4. WiCoP Evaluation WiCoP makes use of tunnels to differentiate control and data traffic. Control traffic is transmitted via a control tunnel while data traffic from different logical groups is transmitted via distinct VLAN tunnels. This ensures separation of traffic flows between the WTPs and AC. In addition, a 'C' bit is used to differentiate a control frame from a data frame. 4.1.2.5. Analysis For CTP, although it has been clearly stated that CTP data messages are used to tunnel user data between WTP and AC, it only meets this Gwee Expires March 16, 2006 [Page 9] Internet-Draft Comparative Analysis September 2005 objective partially as it does not specify how such a tunnel is triggered. More information is required on the configuration of the tunneling option in a WTP. On the other hand, LWAPP does fulfill this objective through its various mechanisms used in separating the control and data traffic. It is able to meet this objective in both local and split MAC architectures. SLAPP is also able to fulfill this objective as it distinguishes between control packets and data packets based on different encapsulation of different packets. However, it should be noted that the control protocol aspect of SLAPP is actually dependent on the type of technologies used and thus attention must be paid in this area for use with future technologies. WiCoP is able to fulfill this objective as well based on its use of separate data and control tunnels. Similarly to LWAPP, a 'C' bit is used to differentiate the control and data packets. However, it is interesting to find that WiCoP makes use of only one control tunnel to transport control packets from all logical groups. This may be deemed as a security issue and needs to be considered in that light. 4.1.2.6. Recommendation From the descriptions above, CTP's mechanism does not explicitly specify how a trigger for a user data tunnel is called. It will be best if CTP can provide some specifications on the trigger issue. On the other hand, WiCoP's design gives rise to some security concern due to lack of separation of control packets from different logical groups. It will also be beneficial for CAPWAP if WiCoP can provide some form of separation for the control packets for logical groups. For example, it can introduce distinct tunnels not only for data packets but also for control packets for different logical groups. In view of these issues, the mechanism stated in LWAPP and SLAPP specifications are at a better position to meet this objective in an equally effective manner. 4.1.3. Wireless Terminal Transparency "Wireless terminals MUST NOT be required to recognize or be aware of the CAPWAP protocol." 4.1.3.1. CTP Evaluation The operation of CTP is transparent to the wireless terminals. Wireless terminals only interact with the WTPs' wireless MAC and their traffic is bridged either to the controller or the local wired Gwee Expires March 16, 2006 [Page 10] Internet-Draft Comparative Analysis September 2005 infrastructure. Any encapsulation of traffic that took place will be transparent to the wireless terminals as well. 4.1.3.2. LWAPP Evaluation The LWAPP protocol only operates between the AC and WTP and thus does not have any impact on the wireless terminals. Upon connection of a WTP to an AC, it will be configured to provide service autonomously. 4.1.3.3. SLAPP Evaluation SLAPP only operates between the AC and WTPs. SLAPP messages do not travel on the IEEE 802.11 wireless links and thus are transparent to the wireless terminals. 4.1.3.4. WiCoP Evaluation WiCoP does not require any changes to the wireless terminals. Its operations are confined between the AC and WTPs. Thus wireless terminals are not aware of the WiCoP protocol. 4.1.3.5. Analysis On analysis of the four proposed protocols, it can be observed that these protocols are designed in such a way that their operations do not extend to the wireless aspect or affect any wireless terminals. 4.1.3.6. Recommendation The mechanisms stated in all the four proposed protocols realize this objective in an equally effective manner. 4.1.4. Configuration Consistency "The CAPWAP protocol MUST include support for regular exchanges of state information between WTPs and WLAN controller. Examples of state information include WTP processing load and memory utilization." 4.1.4.1. CTP Evaluation In its specification, CTP includes support for regular exchanges of state information through its statistics messages. In this case, CTP recommends the reuse of IEEE 802.11 MIBs for configuration and statistics message payload. MIB extensions should be defined where the corresponding MIBs are not sufficient. Gwee Expires March 16, 2006 [Page 11] Internet-Draft Comparative Analysis September 2005 4.1.4.2. LWAPP Evaluation The LWAPP protocol provides two options in which a WTP manages its configuration. WTPs can retain any configuration parameters provided by the AC or let the AC maintain a record of all WTPs. If a WTP saves configuration locally, it is able to provide such information to any new AC in the event of failure and reconnection to a new AC. Statistical information in LWAPP specification is bound to IEEE 802.11. Any new wireless technologies for LWAPP will need to define their corresponding statistics report format. 4.1.4.3. SLAPP Evaluation During the initialization process in SLAPP, a capability exchange mechanism is performed between the WTPs and AC, allowing the AC to have a consistent picture of the capabilities of the WTPs. After the exchange, the AC configures the WTPs via configuration messages. WTP statistics and status can also be obtained by an AC upon request to the WTP. 4.1.4.4. WiCoP Evaluation WiCoP makes use of Feedback messages which contain configuration information of WTPs and ACs. The WTPs and AC regularly exchange Feedback messages and this helps to provide a consistent configuration for all the WTPs. 4.1.4.5. Analysis It is important to understand the rationale behind this objective. As a CAPWAP protocol is meant to support a large WLAN network environment, proper maintenance of state information of all the nodes is required for its effective operation. A deeper analysis indicates that in addition to this function, the type of state information to be exchanged is also important to for effective management with minimum operation. The above four protocols have focused on the fulfillment of the objective through their own mechanisms but does not provide sufficient information on the type of state information. Although the latter part is implementation specific, it is useful to provide a framework such that there will be fewer implementation issues arising in the future. 4.1.4.6. Recommendation The mechanisms stated in all the four protocols fulfill this objective in an equally effective manner. However, LWAPP and CTP Gwee Expires March 16, 2006 [Page 12] Internet-Draft Comparative Analysis September 2005 specifications provide some recommendation of the use of IEEE 802.11 bound statistics and configuration in their specification. Thus in terms of details, it is recommended to use the mechanisms of LWAPP or CTP for this objective. It will be good if the final CAPWAP protocol does consider this aspect in its specification, providing some details of a framework. 4.1.5. Firmware Trigger "The CAPWAP protocol MUST support a trigger for delivery of firmware updates." 4.1.5.1. CTP Evaluation A WTP image management system is out of scope in the CTP specification. However, it does provide a trigger for software upgrade in its control channel establishment phase. A WTP sends a software update request/response message to the AC to confirm whether it needs to update its firmware. CTP does not specify how the firmware upgrade will be carried out but assumes the application of standardized binary transport protocols (FTP/TFTP). 4.1.5.2. LWAPP Evaluation LWAPP provides a trigger for firmware upgrade during the image-data phase of its state machine. A WTP communicates with the AC to determine whether it needs to upgrade its firmware. The WTP then makes use of the Image Download message to download the required files. 4.1.5.3. SLAPP Evaluation SLAPP provides a trigger for firmware upgrade through its Image Download protocol. In its specification, it mentions a method of securing image download using DTLS. The image download protocol is selected when a new image is determined to be available during the SLAPP discovery phase. The WTP then downloads the new firmware from AC for updating. 4.1.5.4. WiCoP Evaluation WiCoP makes use of Firmware Download message to initiate firmware check and download regularly. Such messages are sent out periodically in order to ensure the most up-to-date firmware for the WTPs. Gwee Expires March 16, 2006 [Page 13] Internet-Draft Comparative Analysis September 2005 4.1.5.5. Analysis Among the four proposed protocols, WiCoP seem to be the only protocol that specifies a firmware update periodically. For the rest of the protocols, the trigger for the firmware update only occurs during the setting up of a connection. Often, it is important that a WTP will update its firmware regularly for effective operation. This is especially true for operation within a large WLAN environment where the are possibilities for WTPs to be reorganized frequently. It will be better if a firmware update be triggered as and when there is an available new update and not when a new connection is being set up. 4.1.5.6. Recommendation As stated earlier, WiCoP is the only protocol that provides firmware update during running operation mode. Such procedure is important if consistent firmware version is to be found in all WTPs in a large WLAN environment. In addition to updating firmware during the setting up of new connections, frequent updates and firmware checks are highly recommended for this objective. In view of this perspective, the mechanism stated in WiCoP fulfills this objective in the most effective manner. 4.1.6. Monitoring and Exchange of System-wide Resource State "The CAPWAP protocol MUST allow for the exchange of statistics, congestion and other WLAN state information." 4.1.6.1. CTP Evaluation CTP makes use of the statistics request and statistics notification messages to facilitate the periodic exchange of statistics. The statistics payload is based on MIB definitions from the IEEE 802.11 standard and extensions. This protocol mechanism is agnostic to wireless technologies and updates to existing wireless standards. 4.1.6.2. LWAPP Evaluation LWAPP provides a mechanism for exchange of statistics and WLAN state information between a WTP and AC. The type of statistics and state information differs according to the aspect of the network considered: wireless and wired. Information collected on wired aspect includes firmware version, number of radios, radio failures etc. In the event of failure, a WTP may also provide reboot statistics and reason for previous failure. On the other hand, information collected on wireless aspect includes statistics such as signal strength based on AC's policy. The LWAPP Gwee Expires March 16, 2006 [Page 14] Internet-Draft Comparative Analysis September 2005 protocol also allows for unsolicited statistics collection. 4.1.6.3. SLAPP Evaluation The SLAPP protocol allows for monitoring and exchange of system wide resources through the definition of configuration, status, event and statistics elements. It allows different types of statistics such as transmit frame counters, receive frame counters etc to be exchanged between a WTP and AC. Statistics collected can be in aggregated form or instantaneous form. SLAPP allows an AC to configure specific events at the WTP through the event mechanism. Using one of the configuration elements, an AC may reconfigure or re-adjust its parameters based on statistics, status or events collected from a WTP. 4.1.6.4. WiCoP Evaluation WiCoP makes use of Feedback messages together with QoS-Value, Statistics, Interface-Error and QoS-Capability message elements to monitor configuration state of the WTPs and AC. The Feedback messages are sent regularly to the AC by the WTPs. This mechanism is also combined with keepalive signaling to serve dual roles of feedback and notification. WiCoP timers are configured to manage these dual roles. 4.1.6.5. Analysis From the objective statement, it should be noted that not only should the final CAPWAP protocol provide a mechanism for monitoring and exchange of system-wide resource state information, it is also important for the protocol specification to list the state information that are being monitored and exchanged by WTPs and ACs. Furthermore, the final CAPWAP protocol should apply this objective over the entire network and not focus on only a portion of the network e.g. wireless portion. From the above description, the four proposed protocols provide their own unique mechanisms to exchange system-wide resource state information. However, it seems that CTP has focused this objective more on the wireless aspect of the network and thus may not be a complete solution for this objective. The remaining three protocols fulfill this objective effectively based on their specifications but there is an interesting observation on WiCoP. The WiCoP protocol allows a WTP and AC to exchange Feedback messages regularly as the Feedback messages also serve as keepalive signals. The dual role of such feedback system is crucial for operational efficiency especially in a large WLAN environment. Furthermore, the QoS capability message element in WiCoP provides a description of the network congestion Gwee Expires March 16, 2006 [Page 15] Internet-Draft Comparative Analysis September 2005 information which directly addresses the objective. 4.1.6.6. Recommendation CTP focuses this objective more on the wireless aspect of the network and thus may not be a complete solution for this objective. The remaining protocols are able to fulfill this objective effectively but it can be observed that the Feedback messages used in WiCoP play a dual role in exchanging state information and acting as keepalive signals. Such mechanism allow for high operational efficiency especially in a large WLAN environment. In view of this, it can be stated that the mechanisms stated in LWAPP, SLAPP and WiCoP fulfill this objective effectively. But in terms of operational efficiency, the mechanism in WiCoP certainly has an advantage over the rest of the proposed protocols. 4.1.7. Resource Control Objective "The CAPWAP protocol MUST map the IEEE 802.11e QoS priorities to equivalent QoS priorities across the switching and wireless medium segments." 4.1.7.1. CTP Evaluation CTP makes use of a two tiered mechanism to map QoS priorities on packets on both wired and wireless aspects of the network. On the wired aspect of the network, CTP defines an 8-bit field for carrying QoS related information independently of the transport protocol. Alternatively, IEEE 802.1p tags can be used on packets to carry QoS information across the wired segment. On the other hand, for the wireless aspect of the network, the mapping of QoS information on the packets is carried out using the IEEE 802.11e standard. 4.1.7.2. LWAPP Evaluation In LWAPP, an IEEE 802.11 WTP QoS message element is defined which is sent by the AC to the WTP to communicate quality of service configuration information. This message element contains fields that correspond to an access category in the IEEE 802.11e specifications and specifies whether data frames are to be tagged using IEEE 802.1p or DSCP. When the AC creates a WLAN on the WTP through the Add WLAN command, IEEE 802.11e information elements and the default QoS value may be included as parameters to configure the WLAN. Such parameters will Gwee Expires March 16, 2006 [Page 16] Internet-Draft Comparative Analysis September 2005 be used to determine the access category queue to be used for all packets for a particular user. 4.1.7.3. SLAPP Evaluation SLAPP defines an IEEE 802.11e element for configuring the IEEE 802.11e functions at the WTP by the AC. The element allows the support of WMM, WMM-SA and U-APSD. Thus the internal parameters to be used follow that of the standard used. The mapping between IEEE 802.11e access category and DSCP or IEEE 802.1d tags are defined in the WMM specification. It is expected that the AC and WTP follow this standard mapping for QoS over the wired and wireless aspects of the network. 4.1.7.4. WiCoP Evaluation The current specifications do not directly address this objective, although it is possible to implement a mapping of IEEE 802.11e AC to VLAN priority tags using the BSSID-TunnelID item. 4.1.7.5. Analysis Based on the description above, WiCoP does not directly address this objective. CTP and SLAPP follow a model in which packets on the wired aspect are tagged using a QoS policy and packets on the wireless aspect are tagged using the IEEE 802.11e standard. Mapping between the two QoS policies are performed on the WTP side. Although this model may work well, there is a lack of control for the AC in preserving the QoS requirements from the AC to the wireless terminal. Thus the effectiveness of CTP and SLAPP in meeting this objective may be undermined if the mapping is not done accurately. On the other hand, LWAPP does allow an AC to determine the QoS policy of a wireless terminal directly and thus is able to have more control on the QoS preservation along both wired and wireless aspects of the network. 4.1.7.6. Recommendation WiCoP does not directly address this objective and thus may be inappropriate to be considered for this objective. CTP and SLAPP exhibit a lack of control by AC in preserving the QoS requirements on both wired and wireless aspects of the network. LWAPP is able to allow an AC to have more control in determining the QoS policy of a wireless terminal directly. Thus in view of this advantage, the mechanism in LWAPP meets this objective in a most effective manner. Gwee Expires March 16, 2006 [Page 17] Internet-Draft Comparative Analysis September 2005 4.1.8. CAPWAP Protocol Security "The CAPWAP protocol MUST support mutual authentication of WTPs and the centralized controller. It must also ensure that information exchanges between them are secured." 4.1.8.1. CTP Evaluation CTP does not support a pre-shared key mechanism for mutual authentication. It assumes the use of digital certificates for mutual authentication between the WTP and AC. CTP also specifies that the encryption key is to be generated by the AC and transported securely to the WTP. 4.1.8.2. LWAPP Evaluation LWAPP specifies two different methods of authentication between the AC and WTP. The first method is asymmetric cryptography and makes use of X.509 certificates on both AC and WTP. The second method makes use of pre-shared keys that is predefined on both AC and WTP. The exchange of session keys for encrypting control traffic has also been specified in LWAPP. Session keys may be updated over time through the key update mechanism for added security. 4.1.8.3. SLAPP Evaluation SLAPP uses DTLS for the purpose of mutual authentication, key management, and encryption. As DTLS provides a secure and connectionless channel using a widely accepted and analyzed protocol, it reduces the need for redefinition in these aspects of the protocol. 4.1.8.4. WiCoP Evaluation WiCoP makes use of IPSec based authentication and encryption mechanisms to secure all exchanges. 4.1.8.5. Analysis WiCoP does not seem to explicitly specify how IPSec is used in its authentication and encryption mechanisms apart from mentioning that it is being used. It will be best if WiCoP provides more information on it. CTP is different from the other protocols in the sense that it makes use of digital certificates solely instead of pre-shared keys. LWAPP is able to support both the use of digital certificates and Gwee Expires March 16, 2006 [Page 18] Internet-Draft Comparative Analysis September 2005 pre-shared keys, thus providing a comprehensive support in the area of security. SLAPP makes use of an existing protocol DTLS to meet its objectives. The use of DTLS will certainly reduce review work required in the WG as compared to the use of other security mechanisms in other protocols. 4.1.8.6. Recommendation It is important to remember that realizing this objective should not involve any new work on security measures or the design of new security mechanisms. The aim of this objective is to ensure sufficient security for the protocol using existing and widely accepted security mechanisms if possible. Involving new work or excessive review on the various security mechanisms may hamper the progress of the finalization of the CAPWAP protocol. Thus in view of this, the mechanism used in SLAPP meets this objective in a most practical manner as it involves the least review work. 4.1.9. System-wide Security "According to the CAPWAP objectives, it states that "The design of the CAPWAP protocol MUST NOT allow for any compromises to the WLAN system by external entities." 4.1.9.1. CTP Evaluation CTP does not define a data path encryption mechanism as it assumes that there will be an end-to-end encrypted tunnel for sensitive data. CTP control messages will be sent encrypted with AES-CCM. 4.1.9.2. LWAPP Evaluation LWAPP control protocol is secured through a key exchange that is protected either through a pre-shared key or via an X.509 certificate. For use of X.509 certificate, LWAPP specifies a certificate profile that limits a certificate to a specific role. PMK sharing is not permitted and the PMK is always held at the AC. This arrangement is to facilitate support for future IEEE 802.11 extensions as well as detection and taking action against rouge attacks. 4.1.9.3. SLAPP Evaluation SLAPP uses DTLS to protect its communication. PMK sharing is not permitted and SLAPP specifies that the PMK resides on the authenticator. Gwee Expires March 16, 2006 [Page 19] Internet-Draft Comparative Analysis September 2005 4.1.9.4. WiCoP Evaluation WiCoP does not yet address the issue of potential problems due to PMK sharing. 4.1.9.5. Analysis Similarly to the analysis provided in the earlier objective, LWAPP and SLAPP provide sufficient security measures as compared to the rest. 4.1.9.6. Recommendation Similarly to the recommendations in the earlier objective, the mechanism in SLAPP meets this objective in a most practical manner. 4.1.10. IEEE 802.11i Considerations "The CAPWAP protocol MUST determine the exact structure of the centralized WLAN architecture in which authentication needs to be supported, i.e. the location of major authentication components. This may be achieved during WTP initialization where major capabilities are distinguished. The protocol must allow for the exchange of key information when authenticator and encryption roles are located in distinct entities." 4.1.10.1. CTP Evaluation CTP considers the IEEE 802.11i security function in two components namely EAP authenticator and key management. The two components can be co-located or separate on the WTP or the AC. Any exchange of security association information between the AC and the WTP is protected either by IEEE 802.11i mechanisms or by CTP mechanisms. 4.1.10.2. LWAPP Evaluation LWAPP defines both local and split MAC approaches for this objective. For Split MAC mode, the authentication is centralized but encryption is performed either at the AC or WTP. For local MAC mode, the authentication lies in the AC but encryption occurs at the WTP. In both modes, PMK is maintained in the AC. 4.1.10.3. SLAPP Evaluation SLAPP supports both local MAC and split MAC architectures for this objective. It takes a step further in defining a bridged and tunneled version of the local MAC architecture, and a distinction Gwee Expires March 16, 2006 [Page 20] Internet-Draft Comparative Analysis September 2005 between L2 crypto being handled at the WTP versus L2 crypto being handled at the AC for the split MAC architecture. The WTP and AC agree on the type of architecture during the registration phase of the SLAPP state machine. When L2 crypto is performed at the AC, encrypted IEEE 802.11 frames will be tunneled to the AC. If L2 crypto is performed at the WTP, decrypted IEEE 802.3 frames will be tunneled. When the IEEE 802.1x authenticator is located on the AC and L2 crypto is performed by the WTP, the AC will send PTKs and GTKs to the WTP through a control message that is protected by DTLS. 4.1.10.4. WiCoP Evaluation WiCoP addresses a scenario in which the authenticator is separated from the point of encryption for both Split MAC and Local MAC architectures. In this case, a Key Config message is used to explicitly transport the 3rd message of the four-way handshake from the authenticator to the point of encryption. Thus the KeyMIC and KeyRSC can be calculated. 4.1.10.5. Analysis From the above description, all the four protocols consider this objective in their design. All the protocols consider the specific case in which the authenticator is separated from the point of encryption and thus a possible solution to address this condition. In accordance with this objective, it can be observed that WiCoP reveals a specific scenario where the Key Config message is used. However, this is not explicitly specified in other protocols. Thus this mechanism in WiCoP satisfies the objective exactly with its Key Config message. This message directly addresses the objective. But it is also noted that the rest of the protocols are also compliant with this objective. 4.1.10.6. Recommendation WiCoP provides the greatest details in relation to this objective. The specifications clearly describe how the Key Config message is used to exchange counter information in designs where the authentication function and encryption point are located in different WLAN devices. So the WiCoP mechanism addresses this objective in the most complete manner. 4.1.11. Interoperability Objective "The CAPWAP protocol MUST include sufficient capabilities negotiations to distinguish between major types of WTPs." Gwee Expires March 16, 2006 [Page 21] Internet-Draft Comparative Analysis September 2005 4.1.11.1. CTP Evaluation In CTP, a capabilities exchange mechanism is specified that allows a WTP and AC to negotiate their operational mode. In Split MAC mode, the WTP will forward all wireless MAC management traffic to the AC. In local MAC mode, the 802.11 management frames will be terminated at the WTP. In Split MAC mode, the WTP will forward all data traffic to the AC with the format of the traffic to be IEEE 802.11 or IEEE 802.3 depending on the mode of the control channel. In Local MAC mode, the data frames will be bridged locally by the WTP to its switching segment. The switching segment may be present locally at the WTP or at the AC. For AC handled bridged access, the CTP protocol provides a tunneling method for IEEE 802.3 frame encapsulation. 4.1.11.2. LWAPP Evaluation The LWAPP protocol is capable of supporting both local and split MAC approaches. It specifies the division of labour for both local and split MAC architectures. A WTP advertises its mode of operation through the WTP Mode and Type message element. 4.1.11.3. SLAPP Evaluation SLAPP supports not only both the split-MAC and local-MAC architecture, but also defines a set of sub-modes for each of these architectures and appropriate split of AP functions between the AC and the WTP for each of these sub-modes. A WTP indicates its support of the CAPWAP modes defined in SLAPP during the registration phase. The AC will then select a CAPWAP mode that it can operate with the WTP. 4.1.11.4. WiCoP Evaluation WiCoP makes use of a 'M' field in its header to distinguish between local MAC and split MAC WTPs. The AC processes each WiCoP packet accordingly based on this information. So using 'M' field, an AC can handle packets from different types of WTPs faster and with fewer processing steps. 4.1.11.5. Analysis From the above description, the four proposed protocols have sufficient capabilities to distinguish between major types of WTP. Gwee Expires March 16, 2006 [Page 22] Internet-Draft Comparative Analysis September 2005 The difference between these protocols lies in their form of mechanisms and the complexity of these mechanisms. SLAPP supports the widest range of WTP architecture modes but it also incurs a high level of complexity. Although CTP and LWAPP supports this objective with less complexity, but negotiation must takes place between the WTP and AC beforehand in order to find out the types of architectures of the WTP. WiCoP seem to offer a very practical and yet simple solution in meeting this objective by making use a single 'M' field. 4.1.11.6. Recommendation SLAPP supports the most number of modes of CAPWAP architectures although it also incurs a high level of complexity on the protocol design. CTP and LWAPP are less complex but an extra step is required in both protocols to negotiate the types of architectures used in WTPs. On the other hand, WiCoP offers a simple and practical solution by making use of a 'M' field. Thus it can be inferred that the mechanism used in WiCoP satisfies this objective the best with its integrated approach to operability. 4.1.12. Protocol Specifications "Any WTP or WLAN controller vendor or any person MUST be able to implement the CAPWAP protocol from the specification itself and by that it is required that all such implementations do interoperate." 4.1.12.1. CTP Evaluation The CTP specification has provided full specification of the protocol and its operation within WTPs and ACs. It also indicates the configuration and statistics capabilities based on MIB specifications from relevant IEEE standards. 4.1.12.2. LWAPP Evaluation The LWAPP specification has provided full specification of the protocol that ensures interoperability for any WTP or AC vendors. 4.1.12.3. SLAPP Evaluation SLAPP does not any prior exchange of technical information between AC and WTP vendors. By implementing just the protocol, interoperability is achieved as long as both the WTP and AC can support the same mode of CAPWAP architectures. 4.1.12.4. WiCoP Evaluation WiCoP is a complete specification and does not require any additional Gwee Expires March 16, 2006 [Page 23] Internet-Draft Comparative Analysis September 2005 proprietary information to implement. 4.1.12.5. Analysis From the objective, it mainly suggests a need for final protocol to be as detailed as possible such that any implementation problems can be minimized for interoperability. 4.1.12.6. Recommendation Since all the specifications are complete, it can be stated that the mechanisms used in all protocols meet this objective in an equally effective manner. 4.1.13. Vendor Independence "A WTP vendor SHOULD be able to make modifications to hardware without any WLAN controller vendor involvement." 4.1.13.1. CTP Evaluation CTP does not assume any reliance on hardware architectures for WTPs and ACs in its specifications. 4.1.13.2. LWAPP Evaluation As LWAPP is fully specified, it is assumed that any WTP vendors can create the actual implementation of the protocol on their hardware. This allows them to make any necessary changes without the need to involve any AC vendor. 4.1.13.3. SLAPP Evaluation Since SLAPP satisfies the earlier objective, it also satisfies this objective. 4.1.13.4. WiCoP Evaluation WiCoP is a complete specification and does not require any additional proprietary information to implement. 4.1.13.5. Analysis Analysis is rather straightforward in this case. From the design of the four protocols, they do not require a WTP vendor to involve an AC vendor in making modifications to its own products. Gwee Expires March 16, 2006 [Page 24] Internet-Draft Comparative Analysis September 2005 4.1.13.6. Recommendation Based on the above analysis, the mechanisms used in all the four protocols fulfill this objective effectively. 4.1.14. Vendor Flexibility "The CAPWAP protocol MUST NOT limit WTP vendors in their choice of local-MAC or split-MAC WTPs. It MUST be compatible with both types of WTPs." 4.1.14.1. CTP Evaluation Based on implementation, CTP has been found to be operable without knowledge of underlying vendor hardware. 4.1.14.2. LWAPP Evaluation Based on implementation, LWAPP supports both Local and MAC approaches and allows for third party WTP vendors to work with both approaches without restriction. 4.1.14.3. SLAPP Evaluation SLAPP provides support for both local MAC and split MAC architectures along with their sub-modes. Assuming a common mode supported by both the WTP and AC, the AC can select this mode for operation with WTP. 4.1.14.4. WiCoP Evaluation WiCoP is a complete specification and does not require any additional proprietary information to implement. 4.1.14.5. Analysis Based on the above description, the mechanisms used in all the four protocols are able to meet this objective. 4.1.14.6. Recommendation The mechanisms used in all the four protocols are able to meet this objective in an equally effective manner. 4.1.15. NAT Traversal "The CAPWAP protocol MUST NOT prevent the operation of established methods of NAT traversal." Gwee Expires March 16, 2006 [Page 25] Internet-Draft Comparative Analysis September 2005 4.1.15.1. CTP Evaluation In CTP, an authentication mechanism is defined to establish a secure connection without depending on MAC or IP address. CTP packets are normally transported via UDP. As CTP is transported above the IP layer, it will work properly through NAT devices. The WTP can be statically configured to discover the AC through a NAT segment. 4.1.15.2. LWAPP Evaluation LWAPP considers two situations in which it may be used in conjunction with LWAPP. The first scenario is where a WTP is behind a NAT system. The second scenario is where the AC sits behind a NAT. For the first scenario, the LWAPP protocol can easily traverses NAT systems since all communications is performed over IP using UDP. For the second scenario, there will a few issues which requires user intervention and predefined configuration to be done for NAT compliance. 4.1.15.3. SLAPP Evaluation SLAPP does not provide any specifications on this objective. 4.1.15.4. WiCoP Evaluation WiCoP does not provide any specifications on this objective. 4.1.15.5. Analysis The aim of this objective is to ensure that the CAPWAP protocol operates above the layer at which a NAT device operates. In general, the four proposals are specified to operate above the IP layer. So their operations should not affected by NATs. There may be some instances in which protocol implementations will need to be adapted, e.g. in terms of AC/WTP identifications. 4.1.15.6. Recommendation All the four protocols have been specified to operate above the IP layer. It is therefore considered that their operations will not be affected by NAT traversals. So all four protocols are equally applicable for this objective. 4.2. Desirable Objectives In this section, a comparison of the various protocols is made against each CAPWAP Desirable Objective. A description of each Desirable Objective and statements from the evaluation draft of each Gwee Expires March 16, 2006 [Page 26] Internet-Draft Comparative Analysis September 2005 protocol are provided for reference. A final analysis is given at the end of each objective. 4.2.1. Multiple Authentication Mechanisms "The CAPWAP protocol MUST support different authentication mechanisms in addition to IEEE 802.11i." 4.2.1.1. CTP Evaluation CTP is wireless terminal agnostic and as the PMK key exchange is generic, it does not prevent the operation of any other authentication mechanisms. 4.2.1.2. LWAPP Evaluation LWAPP allows for a separate security policy for every WLAN created. The Encryption Policy field of the Add WLAN message element defines static and dynamic WEP encryption, as well as TKIP and AES. 4.2.1.3. SLAPP Evaluation SLAPP does not restrict the use of other authentication techniques other than IEEE 802.11i. Typically different techniques are used on separate SSIDs which can be based on one WTP. 4.2.1.4. WiCoP Evaluation WiCoP does not prevent the operation of any authentication mechanism. It is generic to support all types of authentication mechanisms. 4.2.1.5. Analysis From the above description, all the four protocols provide some support for use of different authentication techniques. However, it is clear that LWAPP and SLAPP provide support for multiple authentications in a more effective manner. The use of SSIDs in determining the type of security policy used can help in ensuring a standardized form of security measure for each logical network. This helps to reduce implementation issues. 4.2.1.6. Recommendation Based on the above analysis, the mechanisms used in both SLAPP and LWAPP are the better candidates among the four to fulfill this objective effectively. Gwee Expires March 16, 2006 [Page 27] Internet-Draft Comparative Analysis September 2005 4.2.2. Support for Future Wireless Technologies "CAPWAP protocol messages MUST be designed to be extensible for specific layer 2 wireless technologies. It should not be limited to the transport of elements relating to IEEE 802.11." 4.2.2.1. CTP Evaluation CTP specification considers other layer 2 wireless technologies in its capabilities exchange phase. In the event that there are layer 2 wireless specific elements that need to be added, those can be easily supported by extensions to the protocol. 4.2.2.2. LWAPP Evaluation LWAPP specification describes the process that must be followed in order to define a wireless technology binding for LWAPP. It also defines the IEEE 802.11 binding in its specification for this objective. 4.2.2.3. SLAPP Evaluation SLAPP supports this objective by providing a mechanism to negotiate a technology specific control protocol in its framework. 4.2.2.4. WiCoP Evaluation WiCoP is generic and extensible to support future developments in wireless technologies. 4.2.2.5. Analysis Based on the specifications of the four protocols, it is clear that these protocols do consider the possible use of other layer 2 wireless technologies in their design. Although LWAPP provides some definition of the process of binding a wireless technology to the protocol, it mainly describes the IEEE 802.11 binding in the rest of the specifications. It will be best if more information can be provided in the form of a generic technology binding process framework. On the other hand, SLAPP does provide an excellent framework that helps to extend its use to other future wireless technologies. Its unique protocol design helps in providing some form of modularity in the area of wireless technology used and thus protocol redesign, if required, is restricted mainly to the technology-dependent component only. Gwee Expires March 16, 2006 [Page 28] Internet-Draft Comparative Analysis September 2005 4.2.2.6. Recommendation Although all the four protocols meet this objective, the mechanism used in SLAPP does have an advantage over the rest by virtue of its framework. In the event of protocol redesign or extension required to accommodate any future development, only the technology-dependent component is affected. 4.2.3. Support for New IEEE Requirements "The CAPWAP protocol MUST be openly designed to support new IEEE 802.11 definitions and extensions." 4.2.3.1. CTP Evaluation CTP defines an abstraction layer to accommodate any type of wireless MAC technology. New IEEE 802.11 amendments can be easily accommodated by the protocol although more work is required to interpret the impact of the amendment on both the AC and the WTP. 4.2.3.2. LWAPP Evaluation The LWAPP protocol was designed to be able to accommodate new IEEE extensions defined, although it is possible that some future extensions will require some additional IETF CAPWAP standardization work. 4.2.3.3. SLAPP Evaluation SLAPP defines a raw IEEE 802.11 frame support that allows any IEEE 802.11 frame to be transmitted to the AC, regardless of architecture. Should there be a new IEEE 802.11 amendment that requires fundamental changes to the current model, an additional technology dependent protocol can be defined and negotiated between AC and WTP. 4.2.3.4. WiCoP Evaluation WiCoP is generic and extensible to support future developments in wireless technologies and standards. 4.2.3.5. Analysis Based on the specifications of the four protocols, all the protocols provide support for new IEEE 802.11 definitions. Among them, SLAPP provides a favourable scheme to implement the addition of new IEEE 802.11 amendments easily. By virtue of its framework, it can retain much of its technology independent component and add just a new control protocol to include the new definition in its operation. Gwee Expires March 16, 2006 [Page 29] Internet-Draft Comparative Analysis September 2005 4.2.3.6. Recommendation Based on the above analysis, the mechanism used in SLAPP has an advantage over the rest in meeting this objective effectively. 4.2.4. Interconnection Objective "The CAPWAP protocol MUST NOT be constrained to specific underlying transport mechanisms." 4.2.4.1. CTP Evaluation CTP is independent to the transport technology as it makes use of UDP to transmit its packet. 4.2.4.2. LWAPP Evaluation LWAPP packets are transported using UDP or Ethernet as transports. Support for transport capabilities has been included within the LWAPP protocol itself. Thus, it is expected that LWAPP is sufficiently independent of the transport protocol used. 4.2.4.3. SLAPP Evaluation SLAPP makes use of IPv4 to transport its packets and thus its operation is independent of the L2 interconnection technologies. It is expected that SLAPP will work over IPv6 as well. 4.2.4.4. WiCoP Evaluation WiCoP does not rely of the specifics of underlying transport technologies. Although WiCoP uses UDP, it does not require any UDP- specific information for its operation. 4.2.4.5. Analysis By virtue of their protocol design, the four protocols are not constrained to specific underlying transport mechanisms. 4.2.4.6. Recommendation From the specifications given, the mechanisms used in all the protocol proposals are able to meet this objective in an equally effective manner. 4.2.5. Access Control "The CAPWAP protocol MUST be capable of exchanging information Gwee Expires March 16, 2006 [Page 30] Internet-Draft Comparative Analysis September 2005 required for access control of WTPs and wireless terminals." 4.2.5.1. CTP Evaluation CTP defines connection, disconnection and authentication messages that control the access of wireless terminals. Furthermore, during the registration phase, the WTP have to provide an AP-ID field for verification by the AC. This identification mechanism can be considered as a means of access control of the WTP. 4.2.5.2. LWAPP Evaluation As LWAPP tunnels 802.11 MAC management frames to the AC, the AC has complete control over the behaviour of the network. In addition, an AC performs authorization of WTPs before connection for security reasons. 4.2.5.3. SLAPP Evaluation As SLAPP supports multiple WTP authentication models, it allows the AC to have full control over restricting WTPs based on the access control policies. The access control functions for wireless terminals consist of several components. For example, the cryptographic and associated authentication requirements can be configured per-logical group, which can be used to control access to specific logical groups. Additional access control policies may be enforced at the AC if tunneling of frames is required to the AC. 4.2.5.4. WiCoP Evaluation WiCoP uses the Terminal Data message element to exchange association and authentication information on wireless terminals. This is used by the AC to supervise access control. 4.2.5.5. Analysis Based on the above descriptions, the mechanisms used in all four proposed protocols are able to meet this objective. 4.2.5.6. Recommendation The mechanisms used in all four protocols are able to meet this objective equally well. Gwee Expires March 16, 2006 [Page 31] Internet-Draft Comparative Analysis September 2005 5. Comparative Analysis As mentioned in the introduction, this document contains a comparative analysis of the four protocols. From all the analysis of the various protocols for each objective, every protocol has its own unique strengths in meeting the objectives. Ideally, the final CAPWAP protocol should have a combination of all the best strengths of the various protocols. The table below lists the various protocols and their best strengths in meeting the CAPWAP objectives. Gwee Expires March 16, 2006 [Page 32] Internet-Draft Comparative Analysis September 2005 CAPWAP Objectives Recommended Protocol Mechanisms Logical Groups WiCoP Support for Traffic Separation LWAPP/SLAPP Wireless Terminal Transparency All Configuration Consistency LWAPP/CTP Firmware Trigger WiCoP Monitor System WiCoP Resource Control LWAPP Protocol Security SLAPP System Security SLAPP 802.11i Considerations WiCoP Interoperability WiCoP Product Specifications All Vendor Independence All Vendor Flexibility All NAT Traversal All Multiple Authentication SLAPP/LWAPP Future Wireless SLAPP New IEEE Requirements SLAPP Interconnection All Access Control All Table 1: Recommended mechanisms for CAPWAP Objectives Thus it can be inferred that the ideal CAPWAP protocol should have a combination of the best mechanisms from the various proposals. For example, WiCoP has advantage for logical group objective while LWAPP has advantage for resource control objective. Thus the final CAPWAP Gwee Expires March 16, 2006 [Page 33] Internet-Draft Comparative Analysis September 2005 protocol should make use of WiCoP's strength and combine it with LWAPP's strength. Gwee Expires March 16, 2006 [Page 34] Internet-Draft Comparative Analysis September 2005 6. Conclusion In conclusion, a comparative evaluation of the various proposed protocols has been provided. Recommendations have been given on the various strengths of the protocols. The final CAPWAP protocol should contain a combination of these strengths. To do this, one suggestion is to combine the mechanisms involved in these strengths into the final CAPWAP protocol. However, this may involve some redesigning work and careful analysis of the impact and interaction among these mechanisms. Gwee Expires March 16, 2006 [Page 35] Internet-Draft Comparative Analysis September 2005 7. Security Considerations Security aspects have been discussed in the four proposals. Realizing the recommendations made in this document should not affect the security considerations previously accounted for in the four proposals. In addition, there should be no introduction of new security threats due to realization of recommendations in this document. 8. References [I-D.ietf-capwap-arch] Yang, L., Zerfos, P., and E. Sadot, "Architecture Taxonomy for Control and Provisioning of Wireless Access Points(CAPWAP)", draft-ietf-capwap-arch-06 (work in progress), November 2004. [I-D.ietf-capwap-objectives] Govindan, S., "Objectives for Control and Provisioning of Wireless Access Points (CAPWAP)", draft-ietf-capwap-objectives-03 (work in progress), June 2005. [I-D.ietf-capwap-problem-statement] Calhoun, P., "CAPWAP Problem Statement", draft-ietf-capwap-problem-statement-02 (work in progress), September 2004. [I-D.iino-capwap-wicop] Iino, S., "Wireless LAN Control Protocol (WiCoP)", draft-iino-capwap-wicop-02 (work in progress), June 2005. [I-D.narasimhan-ietf-slapp] Narasimhan, P., "SLAPP : Secure Light Access Point Protocol", draft-narasimhan-ietf-slapp-01 (work in progress), June 2005. [I-D.ohara-capwap-lwapp] Calhoun, P., "Light Weight Access Point Protocol", draft-ohara-capwap-lwapp-03 (work in progress), July 2005. [I-D.singh-capwap-ctp] Singh, I., "CAPWAP Tunneling Protocol (CTP)", draft-singh-capwap-ctp-02 (work in progress), July 2005. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Gwee Expires March 16, 2006 [Page 36] Internet-Draft Comparative Analysis September 2005 Author's Address Richard Choon Lim Gwee Republic Polytechnic Tanglin Campus 1, Kay Siang Road Singapore 248922 Singapore Phone: +65 6419 6244 Email: richard.gwee@rp.edu.sg Gwee Expires March 16, 2006 [Page 37] Internet-Draft Comparative Analysis September 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Gwee Expires March 16, 2006 [Page 38]