Internet DRAFT - draft-francisco-capwap-ctp-evaluation

draft-francisco-capwap-ctp-evaluation




   Operations Group                                            I. Singh 
   Internet Draft                                          P. Francisco 
   Expires: December 2005                                 M. Montemurro 
                                                       Chantry Networks 
                                                              June 2005 
                                                                        
    
    
               Evaluation of CAPWAP Tunneling Protocol (CTP) 
               draft-francisco-capwap-ctp-evaluation-01.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 December 8, 2005. 
    
Copyright Notice 
    
      Copyright (C) The Internet Society (2005). 
    
    
Abstract 
    
   This document presents a self evaluation of the CAPWAP Tunneling 
   Protocol (CTP) with respect to the requirements presented in the 
   CAPWAP Objectives draft.  This work is to aid in the official working 
   group evaluation of the candidate protocols for CAPWAP. 
       
    
 
 
Francisco              Expires - December 2005               [Page 1] 
 Internet-Draft             CTP Evaluation                   June 2005 
 
 
Table of Contents 
       
   1. Definitions....................................................3 
      1.1 Conventions used in this document..........................3 
   2. Introduction...................................................3 
   3. Objectives Responses...........................................3 
      3.1 Mandatory and Accepted Objectives..........................3 
         3.1.1 Logical Groups........................................3 
         3.1.2 Support for Traffic Separation........................3 
         3.1.3 Wireless Terminal Transparency........................4 
         3.1.4 Configuration Consistency.............................4 
         3.1.5 Firmware Trigger......................................4 
         3.1.6 Monitoring and Exchange of System-wide Resource State.5 
         3.1.7 Resource Control Objective............................5 
         3.1.8 CAPWAP Protocol Security..............................6 
         3.1.9 System-wide Security..................................6 
         3.1.10 IEEE 802.11i Considerations..........................7 
         3.1.11 Interoperability Objective...........................7 
         3.1.12 Protocol Specifications..............................8 
         3.1.13 Vendor Independence..................................8 
         3.1.14 Vendor Flexibility...................................9 
         3.1.15 NAT Traversal........................................9 
      3.2 Desirable Objectives.......................................9 
         3.2.1 Multiple Authentication Mechanisms....................9 
         3.2.2 Support for Future Wireless Technologies.............10 
         3.2.3 Support for New IEEE Requirements....................10 
         3.2.4 Interconnection Objective............................10 
         3.2.5 Access Control.......................................11 
      3.3 Non-objectives............................................11 
         3.3.1 Support for Non-CAPWAP WTPs..........................11 
         3.3.2 Technical Specifications.............................11 
      3.4 Operator Requirements.....................................12 
         3.4.1 AP Fast Handoff......................................12 
   4. Compliance Table..............................................12 
   5. Security considerations.......................................13 
   6. References....................................................13 
   7. Author's Addresses............................................13 
      Intellectual Property and Copyright Statements ...............13 











 
 
Francisco              Expires - December 2005               [Page 2] 
 Internet-Draft             CTP Evaluation                   June 2005 
 
 
    
1. 
  Definitions 
    
1.1 
   Conventions used in this document 
    
   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 RFC-2119 [1] 
 
2. 
  Introduction 
 
   The authors of the CAPWAP Tunneling Protocol(CTP) [2] believe that 
   CTP provides a robust solution in the form of a protocol that 
   addresses the issues raised in the CAPWAP Problem Statement draft 
   [3].  CTP can be run over an L2 or an L3 network and it is extensible 
   to support WTPs which terminate other radio technologies than IEEE 
   802.11. 
    
   Given below is a brief analysis of the protocol with respect to the 
   objectives draft [4] that has been presented and discussed in the WG. 
 
3. 
  Objectives Responses 
3.1 
   Mandatory and Accepted Objectives   
    
3.1.1 
     Logical Groups 
   The ability to control and manage physical WTPs in terms of logical 
   groups. 
    
