[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 RFC 4565

Network Working Group                                           D. Loher
Internet-Draft                                       Roving Planet, Inc.
Expires: February 2, 2006                                      D. Nelson
                                                Enterasys Networks, Inc.
                                                             O. Volinsky
                                                 Colubris Networks, Inc.
                                                             B. Sarikaya
                                                                    UNBC
                                                             August 2005


                Evaluation of Candidate CAPWAP Protocols
                       draft-ietf-capwap-eval-00

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 February 2, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document is a record of the process and findings of the
   Configuration and Provisioning of Wireless Access Points Working
   Group (CAPWAP WG) evaluation team.  The evaluation team reviewed the



Loher, et al.           Expires February 2, 2006                [Page 1]

Internet-Draft     Eval. of Candidate CAPWAP Protocols       August 2005


   four candidate protocols as they were submitted to the working group
   on the 26th of June, 2005.


Table of Contents

   1.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Conventions used in this document  . . . . . . . . . . . .  4
     1.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Process Description  . . . . . . . . . . . . . . . . . . . . .  5
     2.1.  Ratings  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Member Statements  . . . . . . . . . . . . . . . . . . . . . .  7
   4.  Protocol Proposals and Highlights  . . . . . . . . . . . . . .  9
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   6.  Mandatory Objective Compliance Evaluation  . . . . . . . . . . 12
     6.1.  Logical Groups . . . . . . . . . . . . . . . . . . . . . . 12
     6.2.  Traffic Separation . . . . . . . . . . . . . . . . . . . . 12
     6.3.  STA Transparency . . . . . . . . . . . . . . . . . . . . . 13
     6.4.  Configuration Consistency  . . . . . . . . . . . . . . . . 14
     6.5.  Firmware Trigger . . . . . . . . . . . . . . . . . . . . . 14
     6.6.  Monitor and Exchange of System-wide Resource State . . . . 16
     6.7.  Resource Control . . . . . . . . . . . . . . . . . . . . . 17
     6.8.  Protocol Security  . . . . . . . . . . . . . . . . . . . . 18
     6.9.  System-Wide  Security  . . . . . . . . . . . . . . . . . . 19
     6.10. 802.11i Considerations . . . . . . . . . . . . . . . . . . 20
     6.11. Interoperability . . . . . . . . . . . . . . . . . . . . . 21
     6.12. Protocol Specifications  . . . . . . . . . . . . . . . . . 21
     6.13. Vendor Independence  . . . . . . . . . . . . . . . . . . . 22
     6.14. Vendor Flexibility . . . . . . . . . . . . . . . . . . . . 22
     6.15. NAT Traversal  . . . . . . . . . . . . . . . . . . . . . . 23
   7.  Desirable Objective Compliance Evaluation  . . . . . . . . . . 24
     7.1.  Multiple Authentication  . . . . . . . . . . . . . . . . . 24
     7.2.  Future Wireless Technologies . . . . . . . . . . . . . . . 24
     7.3.  New IEEE Requirements  . . . . . . . . . . . . . . . . . . 25
     7.4.  Interconnection (IPv6) . . . . . . . . . . . . . . . . . . 25
     7.5.  Access Control . . . . . . . . . . . . . . . . . . . . . . 26
   8.  Evaluation Summary and Conclusions . . . . . . . . . . . . . . 27
   9.  Protocol Recommendation  . . . . . . . . . . . . . . . . . . . 28
     9.1.  High priority recommendations relevant to mandatory
           objectives . . . . . . . . . . . . . . . . . . . . . . . . 28
       9.1.1.  Information Elements . . . . . . . . . . . . . . . . . 28
       9.1.2.  Control Channel Security . . . . . . . . . . . . . . . 28
       9.1.3.  Data Tunneling Modes . . . . . . . . . . . . . . . . . 29
     9.2.  Additional Recommendations Relevant to Desirable
           Objectives . . . . . . . . . . . . . . . . . . . . . . . . 31
       9.2.1.  Access Control . . . . . . . . . . . . . . . . . . . . 31
       9.2.2.  Removal of Layer 2 Encapsulation for Data Tunneling  . 31
       9.2.3.  Data Encapsulation Standard  . . . . . . . . . . . . . 31



Loher, et al.           Expires February 2, 2006                [Page 2]

Internet-Draft     Eval. of Candidate CAPWAP Protocols       August 2005


   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
   Intellectual Property and Copyright Statements . . . . . . . . . . 34
















































Loher, et al.           Expires February 2, 2006                [Page 3]

Internet-Draft     Eval. of Candidate CAPWAP Protocols       August 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 [RFC2119].

1.2.  Terminology

   This document follows the terminology defined in [ARCH] (a work in
   progress), and [OBJ] (also a work in progress).







































Loher, et al.           Expires February 2, 2006                [Page 4]

Internet-Draft     Eval. of Candidate CAPWAP Protocols       August 2005


2.  Process Description

   The process to be described here has been adopted from a previous
   evaluation in IETF [RFC3127].  The CAPWAP objectives draft [OBJ] was
   used to set the scope and direction for the evaluators and was the
   primary source of requirements.  However, the evaluation team also
   used their expert knowledge and professional experience to consider
   how well a candidate protocol met the working group objectives.

   For each of the four candidate protocols, the evaluation draft editor
   assigned two team members to write evaluation briefs.  One member was
   assigned to write a 'Pro' brief and could take a generous
   interpretation of the proposal; this evaluator could grant benefit of
   doubt.  A second evaluator was assigned to write a 'Con' brief and
   was required to use strict criteria when performing the evaluation.

2.1.  Ratings

   The "Pro and "Con" members independently evaluated how well the
   candidate protocol met each objective.  Each objective was scored as
   an 'F' for failure , 'P' for partial or 'C' for completely meeting
   the objective.

   F - Failure to Comply

   The evaluation team believes the proposal does not meet the
   objective.  This could be due to the proposal completely missing any
   functionality towards the objective.  A proposal could also receive
   an 'F' for improperly implementing the objective.

   P - Partial Compliance

   The proposal has some functionality that addresses the objective, but
   it is incomplete or ambiguous.

   C - Compliant

   The proposal fully specifies functionality meeting the objective.
   The specification must be detailed enough that interoperable
   implementations are likely from reading the proposal alone.  If the
   method is ambiguous or particularly complex, an explanation, use
   cases or even diagrams may need to be supplied in order to receive a
   compliant rating.

   The four person evaluation team held a teleconference for each
   candidate to discuss the briefs.  One of the working group chairs was
   also present at the meeting in an advisory capacity.  Each evaluator
   presented their brief with supporting details.  The team discussed



Loher, et al.           Expires February 2, 2006                [Page 5]

Internet-Draft     Eval. of Candidate CAPWAP Protocols       August 2005


   the issues and delivered a team rating for each objective.  These
   discussions are documented in the meeting minutes.  The team ratings
   are used for the compliance evaluation.

   The candidate protocols were scored only on the information written
   in their draft.  This means that a particular protocol might actually
   meet the specifics of a requirement, but if the proposal did not
   state, describe or reference how that requirement was met, it might
   be scored lower.










































Loher, et al.           Expires February 2, 2006                [Page 6]

Internet-Draft     Eval. of Candidate CAPWAP Protocols       August 2005


3.  Member Statements

   Darren Loher, Roving Planet

   I am employed as the senior architect at Roving Planet which writes
   network and security management software for wireless networks.  I
   have over 11 years of commercial experience designing and operating
   networks.  I have implemented and operated networks and network
   management systems for a university, large enterprises and a major
   Internet service provider for over 4 years.  I also have software
   development experience and have written web based network and systems
   management tools including a system for managing a very large
   distributed DNS system.  I have witnessed the IETF standards process
   for several years, my first event being IETF 28.  I have rarely
   directly participated in any working group activities before this
   point.  To my knowledge, my company has no direct relationship with
   any companies that have authored the CAPWAP protocol submissions.

   David Nelson, Enterasys

   I am currently co-chair of the RADEXT WG, AAA Doctor in O&M Area, and
   employed in the core router engineering group of my company.  I have
   previously served on a protocol evaluation team in the AAA WG, and am
   a co-author of RFC 3127 [RFC3127].  I was an active contributor in
   the IEEE 802.11i task group, and previously employed in the WLAN
   engineering group of my company.  I have had no participation in any
   of the submitted protocols.  My company does have an OEM relationship
   with at least one company whose employees have co-authored one of the
   submissions, but I have no direct involvement with our WLAN product
   at this time.

   Oleg Volinsky, Colubris Networks

   I am a member of the Enterprise group of Colubris Networks, a WLAN
   vendor.  I have over 10 years of experience in design and development
   of network products from core routers to home networking equipment.
   Over years I have participated in various IETF groups.  I have been a
   member of CAPWAP WG for over a year.  In my current position I have
   been monitoring the developments of CAPWAP standards and potential
   integration of the resulting protocol into the company's products.  I
   have not participated in any of the candidate protocol drafts.  I
   have not worked for any of the companies whose staff authored any of
   the candidate protocols.

   Behcet Sarikaya, University of Northern British Columbia

   I am currently Professor of Computer Science at UNBC.  I have so far
   five years of experience in IETF as a member of mobile networking



Loher, et al.           Expires February 2, 2006                [Page 7]

Internet-Draft     Eval. of Candidate CAPWAP Protocols       August 2005


   related working groups.  I have made numerous I-D contributions and
   am a coauthor of one RFC.  I have submitted an evaluation draft (with
   Andy Lee) that evaluated LWAPP, CTP and WiCoP.  Also I submitted
   another draft (on CAPWAPHP) that used LWAPP, CTP, WiCoP and SLAPP as
   transport.  I also have research interests on next generation access
   point/controller architectures.  I have no involvement in any of the
   candidate protocol drafts, have not contributed any of the drafts.  I
   have not worked in any of the companies whose staff has produced any
   of the candidate protocols.










































Loher, et al.           Expires February 2, 2006                [Page 8]

Internet-Draft     Eval. of Candidate CAPWAP Protocols       August 2005


4.  Protocol Proposals and Highlights

   The following proposals were submitted as proposals to the CAPWAP
   working group.

   [LWAPP] "Light Weight Access Point Protocol", Work in progress.

   LWAPP was the first CAPWAP protocol orginally submitted to Seamoby
   Working Group.  LWAPP proposes original solutions for authentication,
   user data encapsulation as well as management and configuration
   information elements.  LWAPP originated as a "Split MAC" protocol but
   recent changes have added local MAC support as well.  LWAPP has
   received a security review from Charles Clancy of the University of
   Maryland Information Systems Security Lab.

   LWAPP is the most detailed CAPWAP proposal.  It provides a thorough
   specification of the discovery, security and system management
   methods.  LWAPP focuses on the 802.11 WLAN specific monitoring and
   configuration.  A key feature of LWAPP is it's use of raw 802.11
   frames which are tunneled back to the AC for processing.  In both
   Local and Split MAC mode, raw 802.11 frames are forwarded to the AC
   for management and control.  In addition, in split-MAC mode, user
   data is tunneled in raw 802.11 form to the AC.  Although in concept,
   LWAPP could be used for other wireless technologies, LWAPP defines
   very few primitives that are independant of the 802.11 layer.

   [SLAPP]"Secure Light Access Point Protocol", Work in progress.

   SLAPP distinguishes itself with the use of well known, established
   technologies such as GRE for user data tunneling between AC and WTP
   and the proposed standard DTLS for the control channel transport.

   Four modes of operation are supported, 2 local MAC modes and 2 split
   MAC modes.  STA control may be performed by the AC using native
   802.11 frames which are encapsulated in SLAPP control packets across
   all modes.

   In SLAPP local MAC modes, user data frames may be bridged or tunneled
   back using GRE to the AC as 802.3 frames.  In the split-MAC modes,
   user data is always tunneled back to the AC as native 802.11 frames.
   Encryption of user data may be performed at either the AC or the WTP
   in split-MAC mode.

   [CTP]"CAPWAP Tunneling Protocol", Work in progress.

   CTP distinguishes itself with its use of SNMP to define configuration
   and management data which it then encapsulates in an encrypted
   control channel.  CTP was originally designed as a local MAC protocol



Loher, et al.           Expires February 2, 2006                [Page 9]

Internet-Draft     Eval. of Candidate CAPWAP Protocols       August 2005


   but the new version has split MAC support as well.  In addition, CTP
   is clearly designed from the beginning to be compatible with multiple
   wireless technologies.

   CTP defines information elements for management and control between
   the AC and WTP.  CTP control messages are specified for STA session
   state, configuration and statistics.

   In local MAC mode, CTP does not forward any native wireless frames to
   the AC.  CTP specifies control messages for STA session activity,
   mobilitiy and RF resource management between the AC and WTP.  CTP
   local MAC mode specifies that the integration function from the
   wireless network to 802.3 Ethernet is performed at the WTP for all
   user data.  User data may either be bridged at the WTP or
   encapsulated as 802.3 frames in CTP packets at the WTP and tunneled
   to the AC.

   CTP's Split-MAC mode is defined as an extension to local-MAC mode.
   In CTP's version of split-MAC operation, wireless management frames
   are forwarded in their raw format to the AC.  User data frames may be
   bridged locally at the WTP, or they may be encapsulated in CTP
   packets and tunneled in their native wireless form to the AC.

   CTP supplies STA control abstraction, methods for extending the
   forwarding of multiple types of native wireless management frames and
   many options for user data tunneling.  Configuration management is an
   extension of SNMP.  This makes CTP one of the most flexible of the
   proposed CAPWAP protocols.  However, it does define new security and
   data tunneling mechanisms instead of leveraging existing standards.

   [WICOP]"Wireless LAN Control Protocol", Work in progress.

   The WiCoP protocol introduces new discovery, configuration and
   management of WLAN systems.  The protocol defines a distinct
   discovery mechanism that integrates WTP-AC capabilities negotiation.

   WiCoP defines 802.11 QoS parameters.  In addition, the protocol
   proposes to use standard security and authentication methods such as
   IPSec and EAP.  The protocol needs to go into detail with regards to
   explicit use of the above mentioned methods.  To assure interoperable
   protocol implementations, it is critical to provide user with
   detailed unambiguous specification.









Loher, et al.           Expires February 2, 2006               [Page 10]

Internet-Draft     Eval. of Candidate CAPWAP Protocols       August 2005


5.  Security Considerations

   Each of the candidate protocols has a Security Considerations
   section, as well as security properties.  The CAPWAP Objectives
   document contains security related requirements.  The evaluation team
   has considered if and how the candidate candidate protocols implement
   the security features required by the CAPWAP objectives.  However,
   this evaluation team is not a security team and has not performed a
   thorough security evaluation or tests.  Any protocol coming out of
   the CAPWAP working group must undergo a IETF security review in order
   to fully meet the objectives.








































Loher, et al.           Expires February 2, 2006               [Page 11]

Internet-Draft     Eval. of Candidate CAPWAP Protocols       August 2005


6.  Mandatory Objective Compliance Evaluation

6.1.  Logical Groups

   LWAPP:C, SLAPP:C, CTP:C, WiCoP:C

   LWAPP

   LWAPP provides a control message called "Add WLAN".  This message is
   used by AC to create a WLAN with a unique ID, i.e. its SSID.  The
   WTPs in this WLAN have their own BSSIDs.  LWAPP meets this objective.

   SLAPP

   SLAPP explicitly supports 0-255 BSSID's.

   CTP

   CTP implements a NETWORK_ID attribute which allows a wireless
   technology independant way of creating logical groups.  CTP meets
   this objective.

   WiCoP

   WiCoP provides control tunnels to manage logical groups.  There is
   one control tunnel for each logical group.  WiCoP meets this
   objective.

6.2.  Traffic Separation

   LWAPP:C, SLAPP:C, CTP:P, WiCoP:P

   If a protocol distinguishes a data message from a control message,
   then it meets this objective.

   LWAPP

   LWAPP separates control messages from data messages using "C-bit".
   "C-bit" is defined in the LWAPP transport header.  When C bit is
   equal to zero, the message is a data message.  When C bit is equal to
   one, message is a control message.  So, LWAPP meets this objective

   SLAPP

   The SLAPP protocol encapsulates control using DTLS and optionally,
   user data with GRE.  Of particular note, SLAPP defines 4
   "architecture modes" which define how user data is handled in
   relation to the AC.  SLAPP is compliant with this objective.



Loher, et al.           Expires February 2, 2006               [Page 12]

Internet-Draft     Eval. of Candidate CAPWAP Protocols       August 2005


   CTP

   CTP defines separate packet frame types for control and data.
   However, the evaluation team could not find a way to configure the
   tunneling of user data, so opted to rate CTP as only partially
   compliant.  It appears that CTP would rely on SNMP MIB OID's for this
   function, but none were defined in the specification.  Defining the
   necessary OID's would make CTP fully compliant.

   WiCoP

   WiCoP provides for separation between control and data channels.
   However, tunneling methods are not explicitly described.  Because of
   this, WiCoP partially meets this objective.

6.3.  STA Transparency

   LWAPP:C, SLAPP:C, CTP:C, WiCoP:C

   If a protocol does not indicate that STA needs to know about the
   protocol, then this objective is met.

   The protocol must not define any message formats between STA and
   WTP/AC.

   LWAPP

   LWAPP does not require a STA to be aware of LWAPP.  No messages or
   protocol primitives are defined that the STA must interact with
   beyond the 802.11 standard.  LWAPP is fully compliant.

   SLAPP

   SLAPP places no requirements on STA network elements.  No messages or
   protocol primitives are defined that the STA must interact with
   beyond the 802.11 standard.

   CTP

   CTP does not require a terminal to know CTP.  So, CTP meets this
   objective.

   WiCoP

   WiCoP does not require a terminal to know WiCoP.  So, WiCoP meets
   this objective.





Loher, et al.           Expires February 2, 2006               [Page 13]

Internet-Draft     Eval. of Candidate CAPWAP Protocols       August 2005


6.4.  Configuration Consistency

   LWAPP:C, SLAPP:C, CTP:C, WiCoP:C

   Given the objective of maintaining configurations for a large number
   of network elements involved in 802.11 wireless networks the
   evaluation team would like to recommend that a token, key or serial
   number for configuration be implemented for configuration
   verification.

   LWAPP

   It is possible to obtain and verify all configurable values through
   LWAPP.  Notably, LWAPP takes an approach that only "non-default"
   settings (defaults are specified by LWAPP) are necessary for
   transmission when performing configuration consistency checks.  This
   behavior is explicitly specified in LWAPP.  LWAPP is compliant with
   this objective.

   SLAPP

   Numerous event and statistics are available to report config changes
   and WTP state.  SLAPP does not have any built in abilities to
   minimize or optimize configuration consistency verification, but it
   is compliant with the objective.

   CTP

   CTP's use of SNMP makes configuration consistency checking
   straightfoward.  Where specified in an a MIB, one could take
   advantage of default values.

   WICOP

   The WiCoP configuration starts with exchange of capability messages
   between WTP and AC.  Next, configuration control data is sent to WTP.

   WiCoP defines configuration values in groups of configuration data
   messages.  In addition, the protocol supports configuration using MIB
   objects.  To maintain data consistency each configuration message
   from AC is acknowledged by WTP.

6.5.  Firmware Trigger

   LWAPP:P, SLAPP:P, CTP:P, WiCoP:C

   The evaluation team considered the objective and determined that for
   full compliance, the protocol state machine must support the ability



Loher, et al.           Expires February 2, 2006               [Page 14]

Internet-Draft     Eval. of Candidate CAPWAP Protocols       August 2005


   to initiate the process for checking and performing a firmware update
   independantly of other functions.

   Many protocols perform a firmware check and update procedure only on
   system startup time.  This method received a partial compliance.  The
   team believed that performing the firmware check only at startup time
   was unnecessarily limiting and that allowing it to occur at any time
   in the state machine did not increase complexity of the protocol.
   Allowing the firmware update process to be initiated occur during the
   running state allows more possibilities for minimizing downtime of
   the WTP during the firmware update process.

   For example, the firmware check and download of the image over the
   network could potentially occur while the WTP was in a running state.
   After the file transfer was complete, the WTP could be rebooted just
   once and being running the new firmware image.  This could pose a
   meaningful reduction in downtime when the firmware image is large,
   the link for loading the file is very slow or the WTP reboot time is
   long.

   A protocol would only fail compliance if it no method was specified
   for updating of firmware.

   LWAPP

   Firmware download is initiated by the WTP only at the Join phase
   (when a WTP is first associating with an AC) and not at any other
   time.  The firmware check and update could be "triggered" indirectly
   by the AC by sending a reset message to the WTP.  The resulting
   reboot would cause a firmware check and update to be performed.
   LWAPP is partially compliant because its firmware trigger can only be
   used in the startup phases of the state machine.

   SLAPP

   SLAP{ includes a firmware check and update procedure which is
   performed when a WTP is first connecting to an AC.  The firmware
   check and update can only be "triggered" indirectly by the AC by
   sending a reset message to the WTP.  SLAPP is partially compliant
   because its firmware trigger can only be used in the startup phases
   of the state machine.

   CTP

   The CTP state machine specifies that the firmware upgrade procedure
   must be performed immediately after the authentication exchange as
   defined in section 6.2 of [CTP].  However, section 5.2.5 of [CTP]
   states that the SW-Update-Req message MAY be sent by the AC.  This



Loher, et al.           Expires February 2, 2006               [Page 15]

Internet-Draft     Eval. of Candidate CAPWAP Protocols       August 2005


   indirectly implies that CTP could support an AC triggered software
   update during the regular running state of the WTP.  So it seems that
   CTP might be fully compliant, but the proposal should be clarified
   for full compliance.

   WiCoP

   In WiCoP, firmware update may be triggered any time in the active
   state, so WiCoP is fully compliant.

6.6.  Monitor and Exchange of System-wide Resource State

   LWAPP:C, SLAPP:C, CTP:P, WiCoP:C

   The evaluation team focused on the protocols supplying three methods
   relevant to statistics from WTP's; The ability to transport
   statistics, a minimum set of standard data and the ability to extend
   what data could be reported or collected.

   LWAPP

   Statistics are sent by WTP using "Event Request" message.  LWAPP
   defines an 802.11 statistics message which covers 802.11 MAC layer
   properties.  LWAPP is compliant

   SLAPP

   WLAN statisitics transport is supplied via the control channel and
   encoded in SLAPP defined TLV's called information elements. 802.11
   configuration and statistics information elements are supplied in
   [SLAPP] 6.1.3.1.  These are extendable and include vendor specific
   extensions.

   CTP

   CTP defines a control message called "CTP Stats-Notify".  This
   control message contains statistics in the form of SNMP OID's and is
   sent from the WTP to AC.  This approach is novel because it leverages
   the use of standard SNMP.

   [CTP] 5.3.10 reccommends the use of 802.11 MIBs where applicable.
   However, the proposal acknowledges that additional configuration and
   statistics information is required, but does not specify these MIB
   extensions.  CTP needs to add these extensions to the proposal.
   Also, this minimum set of statistics and configuration OID's must
   become requirements in order to fully meet the objective.

   WiCoP



Loher, et al.           Expires February 2, 2006               [Page 16]

Internet-Draft     Eval. of Candidate CAPWAP Protocols       August 2005


   The feedback control message sent by WTP contains many statistics.
   WiCoP specifies fifteen statistics WTP needs to send to AC.  New
   versions of WiCoP can address any new statistics AC needs to monitor
   WTP.  WiCoP meets this objective.

6.7.  Resource Control

   LWAPP:C, SLAPP:P, CTP:P, WiCoP:P

   The evaluation team interpreted the resource control objective to
   mean that the CAPWAP protocol must map 802.11e QoS markings to the
   wired network.  This mapping must include any encapsulation or
   tunneling of user data defined by the CAPWAP protocol.  Of particular
   note, the evaluation team agreed that the CAPWAP protocol should
   supply an explicit capability to configure this mapping.  Since most
   of the protocols relied only on the 802.11e statically defined
   mapping, most received a partial compliance.

   LWAPP

   LWAPP defines it's own custom TLV structure which consists of an 8
   bit type or class of information value and an additional 8 bit value
   which indexes to a specific variable

   LWAPP allows the mobile station based QoS configuration in each Add
   Mobile Request sent by AC to WTP for each new mobile station that is
   attached.  Packet prioritization is left to individual WTPs. 4
   different QoS policies for each station to enforce can be configured.
   Update Mobile QoS message element can be used to change QoS policy at
   the WTP for a given mobile station.  LWAPP should support 8 QoS
   policies as this matches 802.11e 802.1p and IP TOS, but for this
   objective, 4 classes is compliant.

   Overall, LWAPP conforms to the resource control objective.  It
   enables QoS configuration and mapping.  The control can be applied on
   a logical group basis and also enables the wireless traffic to be
   flexibly mapped to the wired segment.

   SLAPP

   Although 802.11e specifies 802.1p and DSCP mappings, there is no
   explicit support for 802.11e in SLAPP.  SLAPP must be updated to add
   802.11e as one of the standard capabilities that a WTP could support
   and specify a mechanism which would allow configuration of mapping
   the QoS classes.

   CTP




Loher, et al.           Expires February 2, 2006               [Page 17]

Internet-Draft     Eval. of Candidate CAPWAP Protocols       August 2005


   CTP requires that the WTP and AC copy the QoS marking of user data to
   the data message encapsulation.  This mapping is accomplished by the
   CTP Header's 1 byte policy field.  However, no configuration of QoS
   mapping other than copying the user data's already existing markings
   is defined in CTP.  It seems clear that SNMP could be used to
   configure the mapping to occur differently, but no OID's are defined
   which would enable this.  Partial compliance is assigned to CTP for
   this objective.

   WiCoP

   Note: WiCoP rating for Resource Control objective has been upgraded
   from FAILED to PARTIAL.  After an additional review of the WiCoP
   protocol proposal, it was determined that the protocol partially
   meats Resource control objectives.

   WiCoP protocol starts its QoS configuration with 802.11e capability
   exchange between WTP and AC.  The QoS capabilities primitives are
   included in the capability messages.

   WiCoP defines the QoS-Value message which contains 802.11e
   configuration parameters.  This is sent for each group supported by
   WTP.  WiCoP does not provide an explicit method for configuration of
   DSCP tags and 802.1P precedence values.  It is possible to configure
   these parameters through SNMP OID configuration method, but WiCoP
   does not explicitly identify any specific MIBs.  Overall, WiCoP
   partially meets resource control CAPWAP objects.  In order to be
   fully compliant with the given objective, the protocol needs to
   identify a clear method to configure 802.1p and DSCP mappings.

6.8.  Protocol Security

   LWAPP:C, SLAPP:C, CTP:F, WiCoP:F

   For the purposes of the protocol security objective, the evaluation
   team primarily considered whether or not the candidate protocols
   implement the security features required by the CAPWAP objectives.
   Please refer to the security considerations section of this document.

   LWAPP

   It appears that the security mechanisms, including the key management
   portions in LWAPP are correct.  One third party security review has
   been performed.  However, further security review is warranted since
   a CAPWAP specific key exchange mechanism is defined.  LWAPP is
   compliant with the objective

   SLAPP



Loher, et al.           Expires February 2, 2006               [Page 18]

Internet-Draft     Eval. of Candidate CAPWAP Protocols       August 2005


   The SLAPP protocol implements authentication of the WTP by the AC
   using the DTLS protocol.  This behavior is defined in both the
   discovery process and the 802.11 control process.  SLAPP allows
   mutual and asymmetric authentication.  SLAPP also gives informative
   examples of how to properly use the authentication.  SLAPP should add
   another informative example for authentication of the AC by the WTP.
   SLAPP is compliant with the objective.

   CTP

   The original presentation at IETF63 of the preliminary findings of
   the evaluation team reported that CTP failed this objective.  This
   was on the basis of asymmetric authentication not being supported by
   CTP.  This was due to a misunderstanding of what was meant by
   asymmetric authentication by the evaluation team.  The definitions of
   the terminology used in [OBJ] were clarified on the CAPWAP mailing
   list.  CTP in fact does implement a form of asymmetric authentication
   through the use of public keys.

   However, CTP still fails to comply with the objective for two
   reasons:

   First, CTP does not mutually derive session keys.  Second, CTP does
   not perform explicit mutual authentication because the two parties
   authenticating do not confirm the keys.

   WiCoP

   There is not enough specific information to implement WiCOP protocol
   security features.  While in concept EAP and IPSec make sense, there
   is no explicit description on how these methods would be used.

6.9.  System-Wide  Security

   LWAPP:C, SLAPP:C, CTP:F, WiCoP:F

   LWAPP

   LWAPP wraps all control and management communication in it's
   authenticated and encrypted control channel.  LWAPP does not seem
   particularly vulnerable to DoS.  LWAPP should make a recommendation
   that the join method be throttled to reduce the impact of DOS attacks
   against it.  Use of an established security mechanism such as IPSec
   would be preferred.  However, LWAPP's independant security review
   lended enough confidence to declare LWAPP compliant with the
   objective.

   SLAPP



Loher, et al.           Expires February 2, 2006               [Page 19]

Internet-Draft     Eval. of Candidate CAPWAP Protocols       August 2005


   SLAPP is compliant due to wrapping all control and management
   communication in DTLS.  SLAPP also recommends measures to protect
   against discovery request DOS attacks.  DTLS has undergone security
   review and has at least one known implementation outside of SLAPP.
   At the time of this writing, DTLS is pending proposed standard status
   in the IETF.

   CTP

   CTP introduces a new, unestablished mechanism for AC to WTP
   authentication.  For complete compliance, use of an established
   security mechanism with detailed specifications for it's use in CTP
   is preferred.  Alternatively a detailed security review could be
   performed.  CTP does not point out or recommend or specify any DoS
   attack mitigation requirements against Reg-Req and Auth-Req floods,
   such as a rate limiter.  Because CTP received an 'F' on it's protocol
   security objective, it follows that system-wide security must also be
   rated 'F'.

   WiCoP

   WiCop does not address DoS attack threats.  Also, as with the
   protocol security objective, the protocol needs to explicitly
   describe its tunnel and authentication methods.

6.10.  802.11i Considerations

   LWAPP:C, SLAPP:C, CTP:F, WiCoP:P

   LWAPP

   LWAPP explicitly defines mechanisms for handling 802.11i in it's
   modes with encryption terminated at the WTP.  In order to accomplish
   this, the AC sends the PTK using the encrypted control channel to the
   WTP using the Add Mobile message.  When encryption is terminated at
   the AC, there are no special requirements.  LWAPP is compliant.

   SLAPP

   SLAPP defines a control message to send the PTK and GTK to the WTP
   when the WTP is the encryption endpoint.  This control message is
   carried on the DTLS protected control channel.  SLAPP is compliant.

   CTP

   CTP lacks a specification for a control message to send 802.11i PTK
   and GTK keys to a WTP when the WTP is an encryption endpoint.  Based
   on this, CTP fails compliance for this objective.  This requirement



Loher, et al.           Expires February 2, 2006               [Page 20]

Internet-Draft     Eval. of Candidate CAPWAP Protocols       August 2005


   could be addressed either by defining new control channel information
   elements or by simply defining SNMP OID's.  The transport of these
   OID's would be contained in the secure control channel and therefore
   protected.

   WiCoP

   WiCoP lacks documentation in the draft on how to handle 4 way
   handshake.  The case for encryption at the AC needs clarification.

6.11.  Interoperability

   LWAPP:C, SLAPP:C, CTP:C, WiCoP:C

   LWAPP

   LWAPP supports both split and local mac architectures and is
   therefore compliant to the letter of the objectives.  LWAPP is
   particularly rich in its support of the split-mac architecture.
   However, LWAPP's support of Local-MAC is somewhat limited and could
   be expanded.  LWAPP is lacking a mode which allows Local MAC data
   frames to be tunneled back to the AC.  A discussion of possible
   extensions and issues is discussed in the recommendations section of
   this evaluation.

   SLAPP

   SLAPP is compliant.

   CTP

   CTP is compliant.

   WiCoP

   WiCoP is compliant.

6.12.  Protocol Specifications

   LWAPP:C, SLAPP:P, CTP:P, WiCoP:P

   LWAPP

   LWAPP is nearly fully documented.  Only a few sections are noted as
   incomplete.  Detailed descriptions are often given to explain the
   purpose of the protocol primitives defined which should encourage
   interoperable implementations.




Loher, et al.           Expires February 2, 2006               [Page 21]

Internet-Draft     Eval. of Candidate CAPWAP Protocols       August 2005


   SLAPP

   SLAPP is largely implementable from it's specification.  It contains
   enough information to perform an interoperable implementation for
   it's basic elements, however additional informative references or
   examples should be provided covering use of information elements,
   configuring multiple logical groups, etc.

   CTP

   As noted earlier, there are a few areas where CTP lacks a complete
   specification, primarily due to the lack of specific MIB definitions.

   WiCoP

   Due to the lack of specific tunnel specifications and authentication
   specifications, WiCoP is only partially compliant.

6.13.  Vendor Independence

   LWAPP:C, SLAPP:C, CTP:C, WiCoP:C

   LWAPP

   LWAPP is compliant.

   SLAPP

   SLAPP is compliant.

   CTP

   CTP is compliant.

   WiCoP

   WiCoP is compliant.

6.14.  Vendor Flexibility

   LWAPP:C, SLAPP:C, CTP:C, WiCoP:C

   LWAPP

   LWAPP is compliant.

   SLAPP




Loher, et al.           Expires February 2, 2006               [Page 22]

Internet-Draft     Eval. of Candidate CAPWAP Protocols       August 2005


   SLAPP is compliant.

   CTP

   CTP is compliant.

   WiCoP

   WiCoP is compliant.

6.15.  NAT Traversal

   LWAPP:C, SLAPP:C, CTP:C, WiCoP:C

   LWAPP

   LWAPP may require special considerations due to it carrying the IP
   address of the AC and data termination points in the payload of
   encrypted control messages.  To overcome NAT, static NAT mappings may
   need to be created at the NAT'ing device if the AC or data
   termination points addresses are translated from the point of view of
   the WTP.  A WTP should be able function in the hidden address space
   of a NAT'd network.

   SLAPP

   SLAPP places no out of the ordinary constraints regarding NAT.  A WTP
   could function in the hidden address space of a NAT'd network without
   any special configuration.

   CTP

   CTP places no out of the ordinary constraints regarding NAT.  A WTP
   could function in the hidden address space of a NAT'd network without
   any special configuration.

   WiCoP

   WiCoP places no out of the ordinary constraints regarding NAT.  A WTP
   could function in the hidden address space of a NAT'd network without
   any special configuration.










Loher, et al.           Expires February 2, 2006               [Page 23]

Internet-Draft     Eval. of Candidate CAPWAP Protocols       August 2005


7.  Desirable Objective Compliance Evaluation

7.1.  Multiple Authentication

   LWAPP:C, SLAPP:C, CTP:C, WiCoP:C

   LWAPP

   LWAPP allows for multiple STA authentication mechanisms.

   SLAPP

   SLAPP does not constrain other authentication techniques for being
   deployed.

   CTP

   CTP supports multiple STA authentication mechanisms.

   WiCoP

   WiCoP allows for multiple STA authentication mechanisms.

7.2.  Future Wireless Technologies

   LWAPP:C, SLAPP:C, CTP:C, WiCoP:C

   LWAPP

   LWAPP could be used for other wireless technologies.  However, LWAPP
   defines very few primitives that are independant of the 802.11 layer.

   SLAPP

   SLAPP could be used for other wireless technologies.  However, SLAPP
   defines very few primitives that are independant of the 802.11 layer.

   CTP

   CTP supplies STA control abstraction, methods for extending the
   forwarding of multiple types of native wireless management frames and
   many options for user data tunneling.  Configuration management is an
   extension of SNMP, for which new MIB's could in concept, be easily
   plugged in.  This helps makes CTP a particularly flexible proposal
   for supporting future wireless technologies.  In addition, CTP has
   already defined multiple wireless protocol types in addition to
   802.11.




Loher, et al.           Expires February 2, 2006               [Page 24]

Internet-Draft     Eval. of Candidate CAPWAP Protocols       August 2005


   WiCoP

   WiCoP could be used for other wireless technologies.

7.3.  New IEEE Requirements

   LWAPP:C, SLAPP:C, CTP:C, WiCoP:C

   LWAPP

   LWAPP's extensive use of native 802.11 frame forwarding allows it to
   be transparent to many 802.11 changes.  It however shifts the burden
   of adapting MAC layer changes to the packet processing capabilities
   of the AC.

   SLAPP

   SLAPP's use of native 802.11 frames for control and management allow
   SLAPP a measure of transparency to changes in 802.11.  Because SLAPP
   also supports a mode which tunnels user data as 802.3 frames, it has
   additonal architectural options for adapting to changes on the
   wireless infrastructure.

   CTP

   CTP has perhaps the greatest ability to adapt to changes in IEEE
   requirements.  Architecturally speaking, CTP has several options
   available for adapting to change.  SNMP OID's are easily extended for
   additional control and management functions.  Native wireless frames
   can be forwarded directly to the AC if necessary.  Wireless frames
   can be bridged to 802.3 frames and tunneled back to the AC to protect
   the AC from changes at the wireless MAC layer.  These options allow
   many possible ways to adapt to change of the wireless MAC layer.

   WiCoP

   Because WiCoP uses 802.11 frames for the data transport, it is
   transparent to most IEEE changes.  Any new IEEE requirements may need
   new configuration and new capability messages between WTP and AC.
   The AC would need to be modified to handle new 802.11 control and
   management frames.

7.4.  Interconnection (IPv6)

   LWAPP:C, SLAPP:C, CTP:C, WiCoP:C

   LWAPP




Loher, et al.           Expires February 2, 2006               [Page 25]

Internet-Draft     Eval. of Candidate CAPWAP Protocols       August 2005


   LWAPP explicitly defines measures for accomodating IPv6.  LWAPP is
   more sensitive to this in part because it carries IP addresses in two
   control messages.

   SLAPP

   SLAPP is transparent to the interconnection layer.  DTLS and GRE will
   both operate over IPv6.

   CTP

   CTP is transparent to the interconnection layer.  CTP should be able
   to operate over IPv6 without any changes.

   WiCoP

   WiCoP is transparent to the interconnection layer and should be able
   to operate over IPv6 without changes.

7.5.  Access Control

   LWAPP:C, SLAPP:C, CTP:C, WiCoP:C

   LWAPP

   LWAPP uses native 802.11 management frames forwarded to the AC for
   the purpose of performing STA access control.  WTP's are
   authenticated in LWAPP's control protocol Join phase.

   SLAPP

   SLAPP has support for multiple authentication methods for WTP's.  In
   addition, SLAPP can control STA access via 802.11 management frames
   forwarded to the AC or via SLAPP's information element primitives.

   CTP

   CTP specifies STA access control primitives.

   WiCoP

   WiCoP specifies access control in [WICOP] section 5.2.2.









Loher, et al.           Expires February 2, 2006               [Page 26]

Internet-Draft     Eval. of Candidate CAPWAP Protocols       August 2005


8.  Evaluation Summary and Conclusions

   See Figure 1.

    ---------------------------------------------------------------
   | CAPWAP Evaluation              | LWAPP | SLAPP | CTP | WiCoP  |
    ---------------------------------------------------------------|
   | 5.1.1  Logical Groups          |    C  |   C   |  C  |   C    |
   | 5.1.2  Traffic Separation      |    C  |   C   |  P  |   P    |
   | 5.1.3  STA Transparency        |    C  |   C   |  C  |   C    |
   | 5.1.4  Config Consistency      |    C  |   C   |  C  |   C    |
   | 5.1.5  Firmware Trigger        |    P  |   P   |  P  |   C    |
   | 5.1.6  Monitor System          |    C  |   C   |  P  |   C    |
   | 5.1.7  Resource Control        |    C  |   P   |  P  |   P    |
   | 5.1.8  Protocol Security       |    C  |   C   |  F  |   F    |
   | 5.1.9  System Security         |    C  |   C   |  F  |   F    |
   | 5.1.10 802.11i Consideration   |    C  |   C   |  F  |   P    |
   |---------------------------------------------------------------|
   | 5.1.11 Interoperability        |    C  |   C   |  C  |   C    |
   | 5.1.12 Protocol Specifications |    C  |   P   |  P  |   P    |
   | 5.1.13 Vendor Independence     |    C  |   C   |  C  |   C    |
   | 5.1.14 Vendor Flexibility      |    C  |   C   |  C  |   C    |
   | 5.1.15 NAT Traversal           |    C  |   C   |  C  |   C    |
   |---------------------------------------------------------------|
   | Desirable                                                     |
   |---------------------------------------------------------------|
   | 5.2.1  Multiple Authentication |    C  |   C   |  C  |   C    |
   | 5.2.2  Future Wireless         |    C  |   C   |  C  |   C    |
   | 5.2.3  New IEEE Requirements   |    C  |   C   |  C  |   C    |
   | 5.2.4  Interconnection (IPv6)  |    C  |   C   |  C  |   C    |
   | 5.2.5  Access Control          |    C  |   C   |  C  |   C    |
    ---------------------------------------------------------------

   Figure 1: Summary Results

















Loher, et al.           Expires February 2, 2006               [Page 27]

Internet-Draft     Eval. of Candidate CAPWAP Protocols       August 2005


9.  Protocol Recommendation

   The proposals presented offer a variety of novel features which
   together would deliver a full featured, flexible and extensible
   CAPWAP protocol.  The most novel of these features leverage existing
   standards where feasable.  It is this evaluation team's opinion that
   a mix of the capabilities of the proposals will produce the best
   CAPWAP protocol.

   The recommended features are described below.  Many of these novel
   capabilities come from CTP and SLAPP and WiCoP.  However, LWAPP has
   the most complete base protocol and is flexible enough to be extended
   or modified by the working group.  We therefore recommend LWAPP be
   used as the basis for the CAPWAP protocol.

   The evaluation team recommends that the working group carefully
   consider the following issues and recommended changes.  The
   evaluation team believes that a more complete CAPWAP protocol will be
   delivered by addressing these issues and changes.

9.1.  High priority recommendations relevant to mandatory objectives

9.1.1.  Information Elements

   LWAPP's attribute value pair system meets the objectives as defined
   by the working group.  However, it has only 8 bits assigned for
   attribute types, with an additional 8 bits for a specific element
   within a attribute type.  The evaluation team strongly recommends
   that a larger number of bits be assigned for attribute types and
   information elements.

9.1.2.  Control Channel Security

   LWAPP's security mechanisms appear satisfactory and could serve
   CAPWAP going forward.  However, the evaluation team recommends
   adoption of a standard security protocol for the control channel.

   There are several motivations for a standards based security
   protocol, but the primary disadvantage of a new security protocol is
   that it will take longer and be more difficult to standardize than
   reusing an existing IETF standard.  First, a new security protocol
   will face a longer, slower approval processes from the Security Area
   Directorate and the IESG.  The new CAPWAP security protocol will need
   to pass several tests including:

   What is uniquely required by CAPWAP that is not available from an
   existing standard protocol?  How will CAPWAP's security protocol meet
   security area requirements for extensibility, such as the ability to



Loher, et al.           Expires February 2, 2006               [Page 28]

Internet-Draft     Eval. of Candidate CAPWAP Protocols       August 2005


   support future cipher suites and new key exchange methods?  How does
   this ability compare to established security protocols which have
   these capabilities?

   Points such as these are continually receiving more attention in the
   industry and in the IETF.  Extensibility of key exchange methods and
   ciper suites are becoming industry standard best practices.  These
   issues are important topics in the IETF Security Area Advisory Group
   (SAAG) and the recent SecMech BOF.

   These issues could be nullified by adopting an appropriate existing
   standard security protocol.  IPsec or DTLS could be a standards
   alternative to LWAPP's specification.  DTLS presents a UDP variant of
   TLS.  Although DTLS is relatively new, TLS is a heavily used, tried
   and tested security protocol.

   The evaluation team recommends that whatever security protocol is
   specified for CAPWAP, that it's use cases must be described in
   detail.  LWAPP does a good job of this with it's proposed,
   proprietary method.  If an updated specification is developed, it
   should contain at least one mandatory authentication and cipher
   method.  For example, pre-shared key and x.509 certificates could be
   specified as mandatory authentication methods and AES CCMP could be
   selected as a mandatory cipher.

   Given the possibilities for code reuse, industry reliance on TLS and
   the future for TLS, DTLS may be a wise alternative to a security
   method specific to CAPWAP.  In addition, use of DTLS would likely
   expidite the approval of CAPWAP as a proposed standard over the use
   of CAPWAP specific security mechanisms.

9.1.3.  Data Tunneling Modes

9.1.3.1.  Support for Local MAC User Data Tunneling

   The issue of data encapsulation is closely related to the Split and
   Local MAC architectures.  The Split MAC architecture requires some
   form of data tunneling.  All the proposals except LWAPP offer a
   method of tunneling in Local MAC mode as well.  By Local MAC data
   tunneling, we mean the tunneling of user data as 802.3 Ethernet
   frames back to the AC from a WTP which is otherwise in Local MAC
   mode.

   Tunneling data in Local MAC mode offers the ability for implementors
   to innovate in several ways even while using a Local MAC
   architecture.  For example, functions such as mobility, flexible user
   data encryption options, fast handoffs can be enabled through
   tunneling of user data back to an AC, or as LWAPP defines, a data



Loher, et al.           Expires February 2, 2006               [Page 29]

Internet-Draft     Eval. of Candidate CAPWAP Protocols       August 2005


   termination endpoint, which could be different than the AC.  In
   addition, special QoS or application aware treatments of user data
   packets such as voice or video.  Improved transparency and
   compatibility with future wireless technologies are also possible
   when encapsulating user data in a common format, such as 802.3,
   between the access point and the AC or other termination point in the
   network.

   Another possibility is when a native wireless MAC changes in the
   future, if a new WTP which supports this MAC change can also support
   a wireless MAC -> 802.3 integration function, then the wireless MAC
   layer change may remain transparent to an AC and still maintain many
   of the benefits that data tunneling can bring.

   LWAPP does support a header for tunneled user data which contains
   layer 1 wireless information (RSSI and SNR) that is independant of
   the wireless layer 2 MAC.  Innovations related to the use of RSSI and
   SNR at the AC may be retained even when tunneling 802.3 user data
   across different wireless MAC's.

   It is likely many other features could be created by innovative
   implementors using this method.  However, LWAPP narrowly defines the
   Local MAC architecture to exclude an option of tunneling data frames
   back to the AC.  Given the broad support for tunneling 802.3 data
   frames between WTP and AC across all the proposals and existing
   proprietary industry implementations, the evaluation team strongly
   recommends the working group consider a data tunneling mode for Local
   MAC be added to the LWAPP proposal and become part of the standard
   CAPWAP protocol.

9.1.3.2.  Mandatory and Optional Tunneling Modes

   If more than one tunneling mode is part of the CAPWAP protocol the
   evaluation team recommends that the working group choose one method
   as mandatory and other methods as optional.  In addition, the CAPWAP
   protocol must implement the ability to negotiate which tunneling
   methods are supported through a capabilities exchange.  This allows
   AC's and WTP's freedom to implement a variety of modes but always
   have the option of falling back to a common mode.

   The choice of which mode(s) should be mandatory is an important
   decision and may impact many decisions an implementor has to make
   with their hardware and software choices for both WTP's and AC's.
   The evaluation team believes the working group should address this
   issue of Local MAC data tunneling and carefully choose which mode(s)
   should be mandatory.





Loher, et al.           Expires February 2, 2006               [Page 30]

Internet-Draft     Eval. of Candidate CAPWAP Protocols       August 2005


9.2.  Additional Recommendations Relevant to Desirable Objectives

9.2.1.  Access Control

   Abstraction of STA access control, such as that implemented in CTP
   and WiCoP, stands out as a valuable feature as it is fundamental to
   the operational capabilities of many types of wireless networks, not
   just 802.11.  LWAPP implements station access control as a 802.11
   specific function via forwarding of 802.11 control frames to the
   access controller.  LWAPP has abstracted the STA Delete function out
   of the 802.11 binding.  However, the Add STA function is part of the
   802.11 binding.  It would be useful to implement the wireless MAC
   independant functions for adding a STA outside of the 802.11 binding.

9.2.2.  Removal of Layer 2 Encapsulation for Data Tunneling

   LWAPP currently specifies layer 2 and layer 3 methods for data
   tunneling.  The evaluation team believes the layer 2 method is
   redundant to the layer 3 method.  The team recommends the layer 2
   method encapsulation be removed from the LWAPP protocol.

9.2.3.  Data Encapsulation Standard

   LWAPP's layer 3 data encapsulation meet's the working group
   objectives.  However, The evaluation team recommends the use of a
   standards based protocol for encapsulation of user data between the
   WTP and AC.  GRE or L2TP could make good candidates as standards
   based encapsulation protocols for data tunneling.

   Using a standard gives the opprotunity for code reuse, whether it is
   off-the-shelf microcode for processors, code modules that can be
   purchased for real time operating systems, or open-source
   implementations for Unix based systems.  In addition, L2TP and GRE
   are designed to encapsulate multiple data types, increasing
   flexibility for supporting future wireless technologies.

10.  References

   [ARCH]     Yang, L., Zerfos, P., and E. Sadot, "Architecture Taxonomy
              for Control and Provisioning of Wireless Access
              Points(CAPWAP)", November 2004.

   [CTP]      Singh , I., Francisco, P., Pakulski , K., and F. Backes ,
              "CAPWAP Tunneling Protocol (CTP)", April 2005.

   [LWAPP]    Calhoun, P., O'Hara, B., Kelly, S., Suri, R., Williams,
              M., Hares, S., and N. Cam Winget, "Light Weight Access
              Point Protocol (LWAPP)", March 2005.



Loher, et al.           Expires February 2, 2006               [Page 31]

Internet-Draft     Eval. of Candidate CAPWAP Protocols       August 2005


   [OBJ]      Govindan, S., Yao, ZH., Zhou, WH., Yang, L., and H. Cheng,
              "Objectives for Control and Provisioning of Wireless
              Access Points (CAPWAP)", June 2005.

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

   [RFC3127]  Mitton, D., St.Johns, M., Barkley, S., Nelson, D., Patil,
              B., Stevens, M., and B. Wolff, "Authentication,
              Authorization, and Accounting: Protocol Evaluation",
              RFC 3127, June 2001.

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

   [WICOP]    Iino, S., Govindan, S., Sugiura, M., and H. Cheng,
              "Wireless LAN Control Protocol (WiCoP)", March 2005.


































Loher, et al.           Expires February 2, 2006               [Page 32]

Internet-Draft     Eval. of Candidate CAPWAP Protocols       August 2005


Authors' Addresses

   Darren P. Loher
   Roving Planet, Inc.
   7237 Church Ranch Blvd.
   Westminster, CO  80021
   USA

   Phone: +1.303.996.7560
   Email: dloher@rovingplanet.com


   David B. Nelson
   Enterasys Networks, Inc.
   50 Minuteman Road
   Anover, MA  01810-1008
   USA

   Phone: +1.978.684.1330
   Email: dnelson@enterasys.com


   Oleg Volinsky
   Colubris Networks, Inc.
   200 West Street
   Waltham, MA  02451
   USA

   Phone: +1.781.547.0329
   Email: ovolinsky@colubris.com


   Behcet Sarikaya
   UNBC
   Computer Science Dept.
   3333 University Way
   Prince George, BC  V2N 4Z9
   Canada

   Phone: +1.250.960.5551
   Email: sarikaya@ieee.org










Loher, et al.           Expires February 2, 2006               [Page 33]

Internet-Draft     Eval. of Candidate CAPWAP Protocols       August 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.




Loher, et al.           Expires February 2, 2006               [Page 34]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/