idnits 2.17.1 draft-ietf-capwap-eval-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1355. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1332. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1339. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1345. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 2005) is 6819 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'ARCH' -- Possible downref: Non-RFC (?) normative reference: ref. 'CTP' -- Possible downref: Non-RFC (?) normative reference: ref. 'LWAPP' -- Possible downref: Non-RFC (?) normative reference: ref. 'OBJ' ** Downref: Normative reference to an Informational RFC: RFC 3127 -- Possible downref: Non-RFC (?) normative reference: ref. 'SLAPP' -- Possible downref: Non-RFC (?) normative reference: ref. 'WICOP' Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Loher 3 Internet-Draft Roving Planet, Inc. 4 Expires: February 2, 2006 D. Nelson 5 Enterasys Networks, Inc. 6 O. Volinsky 7 Colubris Networks, Inc. 8 B. Sarikaya 9 UNBC 10 August 2005 12 Evaluation of Candidate CAPWAP Protocols 13 draft-ietf-capwap-eval-00 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on February 2, 2006. 40 Copyright Notice 42 Copyright (C) The Internet Society (2005). 44 Abstract 46 This document is a record of the process and findings of the 47 Configuration and Provisioning of Wireless Access Points Working 48 Group (CAPWAP WG) evaluation team. The evaluation team reviewed the 49 four candidate protocols as they were submitted to the working group 50 on the 26th of June, 2005. 52 Table of Contents 54 1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 1.1. Conventions used in this document . . . . . . . . . . . . 4 56 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 57 2. Process Description . . . . . . . . . . . . . . . . . . . . . 5 58 2.1. Ratings . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 3. Member Statements . . . . . . . . . . . . . . . . . . . . . . 7 60 4. Protocol Proposals and Highlights . . . . . . . . . . . . . . 9 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 62 6. Mandatory Objective Compliance Evaluation . . . . . . . . . . 12 63 6.1. Logical Groups . . . . . . . . . . . . . . . . . . . . . . 12 64 6.2. Traffic Separation . . . . . . . . . . . . . . . . . . . . 12 65 6.3. STA Transparency . . . . . . . . . . . . . . . . . . . . . 13 66 6.4. Configuration Consistency . . . . . . . . . . . . . . . . 14 67 6.5. Firmware Trigger . . . . . . . . . . . . . . . . . . . . . 14 68 6.6. Monitor and Exchange of System-wide Resource State . . . . 16 69 6.7. Resource Control . . . . . . . . . . . . . . . . . . . . . 17 70 6.8. Protocol Security . . . . . . . . . . . . . . . . . . . . 18 71 6.9. System-Wide Security . . . . . . . . . . . . . . . . . . 19 72 6.10. 802.11i Considerations . . . . . . . . . . . . . . . . . . 20 73 6.11. Interoperability . . . . . . . . . . . . . . . . . . . . . 21 74 6.12. Protocol Specifications . . . . . . . . . . . . . . . . . 21 75 6.13. Vendor Independence . . . . . . . . . . . . . . . . . . . 22 76 6.14. Vendor Flexibility . . . . . . . . . . . . . . . . . . . . 22 77 6.15. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 23 78 7. Desirable Objective Compliance Evaluation . . . . . . . . . . 24 79 7.1. Multiple Authentication . . . . . . . . . . . . . . . . . 24 80 7.2. Future Wireless Technologies . . . . . . . . . . . . . . . 24 81 7.3. New IEEE Requirements . . . . . . . . . . . . . . . . . . 25 82 7.4. Interconnection (IPv6) . . . . . . . . . . . . . . . . . . 25 83 7.5. Access Control . . . . . . . . . . . . . . . . . . . . . . 26 84 8. Evaluation Summary and Conclusions . . . . . . . . . . . . . . 27 85 9. Protocol Recommendation . . . . . . . . . . . . . . . . . . . 28 86 9.1. High priority recommendations relevant to mandatory 87 objectives . . . . . . . . . . . . . . . . . . . . . . . . 28 88 9.1.1. Information Elements . . . . . . . . . . . . . . . . . 28 89 9.1.2. Control Channel Security . . . . . . . . . . . . . . . 28 90 9.1.3. Data Tunneling Modes . . . . . . . . . . . . . . . . . 29 91 9.2. Additional Recommendations Relevant to Desirable 92 Objectives . . . . . . . . . . . . . . . . . . . . . . . . 31 93 9.2.1. Access Control . . . . . . . . . . . . . . . . . . . . 31 94 9.2.2. Removal of Layer 2 Encapsulation for Data Tunneling . 31 95 9.2.3. Data Encapsulation Standard . . . . . . . . . . . . . 31 97 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 99 Intellectual Property and Copyright Statements . . . . . . . . . . 34 101 1. Definitions 103 1.1. Conventions used in this document 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in RFC 2119 [RFC2119]. 109 1.2. Terminology 111 This document follows the terminology defined in [ARCH] (a work in 112 progress), and [OBJ] (also a work in progress). 114 2. Process Description 116 The process to be described here has been adopted from a previous 117 evaluation in IETF [RFC3127]. The CAPWAP objectives draft [OBJ] was 118 used to set the scope and direction for the evaluators and was the 119 primary source of requirements. However, the evaluation team also 120 used their expert knowledge and professional experience to consider 121 how well a candidate protocol met the working group objectives. 123 For each of the four candidate protocols, the evaluation draft editor 124 assigned two team members to write evaluation briefs. One member was 125 assigned to write a 'Pro' brief and could take a generous 126 interpretation of the proposal; this evaluator could grant benefit of 127 doubt. A second evaluator was assigned to write a 'Con' brief and 128 was required to use strict criteria when performing the evaluation. 130 2.1. Ratings 132 The "Pro and "Con" members independently evaluated how well the 133 candidate protocol met each objective. Each objective was scored as 134 an 'F' for failure , 'P' for partial or 'C' for completely meeting 135 the objective. 137 F - Failure to Comply 139 The evaluation team believes the proposal does not meet the 140 objective. This could be due to the proposal completely missing any 141 functionality towards the objective. A proposal could also receive 142 an 'F' for improperly implementing the objective. 144 P - Partial Compliance 146 The proposal has some functionality that addresses the objective, but 147 it is incomplete or ambiguous. 149 C - Compliant 151 The proposal fully specifies functionality meeting the objective. 152 The specification must be detailed enough that interoperable 153 implementations are likely from reading the proposal alone. If the 154 method is ambiguous or particularly complex, an explanation, use 155 cases or even diagrams may need to be supplied in order to receive a 156 compliant rating. 158 The four person evaluation team held a teleconference for each 159 candidate to discuss the briefs. One of the working group chairs was 160 also present at the meeting in an advisory capacity. Each evaluator 161 presented their brief with supporting details. The team discussed 162 the issues and delivered a team rating for each objective. These 163 discussions are documented in the meeting minutes. The team ratings 164 are used for the compliance evaluation. 166 The candidate protocols were scored only on the information written 167 in their draft. This means that a particular protocol might actually 168 meet the specifics of a requirement, but if the proposal did not 169 state, describe or reference how that requirement was met, it might 170 be scored lower. 172 3. Member Statements 174 Darren Loher, Roving Planet 176 I am employed as the senior architect at Roving Planet which writes 177 network and security management software for wireless networks. I 178 have over 11 years of commercial experience designing and operating 179 networks. I have implemented and operated networks and network 180 management systems for a university, large enterprises and a major 181 Internet service provider for over 4 years. I also have software 182 development experience and have written web based network and systems 183 management tools including a system for managing a very large 184 distributed DNS system. I have witnessed the IETF standards process 185 for several years, my first event being IETF 28. I have rarely 186 directly participated in any working group activities before this 187 point. To my knowledge, my company has no direct relationship with 188 any companies that have authored the CAPWAP protocol submissions. 190 David Nelson, Enterasys 192 I am currently co-chair of the RADEXT WG, AAA Doctor in O&M Area, and 193 employed in the core router engineering group of my company. I have 194 previously served on a protocol evaluation team in the AAA WG, and am 195 a co-author of RFC 3127 [RFC3127]. I was an active contributor in 196 the IEEE 802.11i task group, and previously employed in the WLAN 197 engineering group of my company. I have had no participation in any 198 of the submitted protocols. My company does have an OEM relationship 199 with at least one company whose employees have co-authored one of the 200 submissions, but I have no direct involvement with our WLAN product 201 at this time. 203 Oleg Volinsky, Colubris Networks 205 I am a member of the Enterprise group of Colubris Networks, a WLAN 206 vendor. I have over 10 years of experience in design and development 207 of network products from core routers to home networking equipment. 208 Over years I have participated in various IETF groups. I have been a 209 member of CAPWAP WG for over a year. In my current position I have 210 been monitoring the developments of CAPWAP standards and potential 211 integration of the resulting protocol into the company's products. I 212 have not participated in any of the candidate protocol drafts. I 213 have not worked for any of the companies whose staff authored any of 214 the candidate protocols. 216 Behcet Sarikaya, University of Northern British Columbia 218 I am currently Professor of Computer Science at UNBC. I have so far 219 five years of experience in IETF as a member of mobile networking 220 related working groups. I have made numerous I-D contributions and 221 am a coauthor of one RFC. I have submitted an evaluation draft (with 222 Andy Lee) that evaluated LWAPP, CTP and WiCoP. Also I submitted 223 another draft (on CAPWAPHP) that used LWAPP, CTP, WiCoP and SLAPP as 224 transport. I also have research interests on next generation access 225 point/controller architectures. I have no involvement in any of the 226 candidate protocol drafts, have not contributed any of the drafts. I 227 have not worked in any of the companies whose staff has produced any 228 of the candidate protocols. 230 4. Protocol Proposals and Highlights 232 The following proposals were submitted as proposals to the CAPWAP 233 working group. 235 [LWAPP] "Light Weight Access Point Protocol", Work in progress. 237 LWAPP was the first CAPWAP protocol orginally submitted to Seamoby 238 Working Group. LWAPP proposes original solutions for authentication, 239 user data encapsulation as well as management and configuration 240 information elements. LWAPP originated as a "Split MAC" protocol but 241 recent changes have added local MAC support as well. LWAPP has 242 received a security review from Charles Clancy of the University of 243 Maryland Information Systems Security Lab. 245 LWAPP is the most detailed CAPWAP proposal. It provides a thorough 246 specification of the discovery, security and system management 247 methods. LWAPP focuses on the 802.11 WLAN specific monitoring and 248 configuration. A key feature of LWAPP is it's use of raw 802.11 249 frames which are tunneled back to the AC for processing. In both 250 Local and Split MAC mode, raw 802.11 frames are forwarded to the AC 251 for management and control. In addition, in split-MAC mode, user 252 data is tunneled in raw 802.11 form to the AC. Although in concept, 253 LWAPP could be used for other wireless technologies, LWAPP defines 254 very few primitives that are independant of the 802.11 layer. 256 [SLAPP]"Secure Light Access Point Protocol", Work in progress. 258 SLAPP distinguishes itself with the use of well known, established 259 technologies such as GRE for user data tunneling between AC and WTP 260 and the proposed standard DTLS for the control channel transport. 262 Four modes of operation are supported, 2 local MAC modes and 2 split 263 MAC modes. STA control may be performed by the AC using native 264 802.11 frames which are encapsulated in SLAPP control packets across 265 all modes. 267 In SLAPP local MAC modes, user data frames may be bridged or tunneled 268 back using GRE to the AC as 802.3 frames. In the split-MAC modes, 269 user data is always tunneled back to the AC as native 802.11 frames. 270 Encryption of user data may be performed at either the AC or the WTP 271 in split-MAC mode. 273 [CTP]"CAPWAP Tunneling Protocol", Work in progress. 275 CTP distinguishes itself with its use of SNMP to define configuration 276 and management data which it then encapsulates in an encrypted 277 control channel. CTP was originally designed as a local MAC protocol 278 but the new version has split MAC support as well. In addition, CTP 279 is clearly designed from the beginning to be compatible with multiple 280 wireless technologies. 282 CTP defines information elements for management and control between 283 the AC and WTP. CTP control messages are specified for STA session 284 state, configuration and statistics. 286 In local MAC mode, CTP does not forward any native wireless frames to 287 the AC. CTP specifies control messages for STA session activity, 288 mobilitiy and RF resource management between the AC and WTP. CTP 289 local MAC mode specifies that the integration function from the 290 wireless network to 802.3 Ethernet is performed at the WTP for all 291 user data. User data may either be bridged at the WTP or 292 encapsulated as 802.3 frames in CTP packets at the WTP and tunneled 293 to the AC. 295 CTP's Split-MAC mode is defined as an extension to local-MAC mode. 296 In CTP's version of split-MAC operation, wireless management frames 297 are forwarded in their raw format to the AC. User data frames may be 298 bridged locally at the WTP, or they may be encapsulated in CTP 299 packets and tunneled in their native wireless form to the AC. 301 CTP supplies STA control abstraction, methods for extending the 302 forwarding of multiple types of native wireless management frames and 303 many options for user data tunneling. Configuration management is an 304 extension of SNMP. This makes CTP one of the most flexible of the 305 proposed CAPWAP protocols. However, it does define new security and 306 data tunneling mechanisms instead of leveraging existing standards. 308 [WICOP]"Wireless LAN Control Protocol", Work in progress. 310 The WiCoP protocol introduces new discovery, configuration and 311 management of WLAN systems. The protocol defines a distinct 312 discovery mechanism that integrates WTP-AC capabilities negotiation. 314 WiCoP defines 802.11 QoS parameters. In addition, the protocol 315 proposes to use standard security and authentication methods such as 316 IPSec and EAP. The protocol needs to go into detail with regards to 317 explicit use of the above mentioned methods. To assure interoperable 318 protocol implementations, it is critical to provide user with 319 detailed unambiguous specification. 321 5. Security Considerations 323 Each of the candidate protocols has a Security Considerations 324 section, as well as security properties. The CAPWAP Objectives 325 document contains security related requirements. The evaluation team 326 has considered if and how the candidate candidate protocols implement 327 the security features required by the CAPWAP objectives. However, 328 this evaluation team is not a security team and has not performed a 329 thorough security evaluation or tests. Any protocol coming out of 330 the CAPWAP working group must undergo a IETF security review in order 331 to fully meet the objectives. 333 6. Mandatory Objective Compliance Evaluation 335 6.1. Logical Groups 337 LWAPP:C, SLAPP:C, CTP:C, WiCoP:C 339 LWAPP 341 LWAPP provides a control message called "Add WLAN". This message is 342 used by AC to create a WLAN with a unique ID, i.e. its SSID. The 343 WTPs in this WLAN have their own BSSIDs. LWAPP meets this objective. 345 SLAPP 347 SLAPP explicitly supports 0-255 BSSID's. 349 CTP 351 CTP implements a NETWORK_ID attribute which allows a wireless 352 technology independant way of creating logical groups. CTP meets 353 this objective. 355 WiCoP 357 WiCoP provides control tunnels to manage logical groups. There is 358 one control tunnel for each logical group. WiCoP meets this 359 objective. 361 6.2. Traffic Separation 363 LWAPP:C, SLAPP:C, CTP:P, WiCoP:P 365 If a protocol distinguishes a data message from a control message, 366 then it meets this objective. 368 LWAPP 370 LWAPP separates control messages from data messages using "C-bit". 371 "C-bit" is defined in the LWAPP transport header. When C bit is 372 equal to zero, the message is a data message. When C bit is equal to 373 one, message is a control message. So, LWAPP meets this objective 375 SLAPP 377 The SLAPP protocol encapsulates control using DTLS and optionally, 378 user data with GRE. Of particular note, SLAPP defines 4 379 "architecture modes" which define how user data is handled in 380 relation to the AC. SLAPP is compliant with this objective. 382 CTP 384 CTP defines separate packet frame types for control and data. 385 However, the evaluation team could not find a way to configure the 386 tunneling of user data, so opted to rate CTP as only partially 387 compliant. It appears that CTP would rely on SNMP MIB OID's for this 388 function, but none were defined in the specification. Defining the 389 necessary OID's would make CTP fully compliant. 391 WiCoP 393 WiCoP provides for separation between control and data channels. 394 However, tunneling methods are not explicitly described. Because of 395 this, WiCoP partially meets this objective. 397 6.3. STA Transparency 399 LWAPP:C, SLAPP:C, CTP:C, WiCoP:C 401 If a protocol does not indicate that STA needs to know about the 402 protocol, then this objective is met. 404 The protocol must not define any message formats between STA and 405 WTP/AC. 407 LWAPP 409 LWAPP does not require a STA to be aware of LWAPP. No messages or 410 protocol primitives are defined that the STA must interact with 411 beyond the 802.11 standard. LWAPP is fully compliant. 413 SLAPP 415 SLAPP places no requirements on STA network elements. No messages or 416 protocol primitives are defined that the STA must interact with 417 beyond the 802.11 standard. 419 CTP 421 CTP does not require a terminal to know CTP. So, CTP meets this 422 objective. 424 WiCoP 426 WiCoP does not require a terminal to know WiCoP. So, WiCoP meets 427 this objective. 429 6.4. Configuration Consistency 431 LWAPP:C, SLAPP:C, CTP:C, WiCoP:C 433 Given the objective of maintaining configurations for a large number 434 of network elements involved in 802.11 wireless networks the 435 evaluation team would like to recommend that a token, key or serial 436 number for configuration be implemented for configuration 437 verification. 439 LWAPP 441 It is possible to obtain and verify all configurable values through 442 LWAPP. Notably, LWAPP takes an approach that only "non-default" 443 settings (defaults are specified by LWAPP) are necessary for 444 transmission when performing configuration consistency checks. This 445 behavior is explicitly specified in LWAPP. LWAPP is compliant with 446 this objective. 448 SLAPP 450 Numerous event and statistics are available to report config changes 451 and WTP state. SLAPP does not have any built in abilities to 452 minimize or optimize configuration consistency verification, but it 453 is compliant with the objective. 455 CTP 457 CTP's use of SNMP makes configuration consistency checking 458 straightfoward. Where specified in an a MIB, one could take 459 advantage of default values. 461 WICOP 463 The WiCoP configuration starts with exchange of capability messages 464 between WTP and AC. Next, configuration control data is sent to WTP. 466 WiCoP defines configuration values in groups of configuration data 467 messages. In addition, the protocol supports configuration using MIB 468 objects. To maintain data consistency each configuration message 469 from AC is acknowledged by WTP. 471 6.5. Firmware Trigger 473 LWAPP:P, SLAPP:P, CTP:P, WiCoP:C 475 The evaluation team considered the objective and determined that for 476 full compliance, the protocol state machine must support the ability 477 to initiate the process for checking and performing a firmware update 478 independantly of other functions. 480 Many protocols perform a firmware check and update procedure only on 481 system startup time. This method received a partial compliance. The 482 team believed that performing the firmware check only at startup time 483 was unnecessarily limiting and that allowing it to occur at any time 484 in the state machine did not increase complexity of the protocol. 485 Allowing the firmware update process to be initiated occur during the 486 running state allows more possibilities for minimizing downtime of 487 the WTP during the firmware update process. 489 For example, the firmware check and download of the image over the 490 network could potentially occur while the WTP was in a running state. 491 After the file transfer was complete, the WTP could be rebooted just 492 once and being running the new firmware image. This could pose a 493 meaningful reduction in downtime when the firmware image is large, 494 the link for loading the file is very slow or the WTP reboot time is 495 long. 497 A protocol would only fail compliance if it no method was specified 498 for updating of firmware. 500 LWAPP 502 Firmware download is initiated by the WTP only at the Join phase 503 (when a WTP is first associating with an AC) and not at any other 504 time. The firmware check and update could be "triggered" indirectly 505 by the AC by sending a reset message to the WTP. The resulting 506 reboot would cause a firmware check and update to be performed. 507 LWAPP is partially compliant because its firmware trigger can only be 508 used in the startup phases of the state machine. 510 SLAPP 512 SLAP{ includes a firmware check and update procedure which is 513 performed when a WTP is first connecting to an AC. The firmware 514 check and update can only be "triggered" indirectly by the AC by 515 sending a reset message to the WTP. SLAPP is partially compliant 516 because its firmware trigger can only be used in the startup phases 517 of the state machine. 519 CTP 521 The CTP state machine specifies that the firmware upgrade procedure 522 must be performed immediately after the authentication exchange as 523 defined in section 6.2 of [CTP]. However, section 5.2.5 of [CTP] 524 states that the SW-Update-Req message MAY be sent by the AC. This 525 indirectly implies that CTP could support an AC triggered software 526 update during the regular running state of the WTP. So it seems that 527 CTP might be fully compliant, but the proposal should be clarified 528 for full compliance. 530 WiCoP 532 In WiCoP, firmware update may be triggered any time in the active 533 state, so WiCoP is fully compliant. 535 6.6. Monitor and Exchange of System-wide Resource State 537 LWAPP:C, SLAPP:C, CTP:P, WiCoP:C 539 The evaluation team focused on the protocols supplying three methods 540 relevant to statistics from WTP's; The ability to transport 541 statistics, a minimum set of standard data and the ability to extend 542 what data could be reported or collected. 544 LWAPP 546 Statistics are sent by WTP using "Event Request" message. LWAPP 547 defines an 802.11 statistics message which covers 802.11 MAC layer 548 properties. LWAPP is compliant 550 SLAPP 552 WLAN statisitics transport is supplied via the control channel and 553 encoded in SLAPP defined TLV's called information elements. 802.11 554 configuration and statistics information elements are supplied in 555 [SLAPP] 6.1.3.1. These are extendable and include vendor specific 556 extensions. 558 CTP 560 CTP defines a control message called "CTP Stats-Notify". This 561 control message contains statistics in the form of SNMP OID's and is 562 sent from the WTP to AC. This approach is novel because it leverages 563 the use of standard SNMP. 565 [CTP] 5.3.10 reccommends the use of 802.11 MIBs where applicable. 566 However, the proposal acknowledges that additional configuration and 567 statistics information is required, but does not specify these MIB 568 extensions. CTP needs to add these extensions to the proposal. 569 Also, this minimum set of statistics and configuration OID's must 570 become requirements in order to fully meet the objective. 572 WiCoP 573 The feedback control message sent by WTP contains many statistics. 574 WiCoP specifies fifteen statistics WTP needs to send to AC. New 575 versions of WiCoP can address any new statistics AC needs to monitor 576 WTP. WiCoP meets this objective. 578 6.7. Resource Control 580 LWAPP:C, SLAPP:P, CTP:P, WiCoP:P 582 The evaluation team interpreted the resource control objective to 583 mean that the CAPWAP protocol must map 802.11e QoS markings to the 584 wired network. This mapping must include any encapsulation or 585 tunneling of user data defined by the CAPWAP protocol. Of particular 586 note, the evaluation team agreed that the CAPWAP protocol should 587 supply an explicit capability to configure this mapping. Since most 588 of the protocols relied only on the 802.11e statically defined 589 mapping, most received a partial compliance. 591 LWAPP 593 LWAPP defines it's own custom TLV structure which consists of an 8 594 bit type or class of information value and an additional 8 bit value 595 which indexes to a specific variable 597 LWAPP allows the mobile station based QoS configuration in each Add 598 Mobile Request sent by AC to WTP for each new mobile station that is 599 attached. Packet prioritization is left to individual WTPs. 4 600 different QoS policies for each station to enforce can be configured. 601 Update Mobile QoS message element can be used to change QoS policy at 602 the WTP for a given mobile station. LWAPP should support 8 QoS 603 policies as this matches 802.11e 802.1p and IP TOS, but for this 604 objective, 4 classes is compliant. 606 Overall, LWAPP conforms to the resource control objective. It 607 enables QoS configuration and mapping. The control can be applied on 608 a logical group basis and also enables the wireless traffic to be 609 flexibly mapped to the wired segment. 611 SLAPP 613 Although 802.11e specifies 802.1p and DSCP mappings, there is no 614 explicit support for 802.11e in SLAPP. SLAPP must be updated to add 615 802.11e as one of the standard capabilities that a WTP could support 616 and specify a mechanism which would allow configuration of mapping 617 the QoS classes. 619 CTP 620 CTP requires that the WTP and AC copy the QoS marking of user data to 621 the data message encapsulation. This mapping is accomplished by the 622 CTP Header's 1 byte policy field. However, no configuration of QoS 623 mapping other than copying the user data's already existing markings 624 is defined in CTP. It seems clear that SNMP could be used to 625 configure the mapping to occur differently, but no OID's are defined 626 which would enable this. Partial compliance is assigned to CTP for 627 this objective. 629 WiCoP 631 Note: WiCoP rating for Resource Control objective has been upgraded 632 from FAILED to PARTIAL. After an additional review of the WiCoP 633 protocol proposal, it was determined that the protocol partially 634 meats Resource control objectives. 636 WiCoP protocol starts its QoS configuration with 802.11e capability 637 exchange between WTP and AC. The QoS capabilities primitives are 638 included in the capability messages. 640 WiCoP defines the QoS-Value message which contains 802.11e 641 configuration parameters. This is sent for each group supported by 642 WTP. WiCoP does not provide an explicit method for configuration of 643 DSCP tags and 802.1P precedence values. It is possible to configure 644 these parameters through SNMP OID configuration method, but WiCoP 645 does not explicitly identify any specific MIBs. Overall, WiCoP 646 partially meets resource control CAPWAP objects. In order to be 647 fully compliant with the given objective, the protocol needs to 648 identify a clear method to configure 802.1p and DSCP mappings. 650 6.8. Protocol Security 652 LWAPP:C, SLAPP:C, CTP:F, WiCoP:F 654 For the purposes of the protocol security objective, the evaluation 655 team primarily considered whether or not the candidate protocols 656 implement the security features required by the CAPWAP objectives. 657 Please refer to the security considerations section of this document. 659 LWAPP 661 It appears that the security mechanisms, including the key management 662 portions in LWAPP are correct. One third party security review has 663 been performed. However, further security review is warranted since 664 a CAPWAP specific key exchange mechanism is defined. LWAPP is 665 compliant with the objective 667 SLAPP 668 The SLAPP protocol implements authentication of the WTP by the AC 669 using the DTLS protocol. This behavior is defined in both the 670 discovery process and the 802.11 control process. SLAPP allows 671 mutual and asymmetric authentication. SLAPP also gives informative 672 examples of how to properly use the authentication. SLAPP should add 673 another informative example for authentication of the AC by the WTP. 674 SLAPP is compliant with the objective. 676 CTP 678 The original presentation at IETF63 of the preliminary findings of 679 the evaluation team reported that CTP failed this objective. This 680 was on the basis of asymmetric authentication not being supported by 681 CTP. This was due to a misunderstanding of what was meant by 682 asymmetric authentication by the evaluation team. The definitions of 683 the terminology used in [OBJ] were clarified on the CAPWAP mailing 684 list. CTP in fact does implement a form of asymmetric authentication 685 through the use of public keys. 687 However, CTP still fails to comply with the objective for two 688 reasons: 690 First, CTP does not mutually derive session keys. Second, CTP does 691 not perform explicit mutual authentication because the two parties 692 authenticating do not confirm the keys. 694 WiCoP 696 There is not enough specific information to implement WiCOP protocol 697 security features. While in concept EAP and IPSec make sense, there 698 is no explicit description on how these methods would be used. 700 6.9. System-Wide Security 702 LWAPP:C, SLAPP:C, CTP:F, WiCoP:F 704 LWAPP 706 LWAPP wraps all control and management communication in it's 707 authenticated and encrypted control channel. LWAPP does not seem 708 particularly vulnerable to DoS. LWAPP should make a recommendation 709 that the join method be throttled to reduce the impact of DOS attacks 710 against it. Use of an established security mechanism such as IPSec 711 would be preferred. However, LWAPP's independant security review 712 lended enough confidence to declare LWAPP compliant with the 713 objective. 715 SLAPP 716 SLAPP is compliant due to wrapping all control and management 717 communication in DTLS. SLAPP also recommends measures to protect 718 against discovery request DOS attacks. DTLS has undergone security 719 review and has at least one known implementation outside of SLAPP. 720 At the time of this writing, DTLS is pending proposed standard status 721 in the IETF. 723 CTP 725 CTP introduces a new, unestablished mechanism for AC to WTP 726 authentication. For complete compliance, use of an established 727 security mechanism with detailed specifications for it's use in CTP 728 is preferred. Alternatively a detailed security review could be 729 performed. CTP does not point out or recommend or specify any DoS 730 attack mitigation requirements against Reg-Req and Auth-Req floods, 731 such as a rate limiter. Because CTP received an 'F' on it's protocol 732 security objective, it follows that system-wide security must also be 733 rated 'F'. 735 WiCoP 737 WiCop does not address DoS attack threats. Also, as with the 738 protocol security objective, the protocol needs to explicitly 739 describe its tunnel and authentication methods. 741 6.10. 802.11i Considerations 743 LWAPP:C, SLAPP:C, CTP:F, WiCoP:P 745 LWAPP 747 LWAPP explicitly defines mechanisms for handling 802.11i in it's 748 modes with encryption terminated at the WTP. In order to accomplish 749 this, the AC sends the PTK using the encrypted control channel to the 750 WTP using the Add Mobile message. When encryption is terminated at 751 the AC, there are no special requirements. LWAPP is compliant. 753 SLAPP 755 SLAPP defines a control message to send the PTK and GTK to the WTP 756 when the WTP is the encryption endpoint. This control message is 757 carried on the DTLS protected control channel. SLAPP is compliant. 759 CTP 761 CTP lacks a specification for a control message to send 802.11i PTK 762 and GTK keys to a WTP when the WTP is an encryption endpoint. Based 763 on this, CTP fails compliance for this objective. This requirement 764 could be addressed either by defining new control channel information 765 elements or by simply defining SNMP OID's. The transport of these 766 OID's would be contained in the secure control channel and therefore 767 protected. 769 WiCoP 771 WiCoP lacks documentation in the draft on how to handle 4 way 772 handshake. The case for encryption at the AC needs clarification. 774 6.11. Interoperability 776 LWAPP:C, SLAPP:C, CTP:C, WiCoP:C 778 LWAPP 780 LWAPP supports both split and local mac architectures and is 781 therefore compliant to the letter of the objectives. LWAPP is 782 particularly rich in its support of the split-mac architecture. 783 However, LWAPP's support of Local-MAC is somewhat limited and could 784 be expanded. LWAPP is lacking a mode which allows Local MAC data 785 frames to be tunneled back to the AC. A discussion of possible 786 extensions and issues is discussed in the recommendations section of 787 this evaluation. 789 SLAPP 791 SLAPP is compliant. 793 CTP 795 CTP is compliant. 797 WiCoP 799 WiCoP is compliant. 801 6.12. Protocol Specifications 803 LWAPP:C, SLAPP:P, CTP:P, WiCoP:P 805 LWAPP 807 LWAPP is nearly fully documented. Only a few sections are noted as 808 incomplete. Detailed descriptions are often given to explain the 809 purpose of the protocol primitives defined which should encourage 810 interoperable implementations. 812 SLAPP 814 SLAPP is largely implementable from it's specification. It contains 815 enough information to perform an interoperable implementation for 816 it's basic elements, however additional informative references or 817 examples should be provided covering use of information elements, 818 configuring multiple logical groups, etc. 820 CTP 822 As noted earlier, there are a few areas where CTP lacks a complete 823 specification, primarily due to the lack of specific MIB definitions. 825 WiCoP 827 Due to the lack of specific tunnel specifications and authentication 828 specifications, WiCoP is only partially compliant. 830 6.13. Vendor Independence 832 LWAPP:C, SLAPP:C, CTP:C, WiCoP:C 834 LWAPP 836 LWAPP is compliant. 838 SLAPP 840 SLAPP is compliant. 842 CTP 844 CTP is compliant. 846 WiCoP 848 WiCoP is compliant. 850 6.14. Vendor Flexibility 852 LWAPP:C, SLAPP:C, CTP:C, WiCoP:C 854 LWAPP 856 LWAPP is compliant. 858 SLAPP 859 SLAPP is compliant. 861 CTP 863 CTP is compliant. 865 WiCoP 867 WiCoP is compliant. 869 6.15. NAT Traversal 871 LWAPP:C, SLAPP:C, CTP:C, WiCoP:C 873 LWAPP 875 LWAPP may require special considerations due to it carrying the IP 876 address of the AC and data termination points in the payload of 877 encrypted control messages. To overcome NAT, static NAT mappings may 878 need to be created at the NAT'ing device if the AC or data 879 termination points addresses are translated from the point of view of 880 the WTP. A WTP should be able function in the hidden address space 881 of a NAT'd network. 883 SLAPP 885 SLAPP places no out of the ordinary constraints regarding NAT. A WTP 886 could function in the hidden address space of a NAT'd network without 887 any special configuration. 889 CTP 891 CTP places no out of the ordinary constraints regarding NAT. A WTP 892 could function in the hidden address space of a NAT'd network without 893 any special configuration. 895 WiCoP 897 WiCoP places no out of the ordinary constraints regarding NAT. A WTP 898 could function in the hidden address space of a NAT'd network without 899 any special configuration. 901 7. Desirable Objective Compliance Evaluation 903 7.1. Multiple Authentication 905 LWAPP:C, SLAPP:C, CTP:C, WiCoP:C 907 LWAPP 909 LWAPP allows for multiple STA authentication mechanisms. 911 SLAPP 913 SLAPP does not constrain other authentication techniques for being 914 deployed. 916 CTP 918 CTP supports multiple STA authentication mechanisms. 920 WiCoP 922 WiCoP allows for multiple STA authentication mechanisms. 924 7.2. Future Wireless Technologies 926 LWAPP:C, SLAPP:C, CTP:C, WiCoP:C 928 LWAPP 930 LWAPP could be used for other wireless technologies. However, LWAPP 931 defines very few primitives that are independant of the 802.11 layer. 933 SLAPP 935 SLAPP could be used for other wireless technologies. However, SLAPP 936 defines very few primitives that are independant of the 802.11 layer. 938 CTP 940 CTP supplies STA control abstraction, methods for extending the 941 forwarding of multiple types of native wireless management frames and 942 many options for user data tunneling. Configuration management is an 943 extension of SNMP, for which new MIB's could in concept, be easily 944 plugged in. This helps makes CTP a particularly flexible proposal 945 for supporting future wireless technologies. In addition, CTP has 946 already defined multiple wireless protocol types in addition to 947 802.11. 949 WiCoP 951 WiCoP could be used for other wireless technologies. 953 7.3. New IEEE Requirements 955 LWAPP:C, SLAPP:C, CTP:C, WiCoP:C 957 LWAPP 959 LWAPP's extensive use of native 802.11 frame forwarding allows it to 960 be transparent to many 802.11 changes. It however shifts the burden 961 of adapting MAC layer changes to the packet processing capabilities 962 of the AC. 964 SLAPP 966 SLAPP's use of native 802.11 frames for control and management allow 967 SLAPP a measure of transparency to changes in 802.11. Because SLAPP 968 also supports a mode which tunnels user data as 802.3 frames, it has 969 additonal architectural options for adapting to changes on the 970 wireless infrastructure. 972 CTP 974 CTP has perhaps the greatest ability to adapt to changes in IEEE 975 requirements. Architecturally speaking, CTP has several options 976 available for adapting to change. SNMP OID's are easily extended for 977 additional control and management functions. Native wireless frames 978 can be forwarded directly to the AC if necessary. Wireless frames 979 can be bridged to 802.3 frames and tunneled back to the AC to protect 980 the AC from changes at the wireless MAC layer. These options allow 981 many possible ways to adapt to change of the wireless MAC layer. 983 WiCoP 985 Because WiCoP uses 802.11 frames for the data transport, it is 986 transparent to most IEEE changes. Any new IEEE requirements may need 987 new configuration and new capability messages between WTP and AC. 988 The AC would need to be modified to handle new 802.11 control and 989 management frames. 991 7.4. Interconnection (IPv6) 993 LWAPP:C, SLAPP:C, CTP:C, WiCoP:C 995 LWAPP 996 LWAPP explicitly defines measures for accomodating IPv6. LWAPP is 997 more sensitive to this in part because it carries IP addresses in two 998 control messages. 1000 SLAPP 1002 SLAPP is transparent to the interconnection layer. DTLS and GRE will 1003 both operate over IPv6. 1005 CTP 1007 CTP is transparent to the interconnection layer. CTP should be able 1008 to operate over IPv6 without any changes. 1010 WiCoP 1012 WiCoP is transparent to the interconnection layer and should be able 1013 to operate over IPv6 without changes. 1015 7.5. Access Control 1017 LWAPP:C, SLAPP:C, CTP:C, WiCoP:C 1019 LWAPP 1021 LWAPP uses native 802.11 management frames forwarded to the AC for 1022 the purpose of performing STA access control. WTP's are 1023 authenticated in LWAPP's control protocol Join phase. 1025 SLAPP 1027 SLAPP has support for multiple authentication methods for WTP's. In 1028 addition, SLAPP can control STA access via 802.11 management frames 1029 forwarded to the AC or via SLAPP's information element primitives. 1031 CTP 1033 CTP specifies STA access control primitives. 1035 WiCoP 1037 WiCoP specifies access control in [WICOP] section 5.2.2. 1039 8. Evaluation Summary and Conclusions 1041 See Figure 1. 1043 --------------------------------------------------------------- 1044 | CAPWAP Evaluation | LWAPP | SLAPP | CTP | WiCoP | 1045 ---------------------------------------------------------------| 1046 | 5.1.1 Logical Groups | C | C | C | C | 1047 | 5.1.2 Traffic Separation | C | C | P | P | 1048 | 5.1.3 STA Transparency | C | C | C | C | 1049 | 5.1.4 Config Consistency | C | C | C | C | 1050 | 5.1.5 Firmware Trigger | P | P | P | C | 1051 | 5.1.6 Monitor System | C | C | P | C | 1052 | 5.1.7 Resource Control | C | P | P | P | 1053 | 5.1.8 Protocol Security | C | C | F | F | 1054 | 5.1.9 System Security | C | C | F | F | 1055 | 5.1.10 802.11i Consideration | C | C | F | P | 1056 |---------------------------------------------------------------| 1057 | 5.1.11 Interoperability | C | C | C | C | 1058 | 5.1.12 Protocol Specifications | C | P | P | P | 1059 | 5.1.13 Vendor Independence | C | C | C | C | 1060 | 5.1.14 Vendor Flexibility | C | C | C | C | 1061 | 5.1.15 NAT Traversal | C | C | C | C | 1062 |---------------------------------------------------------------| 1063 | Desirable | 1064 |---------------------------------------------------------------| 1065 | 5.2.1 Multiple Authentication | C | C | C | C | 1066 | 5.2.2 Future Wireless | C | C | C | C | 1067 | 5.2.3 New IEEE Requirements | C | C | C | C | 1068 | 5.2.4 Interconnection (IPv6) | C | C | C | C | 1069 | 5.2.5 Access Control | C | C | C | C | 1070 --------------------------------------------------------------- 1072 Figure 1: Summary Results 1074 9. Protocol Recommendation 1076 The proposals presented offer a variety of novel features which 1077 together would deliver a full featured, flexible and extensible 1078 CAPWAP protocol. The most novel of these features leverage existing 1079 standards where feasable. It is this evaluation team's opinion that 1080 a mix of the capabilities of the proposals will produce the best 1081 CAPWAP protocol. 1083 The recommended features are described below. Many of these novel 1084 capabilities come from CTP and SLAPP and WiCoP. However, LWAPP has 1085 the most complete base protocol and is flexible enough to be extended 1086 or modified by the working group. We therefore recommend LWAPP be 1087 used as the basis for the CAPWAP protocol. 1089 The evaluation team recommends that the working group carefully 1090 consider the following issues and recommended changes. The 1091 evaluation team believes that a more complete CAPWAP protocol will be 1092 delivered by addressing these issues and changes. 1094 9.1. High priority recommendations relevant to mandatory objectives 1096 9.1.1. Information Elements 1098 LWAPP's attribute value pair system meets the objectives as defined 1099 by the working group. However, it has only 8 bits assigned for 1100 attribute types, with an additional 8 bits for a specific element 1101 within a attribute type. The evaluation team strongly recommends 1102 that a larger number of bits be assigned for attribute types and 1103 information elements. 1105 9.1.2. Control Channel Security 1107 LWAPP's security mechanisms appear satisfactory and could serve 1108 CAPWAP going forward. However, the evaluation team recommends 1109 adoption of a standard security protocol for the control channel. 1111 There are several motivations for a standards based security 1112 protocol, but the primary disadvantage of a new security protocol is 1113 that it will take longer and be more difficult to standardize than 1114 reusing an existing IETF standard. First, a new security protocol 1115 will face a longer, slower approval processes from the Security Area 1116 Directorate and the IESG. The new CAPWAP security protocol will need 1117 to pass several tests including: 1119 What is uniquely required by CAPWAP that is not available from an 1120 existing standard protocol? How will CAPWAP's security protocol meet 1121 security area requirements for extensibility, such as the ability to 1122 support future cipher suites and new key exchange methods? How does 1123 this ability compare to established security protocols which have 1124 these capabilities? 1126 Points such as these are continually receiving more attention in the 1127 industry and in the IETF. Extensibility of key exchange methods and 1128 ciper suites are becoming industry standard best practices. These 1129 issues are important topics in the IETF Security Area Advisory Group 1130 (SAAG) and the recent SecMech BOF. 1132 These issues could be nullified by adopting an appropriate existing 1133 standard security protocol. IPsec or DTLS could be a standards 1134 alternative to LWAPP's specification. DTLS presents a UDP variant of 1135 TLS. Although DTLS is relatively new, TLS is a heavily used, tried 1136 and tested security protocol. 1138 The evaluation team recommends that whatever security protocol is 1139 specified for CAPWAP, that it's use cases must be described in 1140 detail. LWAPP does a good job of this with it's proposed, 1141 proprietary method. If an updated specification is developed, it 1142 should contain at least one mandatory authentication and cipher 1143 method. For example, pre-shared key and x.509 certificates could be 1144 specified as mandatory authentication methods and AES CCMP could be 1145 selected as a mandatory cipher. 1147 Given the possibilities for code reuse, industry reliance on TLS and 1148 the future for TLS, DTLS may be a wise alternative to a security 1149 method specific to CAPWAP. In addition, use of DTLS would likely 1150 expidite the approval of CAPWAP as a proposed standard over the use 1151 of CAPWAP specific security mechanisms. 1153 9.1.3. Data Tunneling Modes 1155 9.1.3.1. Support for Local MAC User Data Tunneling 1157 The issue of data encapsulation is closely related to the Split and 1158 Local MAC architectures. The Split MAC architecture requires some 1159 form of data tunneling. All the proposals except LWAPP offer a 1160 method of tunneling in Local MAC mode as well. By Local MAC data 1161 tunneling, we mean the tunneling of user data as 802.3 Ethernet 1162 frames back to the AC from a WTP which is otherwise in Local MAC 1163 mode. 1165 Tunneling data in Local MAC mode offers the ability for implementors 1166 to innovate in several ways even while using a Local MAC 1167 architecture. For example, functions such as mobility, flexible user 1168 data encryption options, fast handoffs can be enabled through 1169 tunneling of user data back to an AC, or as LWAPP defines, a data 1170 termination endpoint, which could be different than the AC. In 1171 addition, special QoS or application aware treatments of user data 1172 packets such as voice or video. Improved transparency and 1173 compatibility with future wireless technologies are also possible 1174 when encapsulating user data in a common format, such as 802.3, 1175 between the access point and the AC or other termination point in the 1176 network. 1178 Another possibility is when a native wireless MAC changes in the 1179 future, if a new WTP which supports this MAC change can also support 1180 a wireless MAC -> 802.3 integration function, then the wireless MAC 1181 layer change may remain transparent to an AC and still maintain many 1182 of the benefits that data tunneling can bring. 1184 LWAPP does support a header for tunneled user data which contains 1185 layer 1 wireless information (RSSI and SNR) that is independant of 1186 the wireless layer 2 MAC. Innovations related to the use of RSSI and 1187 SNR at the AC may be retained even when tunneling 802.3 user data 1188 across different wireless MAC's. 1190 It is likely many other features could be created by innovative 1191 implementors using this method. However, LWAPP narrowly defines the 1192 Local MAC architecture to exclude an option of tunneling data frames 1193 back to the AC. Given the broad support for tunneling 802.3 data 1194 frames between WTP and AC across all the proposals and existing 1195 proprietary industry implementations, the evaluation team strongly 1196 recommends the working group consider a data tunneling mode for Local 1197 MAC be added to the LWAPP proposal and become part of the standard 1198 CAPWAP protocol. 1200 9.1.3.2. Mandatory and Optional Tunneling Modes 1202 If more than one tunneling mode is part of the CAPWAP protocol the 1203 evaluation team recommends that the working group choose one method 1204 as mandatory and other methods as optional. In addition, the CAPWAP 1205 protocol must implement the ability to negotiate which tunneling 1206 methods are supported through a capabilities exchange. This allows 1207 AC's and WTP's freedom to implement a variety of modes but always 1208 have the option of falling back to a common mode. 1210 The choice of which mode(s) should be mandatory is an important 1211 decision and may impact many decisions an implementor has to make 1212 with their hardware and software choices for both WTP's and AC's. 1213 The evaluation team believes the working group should address this 1214 issue of Local MAC data tunneling and carefully choose which mode(s) 1215 should be mandatory. 1217 9.2. Additional Recommendations Relevant to Desirable Objectives 1219 9.2.1. Access Control 1221 Abstraction of STA access control, such as that implemented in CTP 1222 and WiCoP, stands out as a valuable feature as it is fundamental to 1223 the operational capabilities of many types of wireless networks, not 1224 just 802.11. LWAPP implements station access control as a 802.11 1225 specific function via forwarding of 802.11 control frames to the 1226 access controller. LWAPP has abstracted the STA Delete function out 1227 of the 802.11 binding. However, the Add STA function is part of the 1228 802.11 binding. It would be useful to implement the wireless MAC 1229 independant functions for adding a STA outside of the 802.11 binding. 1231 9.2.2. Removal of Layer 2 Encapsulation for Data Tunneling 1233 LWAPP currently specifies layer 2 and layer 3 methods for data 1234 tunneling. The evaluation team believes the layer 2 method is 1235 redundant to the layer 3 method. The team recommends the layer 2 1236 method encapsulation be removed from the LWAPP protocol. 1238 9.2.3. Data Encapsulation Standard 1240 LWAPP's layer 3 data encapsulation meet's the working group 1241 objectives. However, The evaluation team recommends the use of a 1242 standards based protocol for encapsulation of user data between the 1243 WTP and AC. GRE or L2TP could make good candidates as standards 1244 based encapsulation protocols for data tunneling. 1246 Using a standard gives the opprotunity for code reuse, whether it is 1247 off-the-shelf microcode for processors, code modules that can be 1248 purchased for real time operating systems, or open-source 1249 implementations for Unix based systems. In addition, L2TP and GRE 1250 are designed to encapsulate multiple data types, increasing 1251 flexibility for supporting future wireless technologies. 1253 10. References 1255 [ARCH] Yang, L., Zerfos, P., and E. Sadot, "Architecture Taxonomy 1256 for Control and Provisioning of Wireless Access 1257 Points(CAPWAP)", November 2004. 1259 [CTP] Singh , I., Francisco, P., Pakulski , K., and F. Backes , 1260 "CAPWAP Tunneling Protocol (CTP)", April 2005. 1262 [LWAPP] Calhoun, P., O'Hara, B., Kelly, S., Suri, R., Williams, 1263 M., Hares, S., and N. Cam Winget, "Light Weight Access 1264 Point Protocol (LWAPP)", March 2005. 1266 [OBJ] Govindan, S., Yao, ZH., Zhou, WH., Yang, L., and H. Cheng, 1267 "Objectives for Control and Provisioning of Wireless 1268 Access Points (CAPWAP)", June 2005. 1270 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1271 Requirement Levels", RFC 2119, March 1997. 1273 [RFC3127] Mitton, D., St.Johns, M., Barkley, S., Nelson, D., Patil, 1274 B., Stevens, M., and B. Wolff, "Authentication, 1275 Authorization, and Accounting: Protocol Evaluation", 1276 RFC 3127, June 2001. 1278 [SLAPP] Narasimhan, P., Harkins, D., and S. Ponnuswamy, "SLAPP : 1279 Secure Light Access Point Protocol", May 2005. 1281 [WICOP] Iino, S., Govindan, S., Sugiura, M., and H. Cheng, 1282 "Wireless LAN Control Protocol (WiCoP)", March 2005. 1284 Authors' Addresses 1286 Darren P. Loher 1287 Roving Planet, Inc. 1288 7237 Church Ranch Blvd. 1289 Westminster, CO 80021 1290 USA 1292 Phone: +1.303.996.7560 1293 Email: dloher@rovingplanet.com 1295 David B. Nelson 1296 Enterasys Networks, Inc. 1297 50 Minuteman Road 1298 Anover, MA 01810-1008 1299 USA 1301 Phone: +1.978.684.1330 1302 Email: dnelson@enterasys.com 1304 Oleg Volinsky 1305 Colubris Networks, Inc. 1306 200 West Street 1307 Waltham, MA 02451 1308 USA 1310 Phone: +1.781.547.0329 1311 Email: ovolinsky@colubris.com 1313 Behcet Sarikaya 1314 UNBC 1315 Computer Science Dept. 1316 3333 University Way 1317 Prince George, BC V2N 4Z9 1318 Canada 1320 Phone: +1.250.960.5551 1321 Email: sarikaya@ieee.org 1323 Intellectual Property Statement 1325 The IETF takes no position regarding the validity or scope of any 1326 Intellectual Property Rights or other rights that might be claimed to 1327 pertain to the implementation or use of the technology described in 1328 this document or the extent to which any license under such rights 1329 might or might not be available; nor does it represent that it has 1330 made any independent effort to identify any such rights. Information 1331 on the procedures with respect to rights in RFC documents can be 1332 found in BCP 78 and BCP 79. 1334 Copies of IPR disclosures made to the IETF Secretariat and any 1335 assurances of licenses to be made available, or the result of an 1336 attempt made to obtain a general license or permission for the use of 1337 such proprietary rights by implementers or users of this 1338 specification can be obtained from the IETF on-line IPR repository at 1339 http://www.ietf.org/ipr. 1341 The IETF invites any interested party to bring to its attention any 1342 copyrights, patents or patent applications, or other proprietary 1343 rights that may cover technology that may be required to implement 1344 this standard. Please address the information to the IETF at 1345 ietf-ipr@ietf.org. 1347 Disclaimer of Validity 1349 This document and the information contained herein are provided on an 1350 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1351 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1352 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1353 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1354 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1355 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1357 Copyright Statement 1359 Copyright (C) The Internet Society (2005). This document is subject 1360 to the rights, licenses and restrictions contained in BCP 78, and 1361 except as set forth therein, the authors retain all their rights. 1363 Acknowledgment 1365 Funding for the RFC Editor function is currently provided by the 1366 Internet Society.