3.1.1.1 
       Protocol Evaluation 
   The CTP protocol allows the AP and WTP to exchange  information on 
   logical groups as part of the capabilities exchange 
   (CTP_CAP_REQ/RESP). The AC uses this information to provision logical 
   groups on the WTP as part of the configuration transaction. 
   The CTP header in the control and data messages provides a mechanism 
   to segment traffic between logical groups.  
     
3.1.1.2 
       Compliance 
   CTP is compliant with this objective. 
    
3.1.2 
     Support for Traffic Separation 
   This objective pertains to the need to maintain separation of control 
   and data traffic in the operation of the protocol. 
    
3.1.2.1 
       Protocol Evaluation 
   CTP provides specific message types control and data traffic. CTP 
   data traffic can either be tunneled to the AC or bridged locally at 
   the WTP. Control traffic will always travel between the AC and the 
   WTP. 
    
 
 
Francisco              Expires - December 2005               [Page 3] 
 Internet-Draft             CTP Evaluation                   June 2005 
 
 
3.1.2.2 
       Compliance 
   CTP is compliant with this objective. 
    
3.1.3 
     Wireless Terminal Transparency 
   This objective specifies the need for the protocol to be client 
   agnostic.  That is, the wireless terminals need not be aware of the 
   existence of the CAPWAP protocol running underneath. 
    
3.1.3.1 
       Protocol Evaluation 
   CTP defines a protocol for the provisioning and control of WTPs. The 
   protocol is agnostic to wireless MAC technology and entirely 
   transparent to a wireless terminal. Shipping products using CTP 
   demonstrate that this protocol does not have any adverse effects, 
   interoperability or otherwise, on the wireless terminals. 
    
3.1.3.2 
       Compliance 
   CTP is compliant with this objective. 
    
3.1.4 
     Configuration Consistency 
   This objectives pertains to the protocolÆs ability to provide 
   consistent configuration state information of the WTPs at the AC.   
    
3.1.4.1 
       Protocol Evaluation 
   CTP defines a configuration transaction where the AC can exchange 
   configuration with the WTP. The mechanism uses an SNMP data payload 
   encapsulated inside a CTP frame. The WTP must acknowledge the 
   configuration update to confirm that the configuration state on the 
   WTP is synchronized with the AC. 
    
   The protocol makes use of the SNMP MIB that is defined in the IEEE 
   802.11 standard and its amendments. This provides a generic mechanism 
   for configuration which is agnostic to wireless technologies and 
   updates to wireless standards.  
    
3.1.4.2 
       Compliance 
   CTP is compliant with this objective. 
 
3.1.5 
      Firmware Trigger 
   This objective states that the protocol must have the ability to 
   trigger WTP firmware updates.  It does not necessarily state the need 
   for the protocol to integrate a software update mechanism within the 
   protocol itself. 
    
3.1.5.1 
       Protocol Evaluation 
   After the device capability exchange phase (CTP-CAP_REQ/RESP) which 
   allows for the identification of the type of WTP connecting, CTP 
   protocol specifies a phase of firmware image validation (CTP-
   Software-upgrade-req/resp, section 5.1.5) where the WTP indicates the 

 
 
Francisco              Expires - December 2005               [Page 4] 
 Internet-Draft             CTP Evaluation                   June 2005 
 
 
   version of its firmware to the Controller. The controller can 
   evaluate the version of the WTP software and signal the WTP to update 
   its image. CTP does not specify the actual method for firmware 
   upgrade, but rather assumes the application of standardized binary 
   transport protocols (FTP/TFTP).  
    
3.1.5.2 
       Compliance 
   CTP is compliant with this objective. 
    
3.1.6 
      Monitoring and Exchange of System-wide Resource State 
   This objective states that the protocol must incorporate the ability 
   for the WTP to send statistics, congestion indications and other 
   pertinent wireless state information to the AC. 
    
