GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4565

Network Working Group D. Loher Request for Comments: 4565 Envysion, Inc. Category: Informational D. Nelson

                                              Enterasys Networks, Inc.
                                                           O. Volinsky
                                               Colubris Networks, Inc.
                                                           B. Sarikaya
                                                            Huawei USA
                                                             July 2006
         Evaluation of Candidate Control and Provisioning
            of Wireless Access Points (CAPWAP) Protocols

Status of This Memo

 This memo provides information for the Internet community.  It does
 not specify an Internet standard of any kind.  Distribution of this
 memo is unlimited.

Copyright Notice

 Copyright (C) The Internet Society (2006).

Abstract

 This document is a record of the process and findings of the Control
 and Provisioning of Wireless Access Points Working Group (CAPWAP WG)
 evaluation team.  The evaluation team reviewed the 4 candidate
 protocols as they were submitted to the working group on June 26,
 2005.

Table of Contents

 1. Introduction ....................................................3
    1.1. Conventions Used in This Document ..........................3
    1.2. Terminology ................................................3
 2. Process Description .............................................3
    2.1. Ratings ....................................................3
 3. Member Statements ...............................................4
 4. Protocol Proposals and Highlights ...............................5
    4.1. LWAPP ......................................................5
    4.2. SLAPP ......................................................6
    4.3. CTP ........................................................6
    4.4. WiCoP ......................................................7

Loher, et al. Informational [Page 1] RFC 4565 Evaluation of Candidate CAPWAP Protocols July 2006

 5. Security Considerations .........................................7
 6. Mandatory Objective Compliance Evaluation .......................8
    6.1. Logical Groups .............................................8
    6.2. Traffic Separation .........................................8
    6.3. STA Transparency ...........................................9
    6.4. Configuration Consistency .................................10
    6.5. Firmware Trigger ..........................................11
    6.6. Monitor and Exchange of System-wide Resource State ........12
    6.7. Resource Control ..........................................13
    6.8. Protocol Security .........................................15
    6.9. System-Wide Security ......................................16
    6.10. 802.11i Considerations ...................................17
    6.11. Interoperability .........................................17
    6.12. Protocol Specifications ..................................18
    6.13. Vendor Independence ......................................19
    6.14. Vendor Flexibility .......................................19
    6.15. NAT Traversal ............................................20
 7. Desirable Objective Compliance Evaluation ......................20
    7.1. Multiple Authentication ...................................20
    7.2. Future Wireless Technologies ..............................21
    7.3. New IEEE Requirements .....................................21
    7.4. Interconnection (IPv6) ....................................22
    7.5. Access Control ............................................23
 8. Evaluation Summary and Conclusions .............................24
 9. Protocol Recommendation ........................................24
    9.1. High-Priority Recommendations Relevant to
         Mandatory Objectives ......................................25
         9.1.1. Information Elements ...............................25
         9.1.2. Control Channel Security ...........................25
         9.1.3. Data Tunneling Modes ...............................26
    9.2. Additional Recommendations Relevant to Desirable
         Objectives ................................................27
         9.2.1. Access Control .....................................27
         9.2.2. Removal of Layer 2 Encapsulation for Data
                Tunneling ..........................................28
         9.2.3. Data Encapsulation Standard ........................28
 10. Normative References ..........................................29
 11. Informative References ........................................29

1. Introduction

 This document is a record of the process and findings of the Control
 and Provisioning of Wireless Access Points Working Group (CAPWAP WG)
 evaluation team.  The evaluation team reviewed the 4 candidate
 protocols as they were submitted to the working group on June 26,
 2005.

Loher, et al. Informational [Page 2] RFC 4565 Evaluation of Candidate CAPWAP Protocols July 2006

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 uses terminology defined in RFC 4118 [ARCH], RFC 4564
 [OBJ], and IEEE 802.11i [802.11i].

2. Process Description

 The process to be described here has been adopted from a previous
 evaluation in IETF [RFC3127].  The CAPWAP objectives in RFC 4564
 [OBJ] were 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 4 candidate protocols, the evaluation document editor
 assigned 2 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.

Loher, et al. Informational [Page 3] RFC 4565 Evaluation of Candidate CAPWAP Protocols July 2006

 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 4-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 a brief with supporting details.  The team discussed 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.

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 cochair 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 coauthor of RFC 3127 [RFC3127].  I was an active contributor in the
 IEEE 802.11i task group, and previously employed in the WLAN

Loher, et al. Informational [Page 4] RFC 4565 Evaluation of Candidate CAPWAP Protocols July 2006

 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 coauthored 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
 5 years of experience in IETF as a member of mobile networking-
 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.

4. Protocol Proposals and Highlights

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

4.1. LWAPP

 The "Light Weight Access Point Protocol" [LWAPP] was the first CAPWAP
 protocol originally submitted to Seamoby Working Group.  LWAPP
 proposes original solutions for authentication and 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.

Loher, et al. Informational [Page 5] RFC 4565 Evaluation of Candidate CAPWAP Protocols July 2006

 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 its use of raw 802.11
 frames that are tunneled back to the Access Controller (AC) for
 processing.  In both local- and split-MAC modes, 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.
 While in concept, LWAPP could be used for other wireless
 technologies, LWAPP defines very few primitives that are independent
 of the 802.11 layer.

4.2. SLAPP

 "Secure Light Access Point Protocol" [SLAPP] distinguishes itself
 with the use of well-known, established technologies such as Generic
 Routing Encapsulation (GRE) for user data tunneling between the AC
 and Wireless Termination Point (WTP) and the proposed standard
 Datagram Transport Layer Security [DTLS] for the control channel
 transport.
 4 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 that are encapsulated in SLAPP control packets across all
 modes. (STA refers to a wireless station, typically a laptop.)
 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.

4.3. CTP

 "CAPWAP Tunneling Protocol" [CTP] distinguishes itself with its use
 of Simple Network Management Protocol (SNMP) to define configuration
 and management data that it then encapsulates in an encrypted control
 channel.  CTP was originally designed as a local-MAC protocol 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.

Loher, et al. Informational [Page 6] RFC 4565 Evaluation of Candidate CAPWAP Protocols July 2006

 In local-MAC mode, CTP does not forward any native wireless frames to
 the AC.  CTP specifies control messages for STA session activity,
 mobility, and radio frequency (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.

4.4. WiCoP

 "Wireless LAN Control Protocol" [WICOP] introduces new discovery,
 configuration, and management of Wireless LAN (WLAN) systems.  The
 protocol defines a distinct discovery mechanism that integrates WTP-
 AC capabilities negotiation.
 WiCoP defines 802.11 Quality of Service (QoS) parameters.  In
 addition, the protocol proposes to use standard security and
 authentication methods such as IPsec and Extensible Authentication
 Protocol (EAP).  The protocol needs to go into detail with regards to
 explicit use of the above-mentioned methods.  To ensure interoperable
 protocol implementations, it is critical to provide users with
 detailed unambiguous specification.

5. Security Considerations

 Each of the candidate protocols has a Security Considerations
 section, as well as security properties.  The CAPWAP objectives
 document [OBJ] contains security-related requirements.  The
 evaluation team has considered if and how the candidate protocols
 implement the security features required by the CAPWAP objectives.
 However, this evaluation team is not a security team and has not

Loher, et al. Informational [Page 7] RFC 4565 Evaluation of Candidate CAPWAP Protocols July 2006

 performed a thorough security evaluation or tests.  Any protocol
 coming out of the CAPWAP working group must undergo an IETF security
 review in order to fully meet the objectives.

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 the AC to create a WLAN with a unique ID, i.e., its Service
 Set Identifier (SSID).  The WTPs in this WLAN have their own Basic
 Service Set Identifiers (BSSIDs).  LWAPP meets this objective.
 SLAPP
 SLAPP explicitly supports 0-255 BSSIDs.
 CTP
 CTP implements a NETWORK_ID attribute that allows a wireless-
 technology-independent 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, the message is a control message.  So, LWAPP meets this
 objective.

Loher, et al. Informational [Page 8] RFC 4565 Evaluation of Candidate CAPWAP Protocols July 2006

 SLAPP
 The SLAPP protocol encapsulates control using DTLS and optionally,
 user data with GRE.  Of particular note, SLAPP defines 4
 "architecture modes" that define how user data is handled in relation
 to the AC.  SLAPP is compliant with this objective.
 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 it opted to rate CTP as only partially
 compliant.  It appears that CTP would rely on SNMP MIB Object
 Identifiers (OIDs) for this function, but none were defined in the
 specification.  Defining the necessary OIDs 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.

Loher, et al. Informational [Page 9] RFC 4565 Evaluation of Candidate CAPWAP Protocols July 2006

 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.

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 events and statistics are available to report configuration
 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
 straightforward.  Where specified in a MIB, one could take advantage
 of default values.
 WICOP
 The WiCoP configuration starts with exchange of capability messages
 between the WTP and AC.  Next, configuration control data is sent to
 the WTP.

Loher, et al. Informational [Page 10] RFC 4565 Evaluation of Candidate CAPWAP Protocols July 2006

 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 the AC is acknowledged by the 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
 to initiate the process for checking and performing a firmware update
 independently 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 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 begin 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 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.

Loher, et al. Informational [Page 11] RFC 4565 Evaluation of Candidate CAPWAP Protocols July 2006

 SLAPP
 SLAP includes a firmware check and update procedure that 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
 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 3 methods
 relevant to statistics from WTPs: 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 the WTP using an "Event Request" message.
 LWAPP defines an 802.11 statistics message that covers 802.11 MAC
 layer properties.  LWAPP is compliant.
 SLAPP
 WLAN statistics transport is supplied via the control channel and
 encoded in SLAPP-defined TLVs called information elements. 802.11
 configuration and statistics information elements are supplied in
 [SLAPP] 6.1.3.1.  These are extendable and include vendor-specific
 extensions.

Loher, et al. Informational [Page 12] RFC 4565 Evaluation of Candidate CAPWAP Protocols July 2006

 CTP
 CTP defines a control message called "CTP Stats-Notify".  This
 control message contains statistics in the form of SNMP OIDs and is
 sent from the WTP to AC.  This approach is novel because it leverages
 the use of standard SNMP.
 Section 5.3.10 of [CTP] recommends the use of 802.11 MIBs where
 applicable.  However, the proposal acknowledges that additional
 configuration and statistics information is required, but does not
 specify these MIB extensions.  CTP needs to add these extensions to
 the proposal.  Also, this minimum set of statistics and configuration
 OIDs must become requirements in order to fully meet the objective.
 WiCoP
 The feedback control message sent by the WTP contains many
 statistics.  WiCoP specifies 15 statistics that the WTP needs to send
 to the AC.  New versions of WiCoP can address any new statistics that
 the AC needs to monitor the WTP.  WiCoP meets this objective.

6.7. Resource Control

 LWAPP:C, SLAPP:P, CTP:P, WiCoP:P
 The evaluation team interpreted the resource control objective to
 mean that the CAPWAP protocol must map 802.11e QoS markings to the
 wired network.  This mapping must include any encapsulation or
 tunneling of user data defined by the CAPWAP protocol.  Of particular
 note, the evaluation team agreed that the CAPWAP protocol should
 supply an explicit capability to configure this mapping.  Since most
 of the protocols relied only on the 802.11e statically defined
 mapping, most received a partial compliance.
 LWAPP
 LWAPP defines its own custom TLV structure, which consists of an
 8-bit type or class of information value and an additional 8-bit
 value that indexes to a specific variable.
 LWAPP allows the mobile station-based QoS configuration in each Add
 Mobile Request sent by AC to WTP for each new mobile station that is
 attached.  Packet prioritization is left to individual WTPs. 4
 different QoS policies for each station to enforce can be configured.
 Update Mobile QoS message element can be used to change QoS policy at
 the WTP for a given mobile station.  LWAPP should support 8 QoS
 policies as this matches 802.11e 802.1p and IP TOS, but for this
 objective, 4 classes is compliant.

Loher, et al. Informational [Page 13] RFC 4565 Evaluation of Candidate CAPWAP Protocols July 2006

 Overall, LWAPP conforms to the resource control objective.  It
 enables QoS configuration and mapping.  The control can be applied on
 a logical group basis and also enables the wireless traffic to be
 flexibly mapped to the wired segment.
 SLAPP
 Although 802.11e specifies 802.1p and Differentiated Service Code
 Point (DSCP) mappings, there is no explicit support for 802.11e in
 SLAPP.  SLAPP must be updated to add 802.11e as one of the standard
 capabilities that a WTP could support and specify a mechanism that
 would allow configuration of mapping the QoS classes.
 CTP
 CTP requires that the WTP and AC copy the QoS marking of user data to
 the data message encapsulation.  This mapping is accomplished by the
 CTP Header's 1-byte policy field.  However, no configuration of QoS
 mapping other than copying the user data's already existing markings
 is defined in CTP.  It seems clear that SNMP could be used to
 configure the mapping to occur differently, but no OIDs are defined
 that would enable this.  Partial compliance is assigned to CTP for
 this objective.
 WiCoP
 Note: WiCoP rating for resource control objectives has been upgraded
 from Failed to Partial.  After an additional review of the WiCoP
 protocol proposal, it was determined that the protocol partially
 meets resource control objectives.
 WiCoP protocol starts its QoS configuration with 802.11e capability
 exchange between the WTP and AC.  The QoS capabilities primitives are
 included in the capability messages.
 WiCoP defines the QoS-Value message that contains 802.11e
 configuration parameters.  This is sent for each group supported by
 the WTP.  WiCoP does not provide an explicit method for configuration
 of DSCP tags and 802.1P precedence values.  It is possible to
 configure these parameters through SNMP OID configuration method, but
 WiCoP does not explicitly identify any specific MIBs.  Overall, WiCoP
 partially meets resource control CAPWAP objectives.  In order to be
 fully compliant with the given objective, the protocol needs to
 identify a clear method to configure 802.1p and DSCP mappings.

Loher, et al. Informational [Page 14] RFC 4565 Evaluation of Candidate CAPWAP Protocols July 2006

6.8. Protocol Security

 LWAPP:C, SLAPP:C, CTP:F, WiCoP:F
 For the purposes of the protocol security objective, the evaluation
 team primarily considered whether or not the candidate protocols
 implement the security features required by the CAPWAP objectives.
 Please refer to the Security Considerations section of this document.
 LWAPP
 It appears that the security mechanisms, including the key management
 portions in LWAPP, are correct.  One third-party security review has
 been performed.  However, further security review is warranted since
 a CAPWAP-specific key exchange mechanism is defined.  LWAPP is
 compliant with the objective.
 SLAPP
 The SLAPP protocol implements authentication of the WTP by the AC
 using the DTLS protocol.  This behavior is defined in both the
 discovery process and the 802.11 control process.  SLAPP allows
 mutual and asymmetric authentication.  SLAPP also gives informative
 examples of how to properly use the authentication.  SLAPP should add
 another informative example for authentication of the AC by the WTP.
 SLAPP is compliant with the objective.
 CTP
 The original presentation at IETF63 of the preliminary findings of
 the evaluation team reported that CTP failed this objective.  This
 was on the basis of asymmetric authentication not being supported by
 CTP.  This was due to a misunderstanding of what was meant by
 asymmetric authentication by the evaluation team.  The definitions of
 the terminology used in [OBJ] were clarified on the CAPWAP mailing
 list.  CTP in fact does implement a form of asymmetric authentication
 through the use of public keys.
 However, CTP still fails to comply with the objective for two
 reasons:
 First, CTP does not mutually derive session keys.  Second, CTP does
 not perform explicit mutual authentication because the 2 parties
 authenticating do not confirm the keys.

Loher, et al. Informational [Page 15] RFC 4565 Evaluation of Candidate CAPWAP Protocols July 2006

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

6.9. System-Wide Security

 LWAPP:C, SLAPP:C, CTP:F, WiCoP:F
 LWAPP
 LWAPP wraps all control and management communication in its
 authenticated and encrypted control channel.  LWAPP does not seem
 particularly vulnerable to Denial of Service (DoS).  LWAPP should
 make a recommendation that the Join method be throttled to reduce the
 impact of DoS attacks against it.  Use of an established security
 mechanism such as IPsec would be preferred.  However, LWAPP's
 independent security review lent enough confidence to declare LWAPP
 compliant with the objective.
 SLAPP
 SLAPP is compliant due to wrapping all control and management
 communication in DTLS.  SLAPP also recommends measures to protect
 against discovery request DoS attacks.  DTLS has undergone security
 review and has at least one known implementation outside of SLAPP.
 At the time of this writing, DTLS is pending proposed standard status
 in the IETF.
 CTP
 CTP introduces a new, unestablished mechanism for AC-to-WTP
 authentication.  For complete compliance, use of an established
 security mechanism with detailed specifications for its use in CTP is
 preferred.  Alternatively, a detailed security review could be
 performed.  CTP does not point out or recommend or specify any DoS
 attack mitigation requirements against Reg-Req and Auth-Req floods,
 such as a rate limiter.  Because CTP received an 'F' on its protocol
 security objective, it follows that system-wide security must also be
 rated 'F'.
 WiCoP
 WiCop does not address DoS attack threats.  Also, as with the
 protocol security objective, the protocol needs to explicitly
 describe its tunnel and authentication methods.

Loher, et al. Informational [Page 16] RFC 4565 Evaluation of Candidate CAPWAP Protocols July 2006

6.10. 802.11i Considerations

 LWAPP:C, SLAPP:C, CTP:F, WiCoP:P
 LWAPP
 LWAPP explicitly defines mechanisms for handling 802.11i in its modes
 with encryption terminated at the WTP.  In order to accomplish this,
 the AC sends the Pairwise Transient Key (PTK) using the encrypted
 control channel to the WTP using the Add Mobile message.  When
 encryption is terminated at the AC, there are no special
 requirements.  LWAPP is compliant.
 SLAPP
 SLAPP defines a control message to send the PTK and Group Temporal
 Key (GTK) to the WTP when the WTP is the encryption endpoint.  This
 control message is carried on the DTLS protected control channel.
 SLAPP is compliant.
 CTP
 CTP lacks a specification for a control message to send 802.11i PTK
 and GTK keys to a WTP when the WTP is an encryption endpoint.  Based
 on this, CTP fails compliance for this objective.  This requirement
 could be addressed either by defining new control channel information
 elements or by simply defining SNMP OIDs.  The transport of these
 OIDs would be contained in the secure control channel and therefore
 protected.
 WiCoP
 WiCoP lacks documentation on how to handle 4-way handshake.  The case
 for encryption at the AC needs clarification.

6.11. Interoperability

 LWAPP:C, SLAPP:C, CTP:C, WiCoP:C
 LWAPP
 LWAPP supports both split- and local-MAC architectures and is
 therefore compliant to the letter of the objectives.  LWAPP is
 particularly rich in its support of the split-MAC architecture.
 However, LWAPP's support of local-MAC is somewhat limited and could
 be expanded.  LWAPP is lacking a mode that allows local-MAC data

Loher, et al. Informational [Page 17] RFC 4565 Evaluation of Candidate CAPWAP Protocols July 2006

 frames to be tunneled back to the AC.  A discussion of possible
 extensions and issues is discussed in the recommendations section of
 this evaluation.
 SLAPP
 SLAPP is compliant.
 CTP
 CTP is compliant.
 WiCoP
 WiCoP is compliant.

6.12. Protocol Specifications

 LWAPP:C, SLAPP:P, CTP:P, WiCoP:P
 LWAPP
 LWAPP is nearly fully documented.  Only a few sections are noted as
 incomplete.  Detailed descriptions are often given to explain the
 purpose of the protocol primitives defined that should encourage
 interoperable implementations.
 SLAPP
 SLAPP is largely implementable from its specification.  It contains
 enough information to perform an interoperable implementation for its
 basic elements; however, additional informative references or
 examples should be provided covering use of information elements,
 configuring multiple logical groups, and so on.
 CTP
 As noted earlier, there are a few areas where CTP lacks a complete
 specification, primarily due to the lack of specific MIB definitions.
 WiCoP
 Due to the lack of specific tunnel specifications and authentication
 specifications, WiCoP is only partially compliant.

Loher, et al. Informational [Page 18] RFC 4565 Evaluation of Candidate CAPWAP Protocols July 2006

6.13. Vendor Independence

 LWAPP:C, SLAPP:C, CTP:C, WiCoP:C
 LWAPP
 LWAPP is compliant.
 SLAPP
 SLAPP is compliant.
 CTP
 CTP is compliant.
 WiCoP
 WiCoP is compliant.

6.14. Vendor Flexibility

 LWAPP:C, SLAPP:C, CTP:C, WiCoP:C
 LWAPP
 LWAPP is compliant.
 SLAPP
 SLAPP is compliant.
 CTP
 CTP is compliant.
 WiCoP
 WiCoP is compliant.

Loher, et al. Informational [Page 19] RFC 4565 Evaluation of Candidate CAPWAP Protocols July 2006

6.15. NAT Traversal

 LWAPP:C, SLAPP:C, CTP:C, WiCoP:C
 LWAPP
 LWAPP may require special considerations due to it carrying the IP
 address of the AC and data termination points in the payload of
 encrypted control messages.  To overcome Network Address Translation
 (NAT), static NAT mappings may need to be created at the NAT'ing
 device if the AC or data termination points addresses are translated
 from the point of view of the WTP.  A WTP should be able to function
 in the hidden address space of a NAT'd network.
 SLAPP
 SLAPP places no out-of-the-ordinary constraints regarding NAT.  A WTP
 could function in the hidden address space of a NAT'd network without
 any special configuration.
 CTP
 CTP places no out-of-the-ordinary constraints regarding NAT.  A WTP
 could function in the hidden address space of a NAT'd network without
 any special configuration.
 WiCoP
 WiCoP places no out-of-the-ordinary constraints regarding NAT.  A WTP
 could function in the hidden address space of a NAT'd network without
 any special configuration.

7. Desirable Objective Compliance Evaluation

7.1. Multiple Authentication

 LWAPP:C, SLAPP:C, CTP:C, WiCoP:C
 LWAPP
 LWAPP allows for multiple STA authentication mechanisms.
 SLAPP
 SLAPP does not constrain other authentication techniques from being
 deployed.

Loher, et al. Informational [Page 20] RFC 4565 Evaluation of Candidate CAPWAP Protocols July 2006

 CTP
 CTP supports multiple STA authentication mechanisms.
 WiCoP
 WiCoP allows for multiple STA authentication mechanisms.

7.2. Future Wireless Technologies

 LWAPP:C, SLAPP:C, CTP:C, WiCoP:C
 LWAPP
 LWAPP could be used for other wireless technologies.  However, LWAPP
 defines very few primitives that are independent of the 802.11 layer.
 SLAPP
 SLAPP could be used for other wireless technologies.  However, SLAPP
 defines very few primitives that are independent of the 802.11 layer.
 CTP
 CTP supplies STA control abstraction, methods for extending the
 forwarding of multiple types of native wireless management frames,
 and many options for user data tunneling.  Configuration management
 is an extension of SNMP, to which new MIBs could, in concept, be
 easily plugged in.  This helps makes CTP a particularly flexible
 proposal for supporting future wireless technologies.  In addition,
 CTP has already defined multiple wireless protocol types in addition
 to 802.11.
 WiCoP
 WiCoP could be used for other wireless technologies.

7.3. New IEEE Requirements

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

Loher, et al. Informational [Page 21] RFC 4565 Evaluation of Candidate CAPWAP Protocols July 2006

 SLAPP
 SLAPP's use of native 802.11 frames for control and management allows
 SLAPP a measure of transparency to changes in 802.11.  Because SLAPP
 also supports a mode that tunnels user data as 802.3 frames, it has
 additional architectural options for adapting to changes on the
 wireless infrastructure.
 CTP
 CTP has perhaps the greatest ability to adapt to changes in IEEE
 requirements.  Architecturally speaking, CTP has several options
 available for adapting to change.  SNMP OIDs are easily extended for
 additional control and management functions.  Native wireless frames
 can be forwarded directly to the AC if necessary.  Wireless frames
 can be bridged to 802.3 frames and tunneled back to the AC to protect
 the AC from changes at the wireless MAC layer.  These options allow
 many possible ways to adapt to change of the wireless MAC layer.
 WiCoP
 Because WiCoP uses 802.11 frames for the data transport, it is
 transparent to most IEEE changes.  Any new IEEE requirements may need
 new configuration and new capability messages between the WTP and AC.
 The AC would need to be modified to handle new 802.11 control and
 management frames.

7.4. Interconnection (IPv6)

 LWAPP:C, SLAPP:C, CTP:C, WiCoP:C
 LWAPP
 LWAPP explicitly defines measures for accommodating IPv6.  LWAPP is
 more sensitive to this in part because it carries IP addresses in two
 control messages.
 SLAPP
 SLAPP is transparent to the interconnection layer.  DTLS and GRE will
 both operate over IPv6.
 CTP
 CTP is transparent to the interconnection layer.  CTP should be able
 to operate over IPv6 without any changes.

Loher, et al. Informational [Page 22] RFC 4565 Evaluation of Candidate CAPWAP Protocols July 2006

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

7.5. Access Control

 LWAPP:C, SLAPP:C, CTP:C, WiCoP:C
 LWAPP
 LWAPP uses native 802.11 management frames forwarded to the AC for
 the purpose of performing STA access control.  WTPs are authenticated
 in LWAPP's control protocol Join phase.
 SLAPP
 SLAPP has support for multiple authentication methods for WTPs.  In
 addition, SLAPP can control STA access via 802.11 management frames
 forwarded to the AC or via SLAPP's information element primitives.
 CTP
 CTP specifies STA access control primitives.
 WiCoP
 WiCoP specifies access control in [WICOP] section 5.2.2.

Loher, et al. Informational [Page 23] RFC 4565 Evaluation of Candidate CAPWAP Protocols July 2006

8. Evaluation Summary and Conclusions

 See Figure 1 (section numbers correspond to RFC 4564 [OBJ]).
  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

9. Protocol Recommendation

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

Loher, et al. Informational [Page 24] RFC 4565 Evaluation of Candidate CAPWAP Protocols July 2006

 The recommended features are described below.  Many of these novel
 capabilities come from CTP and SLAPP and WiCoP.  However, LWAPP has
 the most complete base protocol and is flexible enough to be extended
 or modified by the working group.  We therefore recommend that LWAPP
 be used as the basis for the CAPWAP protocol.
 The evaluation team recommends that the working group carefully
 consider the following issues and recommended changes.  The
 evaluation team believes that a more complete CAPWAP protocol will be
 delivered by addressing these issues and changes.

9.1. High-Priority Recommendations Relevant to Mandatory Objectives

9.1.1. Information Elements

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

9.1.2. Control Channel Security

 LWAPP's security mechanisms appear satisfactory and could serve
 CAPWAP going forward.  However, the evaluation team recommends
 adoption of a standard security protocol for the control channel.
 There are several motivations for a standards-based security
 protocol, but the primary disadvantage of a new security protocol is
 that it will take longer and be more difficult to standardize than
 reusing an existing IETF standard.  First, a new security protocol
 will face a longer, slower approval processes from the Security Area
 Directorate and the IESG.  The new CAPWAP security protocol will need
 to pass several tests including the following:
 What is uniquely required by CAPWAP that is not available from an
 existing standard protocol?  How will CAPWAP's security protocol meet
 security area requirements for extensibility, such as the ability to
 support future cipher suites and new key exchange methods?  How does
 this ability compare to established security protocols that have
 these capabilities?
 Points such as these are continually receiving more attention in the
 industry and in the IETF.  Extensibility of key exchange methods and
 cipher suites are becoming industry standard best practices.  These
 issues are important topics in the IETF Security Area Advisory Group
 (SAAG) and the SecMech BOF, held during the 63rd IETF meeting.

Loher, et al. Informational [Page 25] RFC 4565 Evaluation of Candidate CAPWAP Protocols July 2006

 These issues could be nullified by adopting an appropriate existing
 standard security protocol.  IPsec or DTLS could be a standards
 alternative to LWAPP's specification.  DTLS presents a UDP variant of
 Transport Layer Security (TLS).  Although DTLS is relatively new, TLS
 is a heavily used, tried-and-tested security protocol.
 The evaluation team recommends that whatever security protocol is
 specified for CAPWAP, its use cases must be described in detail.
 LWAPP does a good job of this with its proposed, proprietary method.
 If an updated specification is developed, it should contain at least
 one mandatory authentication and cipher method.  For example, pre-
 shared key and x.509 certificates could be specified as mandatory
 authentication methods, and Advanced Encryption Standard (AES)
 Counter Mode with CBC-MAC Protocol (CCMP) could be selected as a
 mandatory cipher.
 Given the possibilities for code reuse, industry reliance on TLS, and
 the future for TLS, DTLS may be a wise alternative to a security
 method specific to CAPWAP.  In addition, use of DTLS would likely
 expedite the approval of CAPWAP as a proposed standard over the use
 of CAPWAP-specific security mechanisms.

9.1.3. Data Tunneling Modes

9.1.3.1. Support for Local MAC User Data Tunneling

 The issue of data encapsulation is closely related to the split- and
 local-MAC architectures.  The split-MAC architecture requires some
 form of data tunneling.  All the proposals except LWAPP offer a
 method of tunneling in local-MAC mode as well.  By local-MAC data
 tunneling, we mean the tunneling of user data as 802.3 Ethernet
 frames back to the AC from a WTP that is otherwise in local-MAC mode.
 Tunneling data in local-MAC mode offers the ability for implementers
 to innovate in several ways even while using a local-MAC
 architecture.  For example, functions such as mobility, flexible user
 data encryption options, and fast handoffs can be enabled through
 tunneling of user data back to an AC, or as LWAPP defines, a data
 termination endpoint, which could be different from the AC.  In
 addition, there are 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.

Loher, et al. Informational [Page 26] RFC 4565 Evaluation of Candidate CAPWAP Protocols July 2006

 Another possibility is when a native wireless MAC changes in the
 future, if a new WTP that 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 that contains
 layer 1 wireless information (Received Signal Strength Indication
 (RSSI) and Signal-to-Noise Ratio (SNR)) that is independent 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 MACs.
 It is likely that many other features could be created by innovative
 implementers 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 the WTP and AC across all the proposals and existing
 proprietary industry implementations, the evaluation team strongly
 recommends that 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
 ACs and WTPs 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 implementers have to make with
 their hardware and software choices for both WTPs and ACs.  The
 evaluation team believes that the working group should address this
 issue of local-MAC data tunneling and carefully choose which mode(s)
 should be mandatory.

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 an 802.11-

Loher, et al. Informational [Page 27] RFC 4565 Evaluation of Candidate CAPWAP Protocols July 2006

 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
 independent 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 that the layer 2 method is
 redundant to the layer 3 method.  The team recommends that the layer
 2 method encapsulation be removed from the LWAPP protocol.

9.2.3. Data Encapsulation Standard

 LWAPP's layer 3 data encapsulation meets 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 Layer 2 Tunneling Protocol (L2TP) could make good
 candidates as standards-based encapsulation protocols for data
 tunneling.
 Using a standard gives the opportunity 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.

Loher, et al. Informational [Page 28] RFC 4565 Evaluation of Candidate CAPWAP Protocols July 2006

10. Normative References

 [802.11i]  IEEE Standard 802.11i, "Medium Access Control (MAC)
            Security Enhancements", July 2004.
 [ARCH]     Yang, L., Zerfos, P., and E. Sadot, "Architecture Taxonomy
            for Control and Provisioning of Wireless Access Points
            (CAPWAP)", RFC 4118, June 2005.
 [OBJ]      Govindan, S., Ed., Cheng, H., Yao, ZH., Zhou, WH., and L.
            Yang, "Objectives for Control and Provisioning of Wireless
            Access Points (CAPWAP)", RFC 4564, July 2006.
 [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", RFC 2119, March 1997.

11. Informative References

 [CTP]      Singh , I., Francisco, P., Pakulski , K., and F. Backes,
            "CAPWAP Tunneling Protocol (CTP)", Work in Progress, April
            2005.
 [DTLS]     Rescorla, E. and N. Modadugu, "Datagram Transport Layer
            Security", RFC 4347, April 2006.
 [LWAPP]    Calhoun, P., O'Hara, B., Kelly, S., Suri, R., Williams,
            M., Hares, S., and N. Cam Winget, "Light Weight Access
            Point Protocol (LWAPP)", Work in Progress, March 2005.
 [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", Work in Progress, May
            2005.
 [WICOP]    Iino, S., Govindan, S., Sugiura, M., and H. Cheng,
            "Wireless LAN Control Protocol (WiCoP)", Work in Progress,
            March 2005.

Loher, et al. Informational [Page 29] RFC 4565 Evaluation of Candidate CAPWAP Protocols July 2006

Authors' Addresses

 Darren P. Loher
 Envysion, Inc.
 2010 S. 8th Street
 Boulder, CO  80302
 USA
 Phone: +1.303.667.8761
 EMail: dplore@gmail.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
 Huawei USA
 1700 Alma Dr. Suite 100
 Plano, TX  75075
 USA
 Phone: +1.972.509.5599
 EMail: sarikaya@ieee.org

Loher, et al. Informational [Page 30] RFC 4565 Evaluation of Candidate CAPWAP Protocols July 2006

Full Copyright Statement

 Copyright (C) The Internet Society (2006).
 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.
 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.

Intellectual Property

 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.

Acknowledgement

 Funding for the RFC Editor function is provided by the IETF
 Administrative Support Activity (IASA).

Loher, et al. Informational [Page 31]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4565.txt · Last modified: 2006/07/08 03:28 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki