idnits 2.17.1 draft-francisco-capwap-ctp-evaluation-01.txt: -(275): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(531): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(564): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(671): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(674): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 736. ** 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. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(A) Disclaimer.) ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(B) IPR Disclosure Invitation.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 11 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 10 longer pages, the longest (page 11) being 66 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 == Line 120 has weird spacing: '...xchange infor...' == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- 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 (June 2005) is 6890 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) == Outdated reference: A later version (-02) exists of draft-singh-capwap-ctp-01 -- Possible downref: Normative reference to a draft: ref. '2' ** Downref: Normative reference to an Informational draft: draft-ietf-capwap-problem-statement (ref. '3') == Outdated reference: A later version (-04) exists of draft-ietf-capwap-objectives-02 ** Downref: Normative reference to an Informational draft: draft-ietf-capwap-objectives (ref. '4') == Outdated reference: A later version (-04) exists of draft-ohara-capwap-lwapp-02 ** Downref: Normative reference to an Historic draft: draft-ohara-capwap-lwapp (ref. '5') Summary: 11 errors (**), 0 flaws (~~), 9 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Operations Group I. Singh 2 Internet Draft P. Francisco 3 Expires: December 2005 M. Montemurro 4 Chantry Networks 5 June 2005 7 Evaluation of CAPWAP Tunneling Protocol (CTP) 8 draft-francisco-capwap-ctp-evaluation-01.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on December 8, 2005. 35 Copyright Notice 37 Copyright (C) The Internet Society (2005). 39 Abstract 41 This document presents a self evaluation of the CAPWAP Tunneling 42 Protocol (CTP) with respect to the requirements presented in the 43 CAPWAP Objectives draft. This work is to aid in the official working 44 group evaluation of the candidate protocols for CAPWAP. 46 Table of Contents 48 1. Definitions....................................................3 49 1.1 Conventions used in this document..........................3 50 2. Introduction...................................................3 51 3. Objectives Responses...........................................3 52 3.1 Mandatory and Accepted Objectives..........................3 53 3.1.1 Logical Groups........................................3 54 3.1.2 Support for Traffic Separation........................3 55 3.1.3 Wireless Terminal Transparency........................4 56 3.1.4 Configuration Consistency.............................4 57 3.1.5 Firmware Trigger......................................4 58 3.1.6 Monitoring and Exchange of System-wide Resource State.5 59 3.1.7 Resource Control Objective............................5 60 3.1.8 CAPWAP Protocol Security..............................6 61 3.1.9 System-wide Security..................................6 62 3.1.10 IEEE 802.11i Considerations..........................7 63 3.1.11 Interoperability Objective...........................7 64 3.1.12 Protocol Specifications..............................8 65 3.1.13 Vendor Independence..................................8 66 3.1.14 Vendor Flexibility...................................9 67 3.1.15 NAT Traversal........................................9 68 3.2 Desirable Objectives.......................................9 69 3.2.1 Multiple Authentication Mechanisms....................9 70 3.2.2 Support for Future Wireless Technologies.............10 71 3.2.3 Support for New IEEE Requirements....................10 72 3.2.4 Interconnection Objective............................10 73 3.2.5 Access Control.......................................11 74 3.3 Non-objectives............................................11 75 3.3.1 Support for Non-CAPWAP WTPs..........................11 76 3.3.2 Technical Specifications.............................11 77 3.4 Operator Requirements.....................................12 78 3.4.1 AP Fast Handoff......................................12 79 4. Compliance Table..............................................12 80 5. Security considerations.......................................13 81 6. References....................................................13 82 7. Author's Addresses............................................13 83 Intellectual Property and Copyright Statements ...............13 85 1. 86 Definitions 88 1.1 89 Conventions used in this document 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in RFC-2119 [1] 95 2. 96 Introduction 98 The authors of the CAPWAP Tunneling Protocol(CTP) [2] believe that 99 CTP provides a robust solution in the form of a protocol that 100 addresses the issues raised in the CAPWAP Problem Statement draft 101 [3]. CTP can be run over an L2 or an L3 network and it is extensible 102 to support WTPs which terminate other radio technologies than IEEE 103 802.11. 105 Given below is a brief analysis of the protocol with respect to the 106 objectives draft [4] that has been presented and discussed in the WG. 108 3. 109 Objectives Responses 110 3.1 111 Mandatory and Accepted Objectives 113 3.1.1 114 Logical Groups 115 The ability to control and manage physical WTPs in terms of logical 116 groups. 118 3.1.1.1 119 Protocol Evaluation 120 The CTP protocol allows the AP and WTP to exchange information on 121 logical groups as part of the capabilities exchange 122 (CTP_CAP_REQ/RESP). The AC uses this information to provision logical 123 groups on the WTP as part of the configuration transaction. 124 The CTP header in the control and data messages provides a mechanism 125 to segment traffic between logical groups. 127 3.1.1.2 128 Compliance 129 CTP is compliant with this objective. 131 3.1.2 132 Support for Traffic Separation 133 This objective pertains to the need to maintain separation of control 134 and data traffic in the operation of the protocol. 136 3.1.2.1 137 Protocol Evaluation 138 CTP provides specific message types control and data traffic. CTP 139 data traffic can either be tunneled to the AC or bridged locally at 140 the WTP. Control traffic will always travel between the AC and the 141 WTP. 143 3.1.2.2 144 Compliance 145 CTP is compliant with this objective. 147 3.1.3 148 Wireless Terminal Transparency 149 This objective specifies the need for the protocol to be client 150 agnostic. That is, the wireless terminals need not be aware of the 151 existence of the CAPWAP protocol running underneath. 153 3.1.3.1 154 Protocol Evaluation 155 CTP defines a protocol for the provisioning and control of WTPs. The 156 protocol is agnostic to wireless MAC technology and entirely 157 transparent to a wireless terminal. Shipping products using CTP 158 demonstrate that this protocol does not have any adverse effects, 159 interoperability or otherwise, on the wireless terminals. 161 3.1.3.2 162 Compliance 163 CTP is compliant with this objective. 165 3.1.4 166 Configuration Consistency 167 This objectives pertains to the protocol�s ability to provide 168 consistent configuration state information of the WTPs at the AC. 170 3.1.4.1 171 Protocol Evaluation 172 CTP defines a configuration transaction where the AC can exchange 173 configuration with the WTP. The mechanism uses an SNMP data payload 174 encapsulated inside a CTP frame. The WTP must acknowledge the 175 configuration update to confirm that the configuration state on the 176 WTP is synchronized with the AC. 178 The protocol makes use of the SNMP MIB that is defined in the IEEE 179 802.11 standard and its amendments. This provides a generic mechanism 180 for configuration which is agnostic to wireless technologies and 181 updates to wireless standards. 183 3.1.4.2 184 Compliance 185 CTP is compliant with this objective. 187 3.1.5 188 Firmware Trigger 189 This objective states that the protocol must have the ability to 190 trigger WTP firmware updates. It does not necessarily state the need 191 for the protocol to integrate a software update mechanism within the 192 protocol itself. 194 3.1.5.1 195 Protocol Evaluation 196 After the device capability exchange phase (CTP-CAP_REQ/RESP) which 197 allows for the identification of the type of WTP connecting, CTP 198 protocol specifies a phase of firmware image validation (CTP- 199 Software-upgrade-req/resp, section 5.1.5) where the WTP indicates the 200 version of its firmware to the Controller. The controller can 201 evaluate the version of the WTP software and signal the WTP to update 202 its image. CTP does not specify the actual method for firmware 203 upgrade, but rather assumes the application of standardized binary 204 transport protocols (FTP/TFTP). 206 3.1.5.2 207 Compliance 208 CTP is compliant with this objective. 210 3.1.6 211 Monitoring and Exchange of System-wide Resource State 212 This objective states that the protocol must incorporate the ability 213 for the WTP to send statistics, congestion indications and other 214 pertinent wireless state information to the AC. 216 3.1.6.1 217 Protocol Evaluation 218 CTP protocol defines frames for the periodic exchange of a WTP�s 219 operational statistics (CTP-Stats-req/resp, CTP-Stats-Notify, Section 220 5.2.7-9). The protocol uses an SNMP format for the statistics based 221 on MIB definitions from the 802.11 standard and its amendments. This 222 protocol mechanism is agnostic to wireless technology and updates to 223 existing wireless standards. 225 3.1.6.2 226 Compliance 227 CTP is compliant with this objective. 229 3.1.7 230 Resource Control Objective 231 This objective pertains to the ability of the protocol to provide a 232 mapping mechanism of the IEEE 802.11e QOS priorities across the 233 wireless and wired infrastructure. 235 3.1.7.1 236 Protocol Evaluation 237 CTP defines a two tiered mechanism for QoS that addresses the 238 switching segment as well as the wireless medium. The QoS strategy 239 for the protocol involves mapping the QoS marking of the data frame 240 to the CTP frame. 242 Across the switched segment, CTP is an IP protocol that provides 243 several mechanisms to ensure the preservation of QoS markers within 244 the original data packet. The protocol header (CTP Section 4.1) 245 natively defines an 8-bit field for relaying of QoS policy related 246 information in a transport independent manner. Alternatively, CTP 247 could use 802.1p tagging to preserve QoS across the switched segment. 248 This allows the WTP and Controller to classify and guarantee the 249 preservation of QoS across the switched network. 251 CTP makes use of the 802.11e standard to preserve QoS across the 252 wireless medium. The mapping for QoS data frames to 802.11e QoS 253 frames is defined in the 802.11e amendment to the 802.11 standard. 255 3.1.7.2 256 Compliance 257 CTP is compliant with this objective. 259 3.1.8 260 CAPWAP Protocol Security 261 This objective concerns the security of the CAPWAP protocol. The 262 protocol must support mutual authentication of the WTP and the AC and 263 the communication channel between the two entities must be secured. 264 In addition, however, the protocol must not preclude the possibility 265 of supporting asymmetric authentication mechanisms. 267 3.1.8.1 268 Protocol Evaluation 269 First of all, as currently defined, CTP does not support a pre-shared 270 key mechanism for mutual authentication. It assumes the existence of 271 digital certificates on the WTP and AC. The mutual authentication 272 mechanism between WTP and AC using digital certificates as described 273 in the CTP draft is very similar to the method employed in the LWAPP 274 draft [5]. As such, some of the recent comments on the WG email list 275 regarding the security of LWAPP�s mutual authentication also applies 276 to CTP. Specifically in the area of the generation of the encryption 277 key. Currently CTP specifies that the encryption key is generated by 278 the AC and is securely transported to the WTP. An obvious 279 improvement would be for the WTP and the AC to mutually contribute to 280 the generation of the encryption key by providing independently 281 generated random material for the session keys. 283 Also, based on discussion on the WG list it is not clear whether the 284 use of pre-shared key for mutual authentication is required or simply 285 that the authentication must be mutual. Nevertheless, we believe 286 that adding another method of mutual authentication, ie. with using 287 pre-shared keys, will enhance the flexibility of the CTP protocol, 288 but at the cost of increased protocol complexity. 290 3.1.8.2 291 Compliance 292 CTP is partially compliant with this objective. 294 3.1.9 295 System-wide Security 296 The protocol must not adversely affect the security of the wireless 297 and wired networks on which it runs. 299 3.1.9.1 300 Protocol Evaluation 301 CTP defines that any exchanges of control based material such as PMK 302 is natively encrypted. All Control messages are mutually encrypted 303 between the WTP and controller. In lieu of a thorough security and 304 cryptographic analysis of the protocol by peers, the authors believe 305 that the encryption/keying mechanism currently provides adequate 306 protection against un-authorized compromise of the transported 307 information which, in turn, would not adversely affect the security 308 of the wireless or wired network. 310 3.1.9.2 311 Compliance 312 The protocol is partially compliant with this objective pending a 313 thorough security and cryptographic review. 315 3.1.10 316 IEEE 802.11i Considerations 317 The CAPWAP protocol must determine the exact structure of the 318 centralized WLAN architecture in which authentication needs to be 319 supported, i.e. the location of major authentication components. 321 This may be achieved during WTP initialization where major 322 capabilities are distinguished. 324 The protocol must allow for the exchange of key information when 325 authenticator and encryption roles are located in distinct entities. 327 3.1.10.1 328 Protocol Evaluation 329 The CTP protocol has separated the 802.11i security function into two 330 components, EAP Authenticator and Key Management. The EAP 331 Authenticator and Key Management functions provide a natural 332 delineation point between 802.11i functions. The location of the 333 components is negotiated between the AC and WTP during the 334 capabilities exchange and registration. The components can either co- 335 located or separate on the WTP or the AC. Any exchange of security 336 association information between the AC and the WTP is protected 337 either by 802.11i mechanisms or by CTP mechanisms. 339 3.1.10.2 340 Compliance 341 CTP is compliant with this objective. 343 3.1.11 344 Interoperability Objective 345 The objective specifies that the protocol must include a capabilities 346 exchange mechanism so that different types of WTPs can be managed by 347 ACs. That is, local-MAC and split-MAC WTPs may be recognized by the 348 AC through protocol exchange and appropriate handling within the 349 protocol would ensue as a result of this capability exchange. 351 3.1.11.1 352 Protocol Evaluation 353 The CTP protocol as specified, provides a mechanism for capabilities 354 exchange (CTP-caps-req/resp) that allows the WTP and the Controller 355 to negotiate their operational mode. The capabilities exchange for 356 control and data traffic is treated independently. 358 Control traffic in split-MAC mode indicates that the WTP will forward 359 all wireless MAC management traffic (i.e. IEEE 802.11) to the AC. 361 Control traffic in local-MAC mode indicates that all 802.11 362 management frames will terminate at the WTP. CTP defines update 363 messages to allow the WTP to signal the AC for updates to wireless 364 client connection states. 366 Data traffic in split-MAC modes indicates that the WTP will forward 367 all traffic to the AC. The format for the traffic can be either 368 wireless MAC dependent (i.e. IEEE 802.11) or IEEE 802.3 depending 369 whether the control channel is split-MAC or local-MAC. 371 Data traffic in local-MAC mode indicates that data frames will be 372 bridged locally by the AP to its switching segment. The switching 373 segment may be present locally at the AP or at the Controller. For 374 Controller handled bridged access the CTP protocol provides a 375 tunneling method for 802.3 frame encapsulation. 377 3.1.11.2 378 Compliance 379 CTP is compliant with this objective. 381 3.1.12 382 Protocol Specifications 383 This objective states that any vendor of a WTP or AC or any person 384 may implement the CAPWAP protocol and that all such implementations 385 should interoperate. 387 3.1.12.1 388 Protocol Evaluation 389 CTP specification fully specify the protocol and its operation within 390 WTPs and ACs. It also indicates the configuration and statistics 391 capabilities come from MIB specifications that are published by IEEE 392 that fully describe the managed objects within an WTP. The authors 393 believe that the work done by the IEEE will enable full 394 interoperability as the specifications coming from IEEE will be 395 complete and not require any knowledge of any vendor specific 396 wireless device information. 398 3.1.12.2 399 Compliance 400 CTP is compliant with this objective. 402 3.1.13 403 Vendor Independence 404 This objective states that the CAPWAP protocol must not be reliant on 405 any underlying vendor implementation of hardware of either the WTP or 406 the AC. 408 3.1.13.1 409 Protocol Evaluation 410 CTP does not assume any underlying hardware architecture of the WTPs 411 or the ACs. In addition any dependency on MIB definitions in its 412 current form also does not assume any reliance on hardware 413 specifications. 415 3.1.13.2 416 Compliance 418 CTP is compliant with this objective. 420 3.1.14 421 Vendor Flexibility 422 The protocol must not be bound to any specific MAC. 424 3.1.14.1 425 Protocol Evaluation 426 CTP has been completely implemented on hardware from at least two 427 different vendors whose wireless MAC implementations are completely 428 independent. Given this fact as well as CTP�s inherent agnosticity 429 of wireless implementation, CTP can be implemented without knowledge 430 of underlying vendor hardware. 432 3.1.14.2 433 Compliance 434 CTP is compliant with this objective. 436 3.1.15 437 NAT Traversal 438 The protocol must not prevent operation across WLAN topologies which 439 include NAT segments. 441 3.1.15.1 442 Protocol Evaluation 443 CTP provides an authentication mechanism which uses AC and WTP 444 identifiers to establish a secure connection without a dependency on 445 MAC or IP address. The CTP protocol is primarily transported as UDP 446 payload. Typical NAT implementations are IP and TCP/UDP port based. 447 Since CTP is transported above these layers, CTP will work properly 448 through NAT devices. The WTP can be statically configured to discover 449 the AC through a NAT segment. 451 3.1.15.2 452 Compliance 453 CTP is compliant with this objective. 455 3.2 456 Desirable Objectives 458 3.2.1 459 Multiple Authentication Mechanisms 460 This objective specifies the requirement that the protocol should be 461 able to support authentication mechanisms other than IEEE 802.11i. 463 3.2.1.1 464 Protocol Evaluation 465 Since CTP is wireless terminal agnostic, and since the PMK key 466 exchange is generic (for example, does not assume any authentication 467 mechanism in the form of an EAP type), CTP does not prevent the 468 operation of any other authentication mechanisms. 470 CTP logically separates the EAP-Authentication function from the Key 471 Management function. Different authentication or key management 472 frameworks can be substituted without affecting the protocol 473 behavior. 475 3.2.1.2 476 Compliance 477 CTP is compliant with this objective. 479 3.2.2 480 Support for Future Wireless Technologies 481 This objective states that the protocol should be able to be extended 482 to future layer 2 wireless technologies and should not be limited to 483 only supporting IEEE 802.11. 485 3.2.2.1 486 Protocol Evaluation 487 The current specification lists alternative layer 2 wireless 488 technologies that and be indicated as part of the capabilities 489 exchange phase. The protocol is sufficiently modular in that the 490 configuration, statistics and other management functions of these 491 wireless devices can be supported. If indeed there are layer 2 492 wireless specific elements that need to be added, those are easily 493 supported by extensions to the protocol. 495 3.2.2.2 496 Compliance 497 CTP is compliant with this objective. 499 3.2.3 500 Support for New IEEE Requirements 501 The protocol must be able to accommodate defined changes or 502 extensions to the IEEE 802.11 specifications. 504 3.2.3.1 505 Protocol Evaluation 506 CTP provides an abstraction layer to accommodate any type of wireless 507 MAC technology. It provides control messages to exchange basic state 508 information between the AC and the WTP. It provides a split MAC 509 mechanism where all MAC frames can be forwarded and handled at the 510 controller. It uses SNMP-based encapsulation to provide a generic 511 mechanism for exchanging configuration and statistics data . New 512 802.11 amendments can be easily accommodated by the protocol. There 513 will be work required to interpret the impact of the amendment on 514 both the AC and the WTP to determine whether further message 515 definition is required. 517 3.2.3.2 518 Compliance 519 CTP is compliant with this objective. 521 3.2.4 522 Interconnection Objective 523 The CAPWAP protocol must not be constrained by the underlying 524 transport technologies of the wired medium. 526 3.2.4.1 527 Protocol Evaluation 528 CTP is agnostic to the underlying transport technology as it is 529 implemented as UDP. This was done with the assumption that the 530 transport technology can carry IP packets across its medium either L2 531 or L3 network. In it�s current definition CTP is transported as UDP 532 payload therefore directly abstracted from IPv4/v6 base. 534 3.2.4.2 535 Compliance 536 CTP is compliant with this objective in terms of not having specified 537 IPv6 header types. 539 3.2.5 540 Access Control 541 This objective pertains to the ability of the protocol to exchange 542 information required for access control of WTPs and wireless 543 terminals. 545 3.2.5.1 546 Protocol Evaluation 547 CTP provides specific messages, e.g. CTP-MU- 548 Connect/Disconnect/Authenticate messages, that control the access of 549 wireless terminals. In addition to the actual mutual authentication 550 of WTPs and ACs, the registration phase contains a AP-ID field that 551 needs to be verified by the AC. This field needs to be checked by 552 the AC and the mechanism for this check is not within the scope of 553 any CAPWAP work. However, the CTP protocol itself provides this 554 identification token as a means of access control of the WTP. 556 3.2.5.2 557 Compliance 558 CTP is compliant with this objective. 560 3.3 561 Non-objectives 563 The current objectives draft states this section as �Rejected 564 Objectives�. We have used the term �Non-Objectives� for this section 565 based on the discussion on the WG email list. 567 3.3.1 568 Support for Non-CAPWAP WTPs 569 This objective states that the CAPWAP protocol should be capable of 570 recognizing legacy WTPs and existing network management systems. 572 3.3.1.1 573 Protocol Evaluation 574 This requirement is more of a feature for centralized WLAN network 575 applications and thus does not apply to the CAPWAP problem statement. 577 3.3.1.2 578 Compliance 579 CTP is compliant with this objective. 581 3.3.2 582 Technical Specifications 583 This objective states that WTP vendors should not have to share 584 technical specifications for hardware and software to AC vendors in 585 order for interoperability to be achieved. 587 3.3.2.1 588 Protocol Evaluation 589 As discussed earlier, CTP is hardware and vendor agnostic. 591 3.3.2.2 592 Compliance 594 CTP is compliant with this objective. 596 3.4 597 Operator Requirements 599 3.4.1 600 AP Fast Handoff 601 This objective states that the CAPWAP protocol operations must not 602 impede or obstruct the efficiency of fast handoff procedures. 604 3.4.1.1 605 Protocol Evaluation 606 In the CTP protocol, the signaling of roaming events are efficiently 607 encoded in the CTP-MU messages. Also, the 802.1x messaging is 608 centralized allowing efficient use of CPU resources at the AC. In 609 effect, the mere existence of the centralized architecture ensures 610 that the efficiency of fast handoffs is improved rather than impeded. 612 3.4.1.2 613 Compliance 614 CTP complies with this objective. 616 4. 617 Compliance Table 619 Given below is a table summarizing the compliance to the objectives. 620 C = Compliant, P = Partially compliant, N = Non-compliant. 622 +----------------------------------------------------+------------+ 623 | Objective Type | Compliance | 624 +----------------------------------------------------+------------+ 625 | Logical Groups | C | 626 | Support for Traffic Separation | C | 627 | Wireless Terminal Transparency | C | 628 | Configuration Consistency | C | 629 | Firmware Trigger | C | 630 | Monitoring & Exchange of System-wide Resource State| C | 631 | Resource Control Objective | C | 632 | CAPWAP Protocol Security | P | 633 | System-wide Security | C | 634 | IEEE 802.11i Considerations | C | 635 | Interoperability Objective | C | 636 | Protocol Specifications | C | 637 | Vendor Independence | C | 638 | Vendor Flexibility | C | 639 | NAT Traversal | C | 640 | Multiple Authentication Mechanisms | C | 641 | Support for Future Wireless Technologies | C | 642 | Support for New IEEE Requirements | C | 643 | Interconnection Objective | C | 644 | Access Control | C | 645 | Support for Non-CAPWAP WTPs | C | 646 | Technical Specifications | C | 647 | AP Fast Handoff | C | 648 +----------------------------------------------------+------------+ 650 5. 651 Security considerations 653 This document provides a self evaluation of CTP in respect to the 654 CAPWAP objectives. The CTP draft itself has a section that 655 catalogues all the pertinent security concerns. Therefore, in this 656 draft there are no new security considerations to be discussed. 658 6. 659 References 661 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 662 Levels", BCP 14, RFC 2119, March 1997 664 [2] Singh, I., et. al., �CAPWAP Tunneling Protocol�, draft-singh- 665 capwap-ctp-01.txt (work in progress), April 2005. 667 [3] Calhoun, P., "CAPWAP Problem Statement", draft-ietf-capwap- 668 problem-statement-02.txt (work in progress), September 2004. 670 [4] Govindan, S., et. al., �Objectives for Control and Provisioning 671 of Wireless Access Points (CAPWAP)�, draft-ietf-capwap-objectives- 672 02.txt (work in progress), April 2005 674 [5] Calhoun, et. al., �Light Weight Access Point Protocol (LWAPP)�, 675 draft-ohara-capwap-lwapp-02.txt (work in progress), April 2005 677 7. 678 Author's Addresses 680 Paulo Francisco 681 Chantry Networks Inc. 682 1900 Minnesota Court 683 Mississauga, ON L5N 3C9 684 Canada 686 Phone: +1 905-363-6410 687 Email: paulo.francisco@siemens.com 689 Inderpreet Singh 690 Chantry Networks Inc. 691 1900 Minnesota Court 692 Mississauga, ON L5N 3C9 693 Canada 694 Phone: +1 905-363-6412 695 Email: inderpreet.singh@siemens.com 697 Michael Montemurro 698 Chantry Networks Inc. 699 1900 Minnesota Court 700 Mississauga, ON L5N 3C9 701 Canada 703 Phone: +1 905-363-6413 704 Email: michael.montemurro@siemens.com 706 Intellectual Property Statement 708 The IETF takes no position regarding the validity or scope of any 709 intellectual property or other rights that might be claimed to 710 pertain to the implementation or use of the technology described in 711 this document or the extent to which any license under such rights 712 might or might not be available; neither does it represent that it 713 has made any effort to identify any such rights. Information on the 714 IETF's procedures with respect to rights in standards-track and 715 standards-related documentation can be found in BCP-11. Copies of 716 claims of rights made available for publication and any assurances of 717 licenses to be made available, or the result of an attempt made to 718 obtain a general license or permission for the use of such 719 proprietary rights by implementers or users of this specification can 720 be obtained from the IETF Secretariat. 722 The IETF invites any interested party to bring to its attention any 723 copyrights, patents or patent applications, or other proprietary 724 rights which may cover technology that may be required to practice 725 this standard. Please address the information to the IETF Executive 726 Director. 728 Disclaimer of Validity 730 This document and the information contained herein are provided on an 731 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 732 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 733 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 734 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 735 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 736 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 738 Copyright Statement 740 Copyright (C) The Internet Society (2005). This document is subject 741 to the rights, licenses and restrictions contained in BCP 78, and 742 except as set forth therein, the authors retain all their rights. 744 Acknowledgment 746 Funding for the RFC Editor function is currently provided by the 747 Internet Society.