3.1.6.1 
        Protocol Evaluation 
   CTP protocol defines frames for the periodic exchange of a WTPÆs 
   operational statistics (CTP-Stats-req/resp, CTP-Stats-Notify, Section 
   5.2.7-9). The protocol uses an SNMP format for the statistics based 
   on MIB definitions from the 802.11 standard and its amendments. This 
   protocol mechanism is agnostic to wireless technology and updates to 
   existing wireless standards. 
    
3.1.6.2 
        Compliance 
   CTP is compliant with this objective. 
 
3.1.7 
      Resource Control Objective 
   This objective pertains to the ability of the protocol to provide a 
   mapping mechanism of the IEEE 802.11e QOS priorities across the 
   wireless and wired infrastructure. 
    
3.1.7.1 
        Protocol Evaluation 
   CTP defines a two tiered mechanism for QoS that addresses the 
   switching segment as well as the wireless medium. The QoS strategy 
   for the protocol involves mapping the QoS marking of the data frame 
   to the CTP frame.  
    
   Across the switched segment, CTP is an IP protocol that provides 
   several mechanisms to ensure the preservation of QoS markers within 
   the original data packet. The protocol header (CTP Section 4.1) 
   natively defines an 8-bit field for relaying of QoS policy related 
   information in a transport independent manner. Alternatively, CTP 
   could use 802.1p tagging to preserve QoS across the switched segment.  
   This allows the WTP and Controller to classify and guarantee the 
   preservation of QoS across the switched network.  
    
   CTP makes use of the 802.11e standard to preserve QoS across the 
   wireless medium. The mapping for QoS data frames to 802.11e QoS 
   frames is defined in the 802.11e amendment to the 802.11 standard.   

 
 
Francisco              Expires - December 2005               [Page 5] 
 Internet-Draft             CTP Evaluation                   June 2005 
 
 
    
3.1.7.2 
        Compliance 
   CTP is compliant with this objective. 
    
3.1.8 
      CAPWAP Protocol Security 
   This objective concerns the security of the CAPWAP protocol.  The 
   protocol must support mutual authentication of the WTP and the AC and 
   the communication channel between the two entities must be secured.  
   In addition, however, the protocol must not preclude the possibility 
   of supporting asymmetric authentication mechanisms. 
    
3.1.8.1 
        Protocol Evaluation 
   First of all, as currently defined, CTP does not support a pre-shared 
   key mechanism for mutual authentication.  It assumes the existence of 
   digital certificates on the WTP and AC.  The mutual authentication 
   mechanism between WTP and AC using digital certificates as described 
   in the CTP draft is very similar to the method employed in the LWAPP 
   draft [5].  As such, some of the recent comments on the WG email list 
   regarding the security of LWAPPÆs mutual authentication also applies 
   to CTP.  Specifically in the area of the generation of the encryption 
   key.  Currently CTP specifies that the encryption key is generated by 
   the AC and is securely transported to the WTP.  An obvious 
   improvement would be for the WTP and the AC to mutually contribute to 
   the generation of the encryption key by providing independently 
   generated random material for the session keys. 
    
   Also, based on discussion on the WG list it is not clear whether the 
   use of pre-shared key for mutual authentication is required or simply 
   that the authentication must be mutual.  Nevertheless, we believe 
   that adding another method of mutual authentication, ie. with using 
   pre-shared keys, will enhance the flexibility of the CTP protocol, 
   but at the cost of increased protocol complexity. 
    
3.1.8.2 
        Compliance 
   CTP is partially compliant with this objective. 
    
3.1.9 
      System-wide Security 
   The protocol must not adversely affect the security of the wireless 
   and wired networks on which it runs. 
    
3.1.9.1 
        Protocol Evaluation 
   CTP defines that any exchanges of control based material such as PMK 
   is natively encrypted. All Control messages are mutually encrypted 
   between the WTP and controller. In lieu of a thorough security and 
   cryptographic analysis of the protocol by peers, the authors believe 
   that the encryption/keying mechanism currently provides adequate 
   protection against un-authorized compromise of the transported 
   information which, in turn, would not adversely affect the security 
   of the wireless or wired network. 
 
 
Francisco              Expires - December 2005               [Page 6] 
 Internet-Draft             CTP Evaluation                   June 2005 
 
 
    
    
    
3.1.9.2 
        Compliance 
   The protocol is partially compliant with this objective pending a 
   thorough security and cryptographic review. 
    
3.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. 
    
3.1.10.1 
         Protocol Evaluation 
   The CTP protocol has separated the 802.11i security function into two 
   components, EAP Authenticator and Key Management. The EAP 
   Authenticator and Key Management functions provide a natural 
   delineation point between 802.11i functions. The location of the 
   components is negotiated between the AC and WTP during the 
   capabilities exchange and registration. The components can either 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 802.11i mechanisms or by CTP mechanisms.  
    
3.1.10.2 
         Compliance 
   CTP is compliant with this objective. 
    
3.1.11 
       Interoperability Objective 
   The objective specifies that the protocol must include a capabilities 
   exchange mechanism so that different types of WTPs can be managed by 
   ACs.  That is, local-MAC and split-MAC WTPs may be recognized by the 
   AC through protocol exchange and appropriate handling within the 
   protocol would ensue as a result of this capability exchange.   
    
3.1.11.1 
         Protocol Evaluation 
   The CTP protocol as specified, provides a mechanism for capabilities 
   exchange (CTP-caps-req/resp) that allows the WTP and the Controller 
   to negotiate their operational mode. The capabilities exchange for 
   control and data traffic is treated independently.  
    
   Control traffic in split-MAC mode indicates that the WTP will forward 
   all wireless MAC management traffic (i.e. IEEE 802.11) to the AC.  
    

 
 
Francisco              Expires - December 2005               [Page 7] 
 Internet-Draft             CTP Evaluation                   June 2005 
 
 
   Control traffic in local-MAC mode indicates that all 802.11 
   management frames will terminate at the WTP. CTP defines update 
   messages to allow the WTP to signal the AC for updates to wireless 
   client connection states. 
    
   Data traffic in split-MAC modes indicates that the WTP will forward 
   all traffic to the AC. The format for the traffic can be either 
   wireless MAC dependent (i.e. IEEE 802.11) or IEEE 802.3 depending 
   whether the control channel is split-MAC or local-MAC.  
    
   Data traffic in local-MAC mode indicates that data frames will be 
   bridged locally by the AP to its switching segment. The switching 
   segment may be present locally at the AP or at the Controller. For 
   Controller handled bridged access the CTP protocol provides a 
   tunneling method for 802.3 frame encapsulation.  
 
3.1.11.2 
         Compliance 
   CTP is compliant with this objective. 
 
3.1.12 
      Protocol Specifications  
   This objective states that any vendor of a WTP or AC or any person 
   may implement the CAPWAP protocol and that all such implementations 
   should interoperate. 
    
3.1.12.1 
         Protocol Evaluation 
   CTP specification fully specify the protocol and its operation within 
   WTPs and ACs.  It also indicates the configuration and statistics 
   capabilities come from MIB specifications that are published by IEEE 
   that fully describe the managed objects within an WTP.  The authors 
   believe that the work done by the IEEE will enable full 
   interoperability as the specifications coming from IEEE will be 
   complete and not require any knowledge of any vendor specific 
   wireless device information. 
    
3.1.12.2 
         Compliance 
   CTP is compliant with this objective. 
    
3.1.13 
       Vendor Independence 
   This objective states that the CAPWAP protocol must not be reliant on 
   any underlying vendor implementation of hardware of either the WTP or 
   the AC. 
    
3.1.13.1 
         Protocol Evaluation 
   CTP does not assume any underlying hardware architecture of the WTPs 
   or the ACs.  In addition any dependency on MIB definitions in its 
   current form also does not assume any reliance on hardware 
   specifications. 
    
3.1.13.2 
         Compliance 
 
 
Francisco              Expires - December 2005               [Page 8] 
 Internet-Draft             CTP Evaluation                   June 2005 
 
 
   CTP is compliant with this objective. 
    
3.1.14 
       Vendor Flexibility 
   The protocol must not be bound to any specific MAC. 
    
3.1.14.1 
         Protocol Evaluation 
   CTP has been completely implemented on hardware from at least two 
   different vendors whose wireless MAC implementations are completely 
   independent.  Given this fact as well as CTPÆs inherent agnosticity 
   of wireless implementation, CTP can be implemented without knowledge 
   of underlying vendor hardware. 
    
3.1.14.2 
         Compliance 
   CTP is compliant with this objective. 
    
3.1.15 
       NAT Traversal 
   The protocol must not prevent operation across WLAN topologies which 
   include NAT segments. 
    
3.1.15.1 
         Protocol Evaluation 
   CTP provides an authentication mechanism which uses AC and WTP 
   identifiers to establish a secure connection without a dependency on 
   MAC or IP address. The CTP protocol is primarily transported as UDP 
   payload. Typical NAT implementations are IP and TCP/UDP port based. 
   Since CTP is transported above these layers, CTP will work properly 
   through NAT devices. The WTP can be statically configured to discover 
   the AC through a NAT segment. 
    
3.1.15.2 
         Compliance 
   CTP is compliant with this objective. 
    
    
3.2 
    Desirable Objectives  
 
3.2.1 
       Multiple Authentication Mechanisms 
   This objective specifies the requirement that the protocol should be 
   able to support authentication mechanisms other than IEEE 802.11i. 
    
3.2.1.1 
         Protocol Evaluation 
   Since CTP is wireless terminal agnostic, and since the PMK key 
   exchange is generic (for example, does not assume any authentication 
   mechanism in the form of an EAP type), CTP does not prevent the 
   operation of any other authentication mechanisms. 
    
   CTP logically separates the EAP-Authentication function from the Key 
   Management function. Different authentication or key management 
   frameworks can be substituted without affecting the protocol 
   behavior. 
    
 
 
Francisco              Expires - December 2005               [Page 9] 
 Internet-Draft             CTP Evaluation                   June 2005 
 
 
3.2.1.2 
         Compliance 
   CTP is compliant with this objective. 
 
3.2.2 
       Support for Future Wireless Technologies 
   This objective states that the protocol should be able to be extended 
   to future layer 2 wireless technologies and should not be limited to 
   only supporting IEEE 802.11. 
    
3.2.2.1 
         Protocol Evaluation 
   The current specification lists alternative layer 2 wireless 
   technologies that and be indicated as part of the capabilities 
   exchange phase.  The protocol is sufficiently modular in that the 
   configuration, statistics and other management functions of these 
   wireless devices can be supported.  If indeed there are layer 2 
   wireless specific elements that need to be added, those are easily 
   supported by extensions to the protocol. 
    
3.2.2.2 
         Compliance 
   CTP is compliant with this objective. 
    
3.2.3 
       Support for New IEEE Requirements 
   The protocol must be able to accommodate defined changes or 
   extensions to the IEEE 802.11 specifications. 
    
3.2.3.1 
        Protocol Evaluation 
   CTP provides an abstraction layer to accommodate any type of wireless 
   MAC technology. It provides control messages to exchange basic state 
   information between the AC and the WTP. It provides a split MAC 
   mechanism where all MAC frames can be forwarded and handled at the 
   controller. It uses SNMP-based encapsulation to provide a generic 
   mechanism for exchanging configuration and statistics data .  New 
   802.11 amendments can be easily accommodated by the protocol.  There 
   will be work required to interpret the impact of the amendment on 
   both the AC and the WTP to determine whether further message 
   definition is required. 
    
3.2.3.2 
        Compliance 
   CTP is compliant with this objective. 
 
3.2.4 
       Interconnection Objective 
   The CAPWAP protocol must not be constrained by the underlying 
   transport technologies of the wired medium. 
    
