idnits 2.17.1 draft-ietf-capwap-objectives-04.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 23. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1400. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1377. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1384. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1390. ** 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 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 (September 28, 2005) is 6783 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Section 2' is mentioned on line 241, but not defined ** Downref: Normative reference to an Informational RFC: RFC 3990 ** Downref: Normative reference to an Informational RFC: RFC 4118 Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Govindan (Editor) 3 Internet-Draft Panasonic 4 Expires: April 1, 2006 ZH. Yao 5 Huawei 6 WH. Zhou 7 China Mobile 8 L. Yang 9 Intel 10 H. Cheng 11 Panasonic 12 September 28, 2005 14 Objectives for Control and Provisioning of Wireless Access Points 15 (CAPWAP) 16 draft-ietf-capwap-objectives-04.txt 18 Status of this Memo 20 By submitting this Internet-Draft, each author represents that any 21 applicable patent or other IPR claims of which he or she is aware 22 have been or will be disclosed, and any of which he or she becomes 23 aware will be disclosed, in accordance with Section 6 of BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on April 1, 2006. 43 Copyright Notice 45 Copyright (C) The Internet Society (2005). 47 Abstract 48 This document presents objectives for an interoperable protocol for 49 the Control and Provisioning of Wireless Access Points (CAPWAP). The 50 document aims to establish a set of focused requirements for the 51 development and evaluation of a CAPWAP protocol. The objectives 52 address Architecture, Operation, Security and Network Operator 53 Requirements that are necessary to enable interoperability among 54 wireless local area network (WLAN) devices of alternative designs. 56 Table of Contents 58 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 4. Objectives Overview . . . . . . . . . . . . . . . . . . . . . 7 62 5. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . 8 63 5.1. Mandatory and Accepted Objectives . . . . . . . . . . . . 8 64 5.1.1. Logical Groups . . . . . . . . . . . . . . . . . . . . 8 65 5.1.2. Support for Traffic Separation . . . . . . . . . . . . 9 66 5.1.3. Wireless Terminal Transparency . . . . . . . . . . . . 10 67 5.1.4. Configuration Consistency . . . . . . . . . . . . . . 11 68 5.1.5. Firmware Trigger . . . . . . . . . . . . . . . . . . . 12 69 5.1.6. Monitoring and Exchange of System-wide Resource 70 State . . . . . . . . . . . . . . . . . . . . . . . . 12 71 5.1.7. Resource Control Objective . . . . . . . . . . . . . . 13 72 5.1.8. CAPWAP Protocol Security . . . . . . . . . . . . . . . 15 73 5.1.9. System-wide Security . . . . . . . . . . . . . . . . . 16 74 5.1.10. IEEE 802.11i Considerations . . . . . . . . . . . . . 17 75 5.1.11. Interoperability Objective . . . . . . . . . . . . . . 19 76 5.1.12. Protocol Specifications . . . . . . . . . . . . . . . 20 77 5.1.13. Vendor Independence . . . . . . . . . . . . . . . . . 21 78 5.1.14. Vendor Flexibility . . . . . . . . . . . . . . . . . . 21 79 5.1.15. NAT Traversal . . . . . . . . . . . . . . . . . . . . 22 80 5.2. Desirable Objectives . . . . . . . . . . . . . . . . . . . 23 81 5.2.1. Multiple Authentication Mechanisms . . . . . . . . . . 23 82 5.2.2. Support for Future Wireless Technologies . . . . . . . 23 83 5.2.3. Support for New IEEE Requirements . . . . . . . . . . 24 84 5.2.4. Interconnection Objective . . . . . . . . . . . . . . 25 85 5.2.5. Access Control . . . . . . . . . . . . . . . . . . . . 26 86 5.3. Non-Objectives . . . . . . . . . . . . . . . . . . . . . . 27 87 5.3.1. Support for Non-CAPWAP WTPs . . . . . . . . . . . . . 27 88 5.3.2. Technical Specifications . . . . . . . . . . . . . . . 28 89 5.4. Operator Requirements . . . . . . . . . . . . . . . . . . 28 90 5.4.1. AP Fast Handoff . . . . . . . . . . . . . . . . . . . 28 91 6. Summary and Conclusion . . . . . . . . . . . . . . . . . . . . 30 92 7. Security Considerations . . . . . . . . . . . . . . . . . . . 31 93 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32 94 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 96 Intellectual Property and Copyright Statements . . . . . . . . . . 35 98 1. Requirements notation 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in [RFC2119]. 104 2. Terminology 106 This document follows the terminologies of [RFC4118]. Additionally, 107 the following terms are defined; 109 Centralized WLAN: A WLAN based on the centralized WLAN Architecture 110 [RFC4118]. 112 Switching Segment: Those aspects of a centralized WLAN that primarily 113 deal with switching or routing of control and data information 114 between Wireless Termination Points (WTPs) and the WLAN controller. 116 Wireless Medium Segment: Those aspects of a centralized WLAN that 117 primarily deal with the wireless interface between WTPs and wireless 118 terminals. The Wireless Medium Segment is specific to layer 2 119 wireless technology, such as IEEE 802.11. 121 CAPWAP Framework: A term that covers the local-MAC and split-MAC 122 designs of the Centralized WLAN Architecture. Standardization 123 efforts are focussed on these designs. 125 CAPWAP Protocol: The protocol between WLAN controller and WTPs in the 126 CAPWAP framework. It facilitates control, management and 127 provisioning of WTPs in an interoperable manner. 129 Logical Group: A logical separation of a physical WTP is termed 130 logical group. So a single physical WTP will operate a number of 131 logical groups. Virtual APs are examples of logical groups. Here, 132 each BSSID and constituent wireless terminals' radios are denoted as 133 distinct logical groups of a physical WTP. Logical groups are 134 maintained without conflicting with the CAPWAP Objectives, 135 particularly the 'Wireles Terminal Transparency' Objective. 137 3. Introduction 139 The growth in large-scale wireless local area network (WLAN) 140 deployments has brought to focus a number of technical challenges. 141 Among them is the complexity of managing large numbers of wireless 142 termination points (WTPs), which is further exacerbated by variations 143 in their design. Another challenge is the maintenance of consistent 144 configurations among the numerous WTPs of a system. The dynamic 145 nature of the wireless medium is also a concern together with WLAN 146 security. The challenges affecting large-scale WLAN deployments have 147 been highlighted in [RFC3990]. 149 Many vendors have addressed these challenges by developing new 150 architectures and solutions. A survey of the various developments 151 was conducted to better understand the context of these challenges. 152 This survey is a first step towards designing interoperability among 153 the solutions. The Architecture Taxonomy [RFC4118] is a result of 154 this survey in which major WLAN architecture families are classified. 155 Broadly, these are the autonomous, centralized WLAN and distributed 156 mesh architectures. 158 The Architecture Taxonomy identified the centralized WLAN 159 architecture as one in which portions of the wireless medium access 160 control (MAC) operations are centralized in a WLAN controller. This 161 centralized WLAN architecture is further classified into remote-MAC, 162 split-MAC and local-MAC designs. Each differs in the degree of 163 separation of wireless MAC layer capabilities between WTPs and WLAN 164 controller. 166 This document puts forward critical objectives for achieving 167 interoperability in the CAPWAP framework. It presents requirements 168 that address the challenges of controling and provisioning large- 169 scale WLAN deployments. The realization of these objectives in a 170 CAPWAP protocol will ensure that WLAN equipment of major design types 171 may be integrally deployed and managed. 173 4. Objectives Overview 175 The objectives for CAPWAP have been broadly classified to address 176 architecture, operation and security requirements of managing large- 177 scale WLAN deployments. 179 Architecture objectives deal with system level aspects of the CAPWAP 180 protocol. They address issues of protocol extensibility, diversity 181 in network deployments and architecture designs and differences in 182 transport technologies. 184 Operational objectives address the control and management features of 185 the CAPWAP protocol. They deal with operations relating to WLAN 186 monitoring, resource management, QoS and access control. 188 Security objectives address potential threats to WLANs and their 189 containment. In the CAPWAP context, security requirements cover both 190 the protocol between WLAN controller and WTPs and also the WLAN 191 system as a whole. 193 Additionally, a general classification is used for objectives 194 relating to the overall impact of the CAPWAP protocol specifications. 196 5. Objectives 198 The objectives described in this document have been prioritized based 199 on their immediate significance in the development and evaluation of 200 a control and provisioning protocol for large-scale WLAN deployments. 201 Additionally, one category is provided for requirements gathered from 202 network service operators. These are specific need that arise from 203 operators' experiencese in deploying and managing large-scale WLANs. 204 The priorities are; 206 i. Mandatory and Accepted Objectives 207 ii. Desirable Objectives 208 iii. Non-Objectives 209 iv. Operator Requirements 211 The priorities have been assigned to individual objectives in 212 accordance with working group discussions. 214 5.1. Mandatory and Accepted Objectives 216 Objectives prioritized as Mandatory and Accepted have been deemed 217 crucial for the control and provisioning of WTPs. They directly 218 address the challenges of large-scale WLAN deployments and must be 219 realized by a CAPWAP protocol. 221 5.1.1. Logical Groups 223 Classification: Architecture 225 Description: 227 Large WLAN deployments are complex and expensive. Furthermore, 228 enterprises deploying such networks are under pressure to improve the 229 efficiency of their expenditures. 231 Shared WLAN deployments, where a single physical WLAN infrastructure 232 supports a number of logical networks, are increasingly used to 233 address these two issues of large-scale WLANs. These are popular as 234 they allow deployment and management costs to be spread across 235 businesses. 237 In traditional WLANs, each physical WTP represents one complete 238 subset of a larger WLAN system. Shared WLANs differ in that each 239 physical WTP represents a number of logical subsets of possibly a 240 number of larger WLAN systems. Each logical division of a physical 241 WTP is referred to as a logical group [Section 2]. So WLANs are 242 managed in terms of logical groups instead of physical WTPs. Logical 243 groups are based on BSSIDs and other types of virtual APs. 245 Protocol Requirement: 247 The CAPWAP protocol MUST be capable of controlling and managing 248 physical WTPs in terms of logical groups including BSSID-based 249 groups. 251 For all operating modes, including those in which the WTP performs 252 local bridging and those in which the AC performs centralized 253 bridging, the protocol MUST provide provisions for configuring 254 logical groups at the WTP. 256 Motivation and Protocol Benefits: 258 Commercial realities necessitate that WLANs be manageable in terms of 259 its logical groups. This allows separation of logical services and 260 underlying infrastructure management. A protocol that realizes this 261 need ensures simlper and cost effective WLANs, which directly address 262 the requirements of network service operators. 264 Relation to Problem Statement: 266 This objective addresses the problem of management complexity in 267 terms of costs. Cost complexity is reduced by sharing WLAN 268 deployments. Consequently, deployment and management cost- 269 efficiencies are realized. 271 5.1.2. Support for Traffic Separation 273 Classification: Operations 275 Description: 277 The centralized WLAN architecture simplifies complexity associated 278 with large-scale deployments by consolidating portions of wireless 279 MAC functionality at a central WLAN controller and distributing the 280 remaining across WTPs. As a result, WTPs and WLAN controller 281 exchange control and data information between them. This objective 282 states that control and data aspects of the exchanges be mutually 283 separated for further simplicity. This will allow solutions for each 284 type of exchange to be independently optimized. 286 Furthermore, in the context of shared WLAN deployments, the mutual 287 separation of control and data also addresses security concerns. In 288 particular, given the likelihood of different logical groups, such as 289 those established by different virtual APs, being managed by 290 different administrators, separation of control and data is a first 291 step towards individually containing and securing the logical groups. 293 It is also important to ensure that traffic from each logical group 294 be mutually separated to maintain the integrity and independence of 295 the logical groups. 297 Protocol Requirement: 299 The CAPWAP Protocol MUST define transport control messages such that 300 the transport of control messages is separate from the transport of 301 data messages. 303 Motivation and Protocol Benefits: 305 The aim of separating data and control aspects of the protocol is to 306 simplify the protocol. It also allows for the flexibility of 307 addressing each type of traffic in the most appropriate manner. 309 Furthermore, this requirement will help remotely located WTPs to 310 handle data traffic in alternative ways without the need for 311 forwarding them across a wide network to the WLAN controller. 313 Separation of WTP control and data also aids in the secure 314 realization of shared WLAN deployments. 316 Relation to Problem Statement: 318 Broadly, this objective relates to the challenge of managing 319 complexity in large-scale WLANs. The requirement for traffic 320 separation simplifies control as this is separated from the task of 321 data transport. 323 5.1.3. Wireless Terminal Transparency 325 Classification: Operations 327 Description: 329 The CAPWAP protocol is applicable between a centralized WLAN 330 controller and a number of WTPs, i.e. it affects only the switching 331 segment of the centralized WLAN architecture. Its operations should 332 therefore be independent of the wireless terminal. Wireless 333 terminals should not be required to be aware of the existence of the 334 CAPWAP protocol. 336 Protocol Requirement: 338 Wireless terminals MUST NOT be required to recognize or be aware of 339 the CAPWAP protocol. 341 Motivation and Protocol Benefits: 343 IEEE 802.11 based wireless terminals are mature and widely available. 344 It would be beneficial for CAPWAP not to impose new requirements on 345 these wireless terminals. In effect, this requirement ensures that 346 the setup cost of the protocol is reduced as the numerous existing 347 wireless terminals need not be altered. 349 Relation to Problem Statement: 351 The Problem Statement highlights the challenges faced by large WLANs 352 consisting of many WTPs. It does not refer to the operations of 353 wireless terminals and this objective emphasizes the independence. 355 5.1.4. Configuration Consistency 357 Classification: Operations 359 Description: 361 WLANs in the CAPWAP framework contain numerous WTPs, each of which 362 need to be configured and managed in a consistent manner. The main 363 concern in ensuring consistency is availability of appropriate 364 information corresponding to WTP configuration states. So 365 configuration consistency can be achieved by providing the 366 centralized WLAN controller with regular updates on the state of WTP 367 operations. The centralized WLAN controller can in turn apply 368 information from the regular updates to ensure consistently among the 369 WTPs. 371 Protocol Requirement: 373 The CAPWAP protocol MUST include support for regular exchanges of 374 state information between WTPs and WLAN controller. Examples of 375 state information include WTP processing load and memory utilization. 377 Motivation and Protocol Benefits: 379 A protocol that provides access to regular state information can in 380 turn be used to enhance WLAN configuration and performance. The 381 CAPWAP protocol will be better equipped to address configuration 382 related problems with the regularly available state information. So 383 with greater state information, control and management operations can 384 be improved. 386 Relation to Problem Statement: 388 One of the major challenges described in the Problem Statement is 389 that of maintaining consistent configuration across the numerous WTPs 390 of a WLAN. This objective addresses the fundamental issue behind 391 this - availability of timely state information. 393 5.1.5. Firmware Trigger 395 Classification: Operations 397 Description: 399 One specific aspect of configuration consistency is the firmware used 400 by various WTPs. The scale of large WLANs introduces possibilities 401 for variations in the firmware used among WTPs. This objective 402 highlights the need for the CAPWAP protocol to trigger the delivery 403 of appropriate versions of firmware to WTPs. The actual delivery of 404 firmware need not be inclusive to the protocol. 406 Protocol Requirement: 408 The CAPWAP protocol MUST support a trigger for delivery of firmware 409 updates. 411 Motivation and Protocol Benefits: 413 The CAPWAP protocol interfaces many WTPs to a centralized WLAN 414 controller. Firmware distribution allows these interfaces to be 415 compatible. This in turn results in consistent configuration and 416 simplified management. So the protocol benefits by including 417 triggers for the distribution of firmware updates. 419 Relation to Problem Statement: 421 Inconsistencies in the configuration of WTPs has been identified as a 422 major challenge for large-scale WTPs. This objectives helps overcome 423 the challenge by providing for a way for the CAPWAP protocol to 424 initiate delivery of firmware updates that are compatible among all 425 WTPs. 427 5.1.6. Monitoring and Exchange of System-wide Resource State 429 Classification: Operations 431 Description: 433 The centralized WLAN architecture is made up of a switching segment 434 and wireless medium segment. In the switching segment, network 435 congestion, WTP status and firmware information have to be monitored. 436 In the wireless medium segment, the dynamic nature of the medium 437 itself has to be monitored. Overall, there are also various 438 statistics need to be considered for efficient WLAN operation. 440 The CAPWAP protocol should be capable of monitoring the various 441 information sources and deliver the resulting information to the 442 relevant WLAN devices - either WTPs or WLAN controller. Moreover, 443 given the relationship among information sources, the CAPWAP protocol 444 should combine state information from them. For example, statistics 445 information and status signals from WTPs may be merged before being 446 exchanged. 448 Examples of statistics information that the CAPWAP protocol should 449 monitor and exchange include; congestion state, interference levels, 450 loss rates and various delay factors. 452 Protocol Requirement: 454 The CAPWAP protocol MUST allow for the exchange of statistics, 455 congestion and other WLAN state information. 457 Motivation and Protocol Benefits: 459 The effectivness of a protocol is based on the relevance of 460 information on which it operates. This requirement for resource 461 monitoring and exchange can provide the appropriate information to 462 the CAPWAP protocol. 464 Relation to Problem Statement: 466 The Problem Statement highlights the challenge of dealing with large 467 numbers of WTPs and the dynamic nature of the wireless medium. 468 Information on the state of WTPs and the medium is important to deal 469 with them effectively. So this objective relates to the problem of 470 managing consistency in large WLANs. 472 5.1.7. Resource Control Objective 474 Classification: Operations 476 Description: 478 Integral to the success of any wireless network system is the 479 performance and quality it can offer its subscribers. Since CAPWAP 480 based WLANs combine a switching segment and a wireless medium 481 segment, performance and quality need to be coordinated across both 482 of these segments. So QoS performance must be enforced system-wide. 484 This objective highlights QoS over the entire WLAN system which 485 includes the switching segment and the wireless medium segment. 486 Given the fundamental differences between the two, it is likely that 487 there are alternate QoS mechanisms between WTPs and wireless service 488 subscribers and between WTPs and WLAN controllers. For instance, the 489 former will be based on IEEE 802.11e while the latter will be an 490 alternative. So resources need to be adjusted in a coordinated 491 fashion over both segments. The CAPWAP protocol should ensure that 492 these adjustments are appropriately exchanged between WLAN 493 controllers and WTPs. 495 In addition to IEEE 802.11e, there are a number of other IEEE 802.11 496 Task Groups that may affect network resources. These include IEEE 497 802.11 TGk, TGu and TGv, which are currently under progress. CAPWAP 498 should therefore not be restricted to IEEE 802.11e based mapping. 500 Protocol Requirement: 502 The CAPWAP protocol MUST map the IEEE 802.11e QoS priorities to 503 equivalent QoS priorities across the switching and wireless medium 504 segments 506 Motivation and Protocol Benefits: 508 A protocol that addresses QoS aspects of WLAN systems will deliver 509 high performance thereby being beneficial for subscribers and for 510 resource utilization efficiency. Since CAPWAP deals with WTPs 511 directly and with the wireless medium indirectly, both of these must 512 be considered for performance. 514 For the wireless medium segment, QoS aspects in the protocol enable 515 high quality communications within the domain of a WLAN controller. 516 Since each domain generally covers an enterprise or a group of 517 service providers, such protocol performance has wide-ranging 518 effects. 520 Within the switching segment of CAPWAP, a QoS-enabled protocol 521 minimizes the adverse effects of dynamic traffic characteristics so 522 as to ensure system-wide performance. 524 Relation to Problem Statement: 526 QoS control is critical to large WLANs and relates to a number of 527 aspects. In particular, this objective can help address the problem 528 of managing dynamic conditions of the wireless medium. 530 Furthermore, traffic characteristics in large scale WLANs are 531 constantly varying. So network utilization becomes inefficient and 532 user experience is unpredictable. 534 The interaction and coordination between the two aspects of system- 535 wide QoS is therefore critical for performance. 537 5.1.8. CAPWAP Protocol Security 539 Classification: Security 541 Description: 543 This objective addresses the security of the CAPWAP protocol. 545 The CAPWAP protocol MUST first provide for the participating entities 546 - WLAN controller and WTPs - to be explicitly mutually authenticated. 547 This is to ensure that rogue elements do not gain access to the WLAN 548 system. Rogue WTPs should not be allowed to breach legitimate WLANs 549 and at the same time rogue WLAN controllers should not be allowed to 550 gain control of legitimate WTPs. For example, WTPs may need to 551 regularly renew their authentication state with the WLAN controller 552 and similarly for WLAN controllers. 554 If authentication is performed via an authenticated key exchange, 555 future knowledge of derived keys is not sufficient for 556 authentication. 558 Any session keys used between the WLAN controller and WTP MUST be 559 mutually derived using entropy contributed by both parties. This 560 ensures that no one party has control over the resulting session 561 keys. 563 Once WTPs and WLAN controller have been mutually authenticated, 564 information exchanges between them must be secured against various 565 security threats. This should cover illegitimate modifications to 566 protocol exchanges, eavesdropping and DoS attacks, among other 567 potential compromises. So the protocol must be provide 568 confidentiality, integrity and authenticity for those exchanges. 570 As a result of realizing this objective it should not be possible for 571 individual WTP breaches to affect the security of the WLAN as a 572 whole. So WTP mis-use will be protected against. 574 Additionally, the key establishment protocol for authentication and 575 securing CAPWAP exchanges must be designed to minimize the 576 possibility of future compromises after the keys are established. 578 CAPWAP MUST NOT prevent the use of asymmetric authentication. The 579 security considerations of such asymmetric authentication are 580 described in the Security Considerations section. 582 Protocol Requirement: 584 The CAPWAP protocol MUST support mutual authentication of WTPs and 585 the centralized controller. It must also ensure that information 586 exchanges between them are secured. 588 Motivation and Protocol Benefits: 590 WLANs are increasingly deployed in critical aspects of enterprise and 591 consumer networks. In these contexts, protocol security is crucial 592 to assure the privacy and integrity expected from network 593 administrators and end-users. So securing the CAPWAP protocol has 594 direct benefits in addressing these concerns. 596 In many cases, the network path between a WTP and WLAN controller 597 contains untrusted links. Such links could be leveraged by rogue 598 WTPs to gain access to the WLAN system. They could also be used by 599 rogue WLAN controllers to gain control of legitimate WTPs and their 600 associated terminals to either redirect or compromise terminal 601 traffic. These security concerns can be mitigated with this 602 objective. 604 Relation to Problem Statement: 606 Security problems in large-scale WLANs are detailed in the Problem 607 Statement. These include complications arising from rogue WTPs and 608 compromised interfaces between WTPs and WLAN controller. The 609 requirement for protocol security addresses these problems and 610 highlights the importance of protecting against them. 612 5.1.9. System-wide Security 614 Classification: Security 616 Description: 618 The emphasis of this objective is on the security threats external to 619 the centralized CAPWAP segment of a WLAN system. The focus is 620 therefore on rogue wireless clients and other illegitimate wireless 621 interferences. There are a number of specific external threats that 622 need to be addressed within the CAPWAP framework. 624 i. PMK Sharing 626 One aspect of this objective relates to recent discussions on PMK 627 sharing in the CAPWAP framework. This objective highlights the need 628 to prevent exploitation of this ambiguity by rogue wireless clients. 629 It is to ensure that any ambiguities arising from the CAPWAP 630 framework are not cause for security breaches. 632 Protocol Requirement: 634 The design of the CAPWAP protocol MUST NOT allow for any compromises 635 to the WLAN system by external entities. 637 Motivation and Protocol Benefits: 639 The external threats to the centralized WLAN architecture become 640 increasingly crucial given the low cost of wireless clients. Since 641 it is relatively inexpensive for rogue individuals to mount attacks, 642 it is important that WLAN systems are protected against them. 643 Adequate mechanisms to thwart such external threats will be of 644 tremendous benefit to the WLAN systems controlled and managed with 645 the CAPWAP protocol. 647 Relation to Problem Statement: 649 This objective is based on the security needs highlighted in the 650 Problem Statement. Specifically, the Problem Statement discusses the 651 effects of the shared wireless medium. This represents the external 652 aspects of the CAPWAP framework from which certain threats can arise. 653 The system-wide security objective addresses such threats in relation 654 to the Problem Statement. 656 5.1.10. IEEE 802.11i Considerations 658 Classification: Operations 660 Description: 662 The CAPWAP protocol must support authentication in the centralized 663 WLAN architecture in which the authenticator and encryption points 664 can be located on distinct entities, i.e. WLAN controller or WTP. 665 The Architecture Taxonomy illustrates a number of variants, in both 666 local-MAC and split-MAC designs, in which the authenticator is 667 located at the WLAN controller and the encryption points are at the 668 WTPs. The CAPWAP protocol must be applicable to these variants and 669 allow authentication mechanisms and their consistituent processes to 670 be operable in these cases. 672 An important issue to consider in this case is the exchange of key 673 information when authenticator and encryption points are located on 674 distinct entities. For example, consider the case where IEEE 802.11i 675 is used in a WLAN in which the WLAN controller realizes the 676 authenticator, some WTPs realize encryption (possibly local-MAC WTPs) 677 and other WTPs rely on the WLAN controller for encryption (possibly 678 split-MAC WTPs). 680 Here, CAPWAP will first need to identify the location of the 681 authenticator and encryption points between each WLAN controller-WTP 682 pair. This will likely be part of the initial WTP configuration. 683 Subsequently, the WTPs which realize encryption will need CAPWAP to 684 exchange key information with the authenticator at the WLAN 685 controller. For the WTPs which do not realize encryption, CAPWAP 686 need to adapt its control to bypass the key exchange phase. 688 Clearly, the centralized WLAN architecture presents a different 689 platform for authentication mechanisms compared to legacy WLANs in 690 which a WTP realized both authenticator and encryption roles. So 691 this objective highlights the need for CAPWAP to support 692 authentication and key management in the centralized WLAN 693 architecture. 695 Protocol Requirement: 697 The CAPWAP protocol MUST determine the exact structure of the 698 centralized WLAN architecture in which authentication needs to be 699 supported, i.e. the location of major authentication components. 700 This may be achieved during WTP initialization where major 701 capabilities are distinguished. 703 The protocol must allow for the exchange of key information when 704 authenticator and encryption roles are located in distinct entities. 706 Motivation and Protocol Benefits: 708 The immediate focus of CAPWAP is on supporting IEEE 802.11 based 709 WLANs. As such, it is necessary for the protocol to recognize the 710 major distinction in WLAN design with respect to IEEE 802.11i 711 authenticator and encryption points. This represents a significant 712 variation that has been highlighted in the Architecture Taxonomy. 713 The CAPWAP protocol benefits by accommodating such a major 714 consideration fro IEEE 802.11i. 716 These requirements will be common for all authentication mechanisms 717 over the centralized WLAN architecture. So they are applicable to 718 IEEE 802.11i, UMA and other mechanisms. 720 Relation to Problem Statement: 722 The Problem Statement highlights the availability of different WTP 723 designs and the need to ensure interoperability among them. In this 724 regard, operational changes occuring due to the separation of the 725 IEEE 802.11i authenticator and encryption points need to be 726 accommated within the CAPWAP protocol. 728 5.1.11. Interoperability Objective 730 Classification: Architecture 732 Description: 734 Two major designs of the centralized WLAN architecture are local-MAC 735 and split-MAC. With the focusing of standardization efforts on these 736 two designs, it is crucial to ensure mutual interoperation among 737 them. 739 This objective for the CAPWAP protocol is to ensure that WTPs of both 740 local-MAC and split-MAC architecture designs are capable of 741 interoperation within a single WLAN. Consequently, a single WLAN 742 controller will be capable of controlling both types of WTPs using a 743 single CAPWAP protocol. Integral support for these designs comprises 744 a number of protocol aspects. 746 i. Capability negotiations between WLAN controller and WTPs 748 WTP designs differ in the degree of IEEE 802.11 MAC functionalities 749 that each type of WTP realizes. The major distinctions, split-MAC 750 and local-MAC differ in the processing of IEEE 802.11 MAC frames. In 751 this regard, the CAPWAP protocol should include functionality that 752 allows for negotiationg of significant capabilities between WTPs and 753 WLAN controller. 755 As a first step, such negotiations could cover the type of WTP - 756 split-MAC or local-MAC - as this provides substantial information on 757 their respective capabilities. 759 ii. Establishment of alternative interfaces 761 The capability differences among different WTPs essentially equates 762 to alternative interfaces with a WLAN controller. So the CAPWAP 763 protocol should be capable of adapting its operations to the major 764 different interfaces. In a first case, this would include 765 accommodating capability differences between local-MAC and split-MAC 766 WTPs. 768 The definition of these interfaces in terms of finer granularity of 769 functionalities will be based on AP functionality documents produced 770 by the IEEE 802.11 AP Functionality (APF) Ad-Hoc Committee. 772 Protocol Requirement: 774 The CAPWAP protocol MUST include sufficient capabilities negotiations 775 to distinguish between major types of WTPs. 777 Motivation and Protocol Benefits: 779 The benefits of realizing this architecture objective are both 780 technical and practical. First, there are substantial overlaps in 781 the control operations of local-MAC and split-MAC architecture 782 designs. The Architecture Taxonomy tabulates major common features 783 of the two designs. As a result, it is technically practical to 784 devise a single protocol that manages both types of devices. 786 Next, the ability to operate a CAPWAP protocol for both types of 787 architectural designs enhances its practical prospects as it will 788 have wider appeal. 790 Furthermore, the additional complexity resulting from such 791 alternative interfaces is marginal. Consequently, the benefits of 792 this objective will far outweigh any cost of realizing it. 794 Relation to Problem Statement: 796 The objective for supporting both local-MAC and split-MAC WTPs is 797 fundamental to addressing the Problem Statement. It forms the basis 798 for those problems to be uniformly addressed across the major WLAN 799 architectures. This is the ultimate aim of standardization efforts. 800 The realization of this objective will ensure the development of a 801 comprehensive set of mechanisms that address the challenges of large- 802 scale WLAN deployments. 804 5.1.12. Protocol Specifications 806 Classification: General 808 Description: 810 WLAN equipment vendors require sufficient details from protocol 811 specifications so that implementing them will allow for compatibility 812 with other equipment that run the same protocol. In this light, it 813 is important for the CAPWAP protocol specifications to be reasonably 814 complete for realization. 816 Protocol Requirement: 818 Any WTP or WLAN controller vendor or any person MUST be able to 819 implement the CAPWAP protocol from the specification itself and by 820 that it is required that all such implementations do interoperate. 822 Motivation and Protocol Benefits: 824 It is beneficial for WLAN equipment vendors to refer to a single set 825 of specifications while implementing the CAPWAP protocol. This helps 826 to ease and quicken the development process. 828 Relation to Problem Statement: 830 This requirement is based on WG discussions that have determined to 831 be important for CAPWAP. 833 5.1.13. Vendor Independence 835 Classification: General 837 Description: 839 Rapid developments in WLAN technologies results in equipment vendors 840 constantly modifying their devices. In many cases, developments are 841 independently made for WLAN controllers and WTPs. The CAPWAP 842 protocol should not affect the the independence of device 843 modificaitons. 845 Protocol Requirement: 847 A WTP vendor SHOULD be able to make modifications to hardware without 848 any WLAN controller vendor involvement. 850 Motivation and Protocol Benefits: 852 Independence in the type of hardware for WLAN equipment ensures that 853 new developments do not hamper protocol operation. 855 Relation to Problem Statement: 857 This requirement is based on WG discussions that have determined to 858 be important for CAPWAP. 860 5.1.14. Vendor Flexibility 862 Classification: General 864 Description: 866 The CAPWAP protocol must not be specified for a particular type of 867 wireless MAC design. It should be compatible with both local-MAC and 868 split-MAC WTPs. 870 Protocol Requirement: 872 The CAPWAP protocol MUST NOT limit WTP vendors in their choice of 873 local-MAC or split-MAC WTPs. It MUST be compatible with both types 874 of WTPs. 876 Motivation and Protocol Benefits: 878 This requirement is to ensure that WTP vendors have sufficient 879 flexibility in selecting the type of wireless MAC design that they 880 consider best for deployments. 882 Relation to Problem Statement: 884 This requirement is based on WG discussions that have determined to 885 be important for CAPWAP. 887 5.1.15. NAT Traversal 889 Classification: General 891 Description: 893 WLAN deployments may involve WTPs and the WLAN controller 894 communicating across NATs. The CAPWAP protocol must be capable of 895 operating across topologies that contain known NAT configurations. 896 It requires appropriate discovery and identification mechanisms for 897 NAT traversal. 899 Protocol Requirement: 901 The CAPWAP protocol MUST NOT prevent the operation of established 902 methods of NAT traversal. 904 Motivation and Protocol Benefits: 906 The wide-spread adoption of WLANs raises the possibility for WLAN 907 topologies containing NATs. It is important for the CAPWAP protocol 908 to be applicable within such topologies. This requirement aims to 909 make the CAPWAP protocol relevant for NAT traversal. 911 Relation to Problem Statement: 913 This requirement is based on WG discussions that have determined to 914 be important for CAPWAP. 916 5.2. Desirable Objectives 918 These objectives have been determined to be desirable for a CAPWAP 919 protocol but not mandatory. Realizing these objectives may help 920 improve control of WLANs but need not necessarily be required for all 921 networks or scenarios. 923 5.2.1. Multiple Authentication Mechanisms 925 Classification: Architecture 927 Description: 929 Shared WLAN infrastructure raise the issue of multiple authentication 930 mechanisms. This is because each logical group is likely to be 931 associated with different service providers or WLAN domains. As a 932 result, the authentication needs withing them will be different. 933 While CAPWAP is required to support IEEE 802.11i, it is also 934 necessary for it to support other authentication mechanisms. For 935 example, one logical group may use IEEE 802.11i while another may use 936 web authentication. CAPWAP must be able to operate in such shared 937 WLANs. 939 Protocol Requirement: 941 The CAPWAP protocol MUST support different authentication mechanisms 942 in addition to IEEE 802.11i. 944 Motivation and Protocol Benefits: 946 The benefit of supporting various authentication mechanisms is that 947 the protocol then becomes flexible for use in various deployments. 948 The protocol will therefore not mandate the use of any particular 949 mechanisms which may not be appropriate for a particular deployment. 951 Relation to Problem Statement: 953 This objective relates to the problem of management complexity. 954 Shared WLAN deployments simplifies management of large networks. 956 5.2.2. Support for Future Wireless Technologies 958 Classification: Architecture 960 Description: 962 The rapid pace of technology developments means that new advances 963 need to be catered for in current analyses. Among these is the 964 support for new wireless technologies within the CAPWAP protocol, 965 such as IEEE 802.16. The protocol should therefore not rely on 966 specifics of IEEE 802.11 technology. 968 In all cases where the CAPWAP protocol messages contain specific 969 layer 2 information elements, the definition of the protocol needs to 970 provide for extensibility so that these elements can be defined for 971 specific layer 2 wireless protocols. This may entail assigning a 972 layer 2 wireless protocol type and version field to the message PDU. 973 Examples of other wireless protocols that might be supported include 974 but are not limited to 802.16e, 802.15.x, etc. 976 Protocol Requirement: 978 CAPWAP protocol messages MUST be designed to be extensible for 979 specific layer 2 wireless technologies. It should not be limited to 980 the transport of elements relating to IEEE 802.11. 982 Motivation and Protocol Benefits: 984 There are many benefits to an extensible protocol. It allows for 985 application in different networks and provides greater scope. 986 Furthermore, service providers require WLAN solutions that will be 987 able to meet current and future market requirements. 989 Relation to Problem Statement: 991 The Problem Statement describes some of the advances taking place in 992 other standards bodies like the IEEE. It is important for the CAPWAP 993 protocol to reflect the advances and provide a framework in which 994 they can be supported. 996 5.2.3. Support for New IEEE Requirements 998 Classification: Architecture 1000 Description: 1002 The IEEE 802.11 APF Ad-Hoc Committee has reviewed IEEE 802.11 1003 functionality and has made more thorough definitions for them. The 1004 CAPWAP protocol must be able to incorporate these definitions with 1005 minimal change. Furthermore, a number of extensions for IEEE 802.11 1006 are currently being standardized. The CAPWAP protocol must also be 1007 able to incorporate these new extensions with minimal change. 1009 Protocol Requirement: 1011 The CAPWAP protocol MUST be openly designed to support new IEEE 1012 802.11 definitions and extensions. 1014 Motivation and Protocol Benefits: 1016 There are a number of advances being made within the IEEE regarding 1017 the functionality of IEEE 802.11 technology. Since this represents 1018 one of the major wireless technologies in use today, it will be 1019 beneficial for CAPWAP to incorporate the relevant new extensions. 1021 Relation to Problem Statement: 1023 The Problem Statement presents an overview of the task of the IEEE 1024 802.11 working group. This group is focussed on defining the 1025 functional architecture of WTPs and new extensions for it. It is 1026 necessary for the CAPWAP protocol to reflect these definitions and 1027 extensions. 1029 5.2.4. Interconnection Objective 1031 Classification: Architecture 1033 Description: 1035 Large scale WLAN deployments are likely to use a variety of 1036 interconnection technologies between different devices of the 1037 network. It should therefore be possible for the CAPWAP protocol to 1038 operate over various interconnection technologies. 1040 As a result of realizing this objective, the protocol will be capable 1041 of operation over both IPv4 and IPv6. It will also be designed such 1042 that it can operate within tightly administered networks, such as 1043 enterprise networks, or on open, public access networks. For 1044 example, VLAN tunnels can be used across different types of networks 1045 over which CAPWAP will operate. 1047 Protocol Requirement: 1049 The CAPWAP protocol MUST NOT be constrained to specific underlying 1050 transport mechanisms. 1052 Motivation and Protocol Benefits: 1054 The main aim of the CAPWAP protocol is to achieve interoperability 1055 among various WTPs and WLAN controllers. As such, the motivation for 1056 this requirement is for the protocol to be operable independent of 1057 underlying interconnection technologies. 1059 Relation to Problem Statement: 1061 The Problem Statement discusses the complexity of configuring large 1062 WLANs. The selection of available interconnection technologies for 1063 large-scale deployments further intensifies this complexity. This 1064 requirement avoids part of the complexity by advocating independence 1065 of the operational aspects of the protocol from from underlying 1066 transport. 1068 5.2.5. Access Control 1070 Classification: Operations 1072 Description: 1074 This objective focuses on the informational needs of WLAN access 1075 control and specifically the role of the CAPWAP protocol in 1076 transporting this information between WTPs and their WLAN controller. 1078 The following are some specific information aspects that need to be 1079 transported by the CAPWAP protocol; 1081 i. IEEE 802.11 association and authentication 1083 The association of wireless clients is distinct for initial and 1084 roaming cases. As a result, access control mechanisms requires 1085 specific contextual information regarding each case. Additionally, 1086 load balancing, QoS, security and congestion information in both 1087 wireless medium segments and switching segments need to be 1088 considered. 1090 ii. WTP Access Control 1092 In addition to controlling access for wireless clients, it is also 1093 necessary to control admission of new WTPs. Given the threat of 1094 rogue WTPs, it is important for CAPWAP to relay appropriate 1095 authentication information between new WTPs and the WLAN controller. 1097 Protocol Requirement: 1099 The CAPWAP protocol MUST be capable of exchanging information 1100 required for access control of WTPs and wireless terminals. 1102 Motivation and Protocol Benefits: 1104 Due to the scale of deployments in which CAPWAP will be employed, 1105 comprehensive access control is crucial. The effectiveness of access 1106 control in turn is affected by the information on which such control 1107 is based. As a result, this objective has critical relevance to a 1108 CAPWAP protocol. 1110 Relation to Problem Statement: 1112 This objective addresses the issue of access control in large WLANs. 1113 Broadly, it relates the problem of managing the complexity scale of 1114 such networks. With collective information of both switching and 1115 wireless medium segments, realizing this objective will help control 1116 and manage complexity. 1118 5.3. Non-Objectives 1120 The following objectives have been prioritized as non-objectives 1121 during the course of working group consultations. They have been 1122 prioritized so in the context of CAPWAP and its considerations. They 1123 may however be applicable in alternative contexts. 1125 5.3.1. Support for Non-CAPWAP WTPs 1127 Classification: Architecture 1129 Description: 1131 The CAPWAP protocol should provide an engine-mechanism to spring WTP 1132 auto-configuration and/or software version updates and should support 1133 integration with existing network management system. WLAN controller 1134 as a management agent is optional. 1136 If entities other than WLAN controllers manage some aspects of WTPs, 1137 such as software downloads, the CAPWAP protocol may be used for WTPs 1138 to notify WLAN controllers of any changes made by the other entities. 1140 Protocol Requirement: 1142 The CAPWAP protocol SHOULD be capable of recognizing legacy WTPs and 1143 existing network management systems. 1145 Motivation and Protocol Benefits: 1147 It is expected that in many cases, the centralized WLAN architecture 1148 will be deployed incrementally with legacy systems. In this regard, 1149 it is necessary for the protocol to be used in scenarios with mixed 1150 WLAN devices. 1152 Relation to Problem Statement: 1154 The Problem Statement highlights management complexity as a major 1155 issue with large WLANs. One part of this comlpexity can be related 1156 to the incremental deployment of centralized WLAN devices for which 1157 this objective is applicable. 1159 5.3.2. Technical Specifications 1161 Classification: General 1163 Description: 1165 The CAPWAP protocol must not require AC and WTP vendors to share 1166 technical specifications to establish compatibility. The protocol 1167 specifications alone must be sufficient for compatibility. 1169 Protocol Requirement: 1171 WTP vendors SHOULD NOT have to share technical specifications for 1172 hardware and software to AC vendors in order for interoperability to 1173 be achieved. 1175 Motivation and Protocol Benefits: 1177 It is beneficial for WLAN equipment vendors to refer to a single set 1178 of specifications while implementing the CAPWAP protocol. This helps 1179 to ease and quicken the development process. 1181 Relation to Problem Statement: 1183 This requirement is based on WG discussions that have determined to 1184 be important for CAPWAP. 1186 This objective has been prioritized as a non objective as it is a 1187 duplicate of the Protocol Specifications objective (Section 5.1.12). 1189 5.4. Operator Requirements 1191 The following objectives have been provided by network service 1192 operators. They represent the requirements from those ultimately 1193 deploying the CAPWAP protocol in their WLANs. 1195 5.4.1. AP Fast Handoff 1197 Classification: Operations 1199 Description: 1201 Network service operators consider handoffs crucially because of the 1202 mobile nature of their customers. In this regard, the CAPWAP 1203 protocol should not adversely affect AP fast handoff procedures. The 1204 protocol may support optimizations for fast handoff procedures so as 1205 to allow better support for real-time services during handoffs. 1207 Protocol Requirement: 1209 CAPWAP protocol operations MUST NOT impede or obstruct the efficacy 1210 of AP fast handoff procedures. 1212 6. Summary and Conclusion 1214 The objectives presented in this document address three main aspects 1215 of the CAPWAP protocol, namely; 1217 i. Architecture 1218 ii. Operations 1219 iii. Security 1221 These requirements are aimed to focus standardization efforts on a 1222 simple, interoperable protocol for managing large-scale WLANs. The 1223 architecture requirements specify the structural features of the 1224 protocol such as those relating to WTP types (local-MAC and split- 1225 MAC) and WTP structures (logical groups). The operations 1226 requirements address the functional aspects dealing with WTP 1227 configuration and management. Finally, the security requirements 1228 cover authentication and integrity aspects of protocol exchanges. 1230 The objectives have additionally been prioritized to reflect their 1231 immediate significance to the development and evaluation of an 1232 interoperable CAPWAP protocol. The priorities are Mandatory and 1233 Accepted, Desirable and Non-objectives. They reflect working group 1234 consensus on the effectiveness of the requirements in the context of 1235 protocol design. 1237 Additionally, this document includes requirements from network 1238 service operators that have been derived based on their experience in 1239 operating large- scale WLANs. 1241 The resulting requirements from this document will be used in 1242 conjunction with the CAPWAP Problem Statement [RFC3990] and CAPWAP 1243 Architecture Taxonomy [RFC4118] to develop and evalute an 1244 interoperable protocol for the control and provisioning of WTPs in 1245 large-scale WLANs. 1247 7. Security Considerations 1249 The CAPWAP framework highlights support for both local-MAC and split- 1250 MAC WTPs. In deployments where both types of WTPs are used, it is 1251 crucial to ensure that each be secured in consideration of their 1252 capabilities. The Architecture Taxonomy illustrates how different 1253 WTPs incorporate varying levels of functionalities. Development of 1254 the CAPWAP protocol should ensure that the deployment of both local- 1255 MAC and split-MAC WTPs within a single WLAN do not present loopholes 1256 for security compromises. 1258 In shared WLAN deployments made of a number of logical groups, 1259 traffic from each group needs to be mutually separated. So in 1260 addition to protocol related exchanges, data traffic from wireless 1261 terminals should also be segregated with respect to the logical 1262 groups to which they belong. It should not be possible for data or 1263 control traffic from one logical group to stray to or influence 1264 another logical group. 1266 The use of IEEE 802.11i over the centralized WLAN architecture allows 1267 for implementations in which the PMK is shared across WTPs. This 1268 raises the ambiguity between legitimate sharing and illegitimate 1269 copies. Wireless terminals may unknowingly fall prey to or exploit 1270 this ambiguity. The resolution of this issue is currently being 1271 evaluted by the IEEE 802 and IETF liaisons. 1273 The low-cost of launching attacks on WLANs makes the CAPWAP protocol 1274 a target. A first step in securing against any form of attacks is to 1275 continuously monitor the WLAN for conditions of potential threats 1276 from rogue WTPs or wireless terminals. For example, profiles for DoS 1277 and replay attacks need to be considered for the CAPWAP protocol to 1278 effectively monitor security conditions. 1280 The open environment of many WLAN deployments makes physical security 1281 breaches highly probable. Compromises resulting from theft and 1282 physical damage must be considered during protocol development. For 1283 instance, it should not be possible for a single compromised WTP to 1284 affect the WLAN as a whole. 1286 Considering asymmetric, non-mutual authentication between WTPs and 1287 WLAN controller, there is a risk of a rogue participant exploiting 1288 such an arrangement. It is preferrable to avoid non-mutual 1289 authentication. In some cases, the legitimacy of the protocol 1290 exchange participants may be verified externally, for example by 1291 means of physical containment within a close environment. Asymmetric 1292 authentication may be appropriate here without risk of security 1293 compromises. 1295 8. Acknowledgements 1297 The authors would like to thank the Working Group Chairs, Dorothy 1298 Gellert and Mahalingam Mani, for their support and patience with this 1299 document. We would also like to thank participants of the Working 1300 Group who have helped shape the objectives. In particular, the 1301 authors thank James Kempf, Pat Calhoun, Inderpreet Singh, Dan 1302 Harkins, T. Sridhar, Charles Clancy and Emek Sadot for their 1303 invaluable inputs. We also extend our gratitude to the IEEE 802.11 1304 Ad-Hoc Committee for their evaluation of the document. The authors 1305 also acknowledge the contributions from Meimei Dang, Satoshi Iino, 1306 Mikihito Sugiura and Dong Wang. 1308 9. References 1310 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1311 Requirement Levels", BCP 14, RFC 2119, March 1997. 1313 [RFC3990] O'Hara, B., Calhoun, P., and J. Kempf, "Configuration and 1314 Provisioning for Wireless Access Points (CAPWAP) Problem 1315 Statement", RFC 3990, February 2005. 1317 [RFC4118] Yang, L., Zerfos, P., and E. Sadot, "Architecture Taxonomy 1318 for Control and Provisioning of Wireless Access Points 1319 (CAPWAP)", RFC 4118, June 2005. 1321 Authors' Addresses 1323 Saravanan Govindan 1324 Panasonic Singapore Laboratories 1325 Block 1022, Tai Seng Industrial Estate 1326 #06-3530, Tai Seng Avenue 1327 Singapore 534 415 1328 Singapore 1330 Phone: +65 6550 5441 1331 Email: saravanan.govindan@sg.panasonic.com 1333 Zhonghui Yao 1334 Huawei Longgang Production Base 1335 Shenzhen 518 129 1336 P. R. China 1338 Phone: +86 755 2878 0808 1339 Email: yaoth@huawei.com 1341 Wenhui Zhou 1342 China Mobile 1343 53A, Xibianmen Ave, Xuanwu District 1344 Beijing 100 053 1345 P. R. China 1347 Phone: +86 10 6600 6688 ext.3061 1348 Email: zhouwenhui@chinamobile.com 1350 L. Lily Yang 1351 Intel Corp. 1352 JF3-206, 2111 NE 25th Ave. 1353 Hilsboro, OR 97124 1354 USA 1356 Phone: +1 503 264 8813 1357 Email: lily.l.yang@intel.com 1358 Hong Cheng 1359 Panasonic Singapore Laboratories 1360 Block 1022, Tai Seng Industrial Estate 1361 #06-3530, Tai Seng Avenue 1362 Singapore 534 415 1363 Singapore 1365 Phone: +65 6550 5447 1366 Email: hong.cheng@sg.panasonic.com 1368 Intellectual Property Statement 1370 The IETF takes no position regarding the validity or scope of any 1371 Intellectual Property Rights or other rights that might be claimed to 1372 pertain to the implementation or use of the technology described in 1373 this document or the extent to which any license under such rights 1374 might or might not be available; nor does it represent that it has 1375 made any independent effort to identify any such rights. Information 1376 on the procedures with respect to rights in RFC documents can be 1377 found in BCP 78 and BCP 79. 1379 Copies of IPR disclosures made to the IETF Secretariat and any 1380 assurances of licenses to be made available, or the result of an 1381 attempt made to obtain a general license or permission for the use of 1382 such proprietary rights by implementers or users of this 1383 specification can be obtained from the IETF on-line IPR repository at 1384 http://www.ietf.org/ipr. 1386 The IETF invites any interested party to bring to its attention any 1387 copyrights, patents or patent applications, or other proprietary 1388 rights that may cover technology that may be required to implement 1389 this standard. Please address the information to the IETF at 1390 ietf-ipr@ietf.org. 1392 Disclaimer of Validity 1394 This document and the information contained herein are provided on an 1395 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1396 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1397 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1398 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1399 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1400 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1402 Copyright Statement 1404 Copyright (C) The Internet Society (2005). This document is subject 1405 to the rights, licenses and restrictions contained in BCP 78, and 1406 except as set forth therein, the authors retain all their rights. 1408 Acknowledgment 1410 Funding for the RFC Editor function is currently provided by the 1411 Internet Society.