diff options
Diffstat (limited to 'doc/rfc/rfc4565.txt')
| -rw-r--r-- | doc/rfc/rfc4565.txt | 1739 |
1 files changed, 1739 insertions, 0 deletions
diff --git a/doc/rfc/rfc4565.txt b/doc/rfc/rfc4565.txt new file mode 100644 index 0000000..68fdf32 --- /dev/null +++ b/doc/rfc/rfc4565.txt @@ -0,0 +1,1739 @@ + + + + + + +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]). + + --------------------------------------------------------------- + | 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] + |