3.2.4.1 
         Protocol Evaluation 
   CTP is agnostic to the underlying transport technology as it is 
   implemented as UDP.  This was done with the assumption that the 
   transport technology can carry IP packets across its medium either L2 
   or L3 network.  In itÆs current definition CTP is transported as UDP 
   payload therefore directly abstracted from IPv4/v6 base.  
 
 
Francisco              Expires - December 2005              [Page 10] 
 Internet-Draft             CTP Evaluation                   June 2005 
 
 
    
3.2.4.2 
         Compliance 
   CTP is compliant with this objective in terms of not having specified 
   IPv6 header types. 
    
3.2.5 
       Access Control 
   This objective pertains to the ability of the protocol to exchange 
   information required for access control of WTPs and wireless 
   terminals. 
    
3.2.5.1 
         Protocol Evaluation 
   CTP provides specific messages, e.g. CTP-MU-
   Connect/Disconnect/Authenticate messages, that control the access of 
   wireless terminals.  In addition to the actual mutual authentication 
   of WTPs and ACs, the registration phase contains a AP-ID field that 
   needs to be verified by the AC.  This field needs to be checked by 
   the AC and the mechanism for this check is not within the scope of 
   any CAPWAP work.  However, the CTP protocol itself provides this 
   identification token as a means of access control of the WTP. 
    
3.2.5.2 
         Compliance 
   CTP is compliant with this objective. 
    
3.3 
    Non-objectives 
 
   The current objectives draft states this section as ôRejected 
   Objectivesö.  We have used the term ôNon-Objectivesö for this section 
   based on the discussion on the WG email list. 
    
3.3.1 
       Support for Non-CAPWAP WTPs 
   This objective states that the CAPWAP protocol should be capable of 
   recognizing legacy WTPs and existing network management systems. 
    
3.3.1.1 
         Protocol Evaluation 
   This requirement is more of a feature for centralized WLAN network 
   applications and thus does not apply to the CAPWAP problem statement. 
    
3.3.1.2 
         Compliance 
   CTP is compliant with this objective. 
    
3.3.2 
       Technical Specifications 
   This objective states that WTP vendors should not have to share 
   technical specifications for hardware and software to AC vendors in 
   order for interoperability to be achieved. 
    
3.3.2.1 
         Protocol Evaluation 
   As discussed earlier, CTP is hardware and vendor agnostic. 
    
3.3.2.2 
         Compliance 
 
 
Francisco              Expires - December 2005              [Page 11] 
 Internet-Draft             CTP Evaluation                   June 2005 
 
 
   CTP is compliant with this objective. 
 
3.4 
    Operator Requirements 
 
3.4.1 
      AP Fast Handoff 
   This objective states that the CAPWAP protocol operations must not 
   impede or obstruct the efficiency of fast handoff procedures. 
    
3.4.1.1 
         Protocol Evaluation 
   In the CTP protocol, the signaling of roaming events are efficiently 
   encoded in the CTP-MU messages.  Also, the 802.1x messaging is 
   centralized allowing efficient use of CPU resources at the AC.  In 
   effect, the mere existence of the centralized architecture ensures 
   that the efficiency of fast handoffs is improved rather than impeded. 
     
3.4.1.2 
         Compliance 
   CTP complies with this objective. 
    
4. 
  Compliance Table 
    
   Given below is a table summarizing the compliance to the objectives.  
   C = Compliant, P = Partially compliant, N = Non-compliant. 
    
   +----------------------------------------------------+------------+ 
   | Objective Type                                     | Compliance | 
   +----------------------------------------------------+------------+ 
   | Logical Groups                                     |     C      | 
   | Support for Traffic Separation                     |     C      | 
   | Wireless Terminal Transparency                     |     C      | 
   | Configuration Consistency                          |     C      | 
   | Firmware Trigger                                   |     C      | 
   | Monitoring & Exchange of System-wide Resource State|     C      | 
   | Resource Control Objective                         |     C      | 
   | CAPWAP Protocol Security                           |     P      | 
   | System-wide Security                               |     C      | 
   | IEEE 802.11i Considerations                        |     C      | 
   | Interoperability Objective                         |     C      | 
   | Protocol Specifications                            |     C      | 
   | Vendor Independence                                |     C      | 
   | Vendor Flexibility                                 |     C      | 
   | NAT Traversal                                      |     C      | 
   | Multiple Authentication Mechanisms                 |     C      | 
   | Support for Future Wireless Technologies           |     C      | 
   | Support for New IEEE Requirements                  |     C      | 
   | Interconnection Objective                          |     C      | 
   | Access Control                                     |     C      | 
   | Support for Non-CAPWAP WTPs                        |     C      | 
   | Technical Specifications                           |     C      | 
   | AP Fast Handoff                                    |     C      | 
 
 
Francisco              Expires - December 2005              [Page 12] 
 Internet-Draft             CTP Evaluation                   June 2005 
 
 
   +----------------------------------------------------+------------+ 
    
    
5. 
  Security considerations 
    
   This document provides a self evaluation of CTP in respect to the 
   CAPWAP objectives.  The CTP draft itself has a section that 
   catalogues all the pertinent security concerns.  Therefore, in this 
   draft there are no new security considerations to be discussed. 
    
6. 
  References 
    
    
                     
   [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 
      Levels", BCP 14, RFC 2119, March 1997 
    
   [2] Singh, I., et. al., ôCAPWAP Tunneling Protocolö, draft-singh-
      capwap-ctp-01.txt (work in progress), April 2005. 
    
   [3] Calhoun, P., "CAPWAP Problem Statement", draft-ietf-capwap-
      problem-statement-02.txt (work in progress), September 2004. 
    
   [4] Govindan, S., et. al., ôObjectives for Control and Provisioning 
      of Wireless Access Points (CAPWAP)ö, draft-ietf-capwap-objectives-
      02.txt (work in progress), April 2005 
    
   [5] Calhoun, et. al., ôLight Weight Access Point Protocol (LWAPP)ö, 
      draft-ohara-capwap-lwapp-02.txt (work in progress), April 2005 
    
    
7. 
  Author's Addresses 
    
   Paulo Francisco 
   Chantry Networks Inc. 
   1900 Minnesota Court 
   Mississauga, ON L5N 3C9 
   Canada 
    
   Phone: +1 905-363-6410 
   Email: paulo.francisco@siemens.com  
    
   Inderpreet Singh 
   Chantry Networks Inc. 
   1900 Minnesota Court 
   Mississauga, ON L5N 3C9 
   Canada 
    

 
 
Francisco              Expires - December 2005              [Page 13] 
 Internet-Draft             CTP Evaluation                   June 2005 
 
 
   Phone: +1 905-363-6412 
   Email: inderpreet.singh@siemens.com  
    
   Michael Montemurro 
   Chantry Networks Inc. 
   1900 Minnesota Court 
   Mississauga, ON L5N 3C9 
   Canada 
    
   Phone: +1 905-363-6413 
   Email: michael.montemurro@siemens.com  
 
Intellectual Property Statement 
 
   The IETF takes no position regarding the validity or scope of any 
   intellectual property 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; neither does it represent that it 
   has made any effort to identify any such rights. Information on the 
   IETF's procedures with respect to rights in standards-track and 
   standards-related documentation can be found in BCP-11. Copies of 
   claims of rights made available for publication 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 Secretariat. 
    
   The IETF invites any interested party to bring to its attention any 
   copyrights, patents or patent applications, or other proprietary 
   rights which may cover technology that may be required to practice 
   this standard. Please address the information to the IETF Executive   
   Director. 
    
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. 
 
 
Francisco              Expires - December 2005              [Page 14] 
 Internet-Draft             CTP Evaluation                   June 2005 
 
 
    
    
Acknowledgment 
    
   Funding for the RFC Editor function is currently provided by the 
   Internet Society. 
    
    
     








































 
 
Francisco              Expires - December 2005              [Page 15]