idnits 2.17.1 draft-ietf-capwap-objectives-03.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 1398. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1375. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1382. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1388. ** 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 == It seems as if not all pages are separated by form feeds - found 0 form feeds but 33 pages 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. ** There are 2 instances of lines with control characters in the document. 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 (June 17, 2005) is 6889 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 draft: draft-ietf-capwap-arch (ref. 'I-D.ietf-capwap-arch') ** Downref: Normative reference to an Informational draft: draft-ietf-capwap-problem-statement (ref. 'I-D.ietf-capwap-problem-statement') Summary: 8 errors (**), 0 flaws (~~), 4 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: December 19, 2005 ZH. Yao 5 Huawei 6 WH. Zhou 7 China Mobile 8 L. Yang 9 Intel 10 H. Cheng 11 Panasonic 12 June 17, 2005 14 Objectives for Control and Provisioning of Wireless Access Points 15 (CAPWAP) 16 draft-ietf-capwap-objectives-03.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 December 19, 2005. 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 . . . . . . . . . . . . . . . . . . . 22 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 . . . . . . . . . . . . . . . 27 89 5.4 Operator Requirements . . . . . . . . . . . . . . . . . . 28 90 5.4.1 AP Fast Handoff . . . . . . . . . . . . . . . . . . . 28 91 6. Summary and Conclusion . . . . . . . . . . . . . . . . . . . 29 92 7. Security Considerations . . . . . . . . . . . . . . . . . . 30 93 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31 94 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 31 96 Intellectual Property and Copyright Statements . . . . . . . 33 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 [I-D.ietf-capwap-arch]. 107 Additionally, the following terms are defined; 109 Centralized WLAN: A WLAN based on the centralized WLAN Architecture 110 [I-D.ietf-capwap-arch]. 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 [I-D.ietf-capwap-problem-statement]. 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 [I-D.ietf-capwap-arch] is a 154 result of this survey in which major WLAN architecture families are 155 classified. Broadly, these are the autonomous, centralized WLAN and 156 distributed 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 Motivation and Protocol Benefits: 253 Commercial realities necessitate that WLANs be manageable in terms of 254 its logical groups. This allows separation of logical services and 255 underlying infrastructure management. A protocol that realizes this 256 need ensures simlper and cost effective WLANs, which directly address 257 the requirements of network service operators. 259 Relation to Problem Statement: 261 This objective addresses the problem of management complexity in 262 terms of costs. Cost complexity is reduced by sharing WLAN 263 deployments. Consequently, deployment and management cost- 264 efficiencies are realized. 266 5.1.2 Support for Traffic Separation 268 Classification: Operations 270 Description: 272 The centralized WLAN architecture simplifies complexity associated 273 with large-scale deployments by consolidating portions of wireless 274 MAC functionality at a central WLAN controller and distributing the 275 remaining across WTPs. As a result, WTPs and WLAN controller 276 exchange control and data information between them. This objective 277 states that control and data aspects of the exchanges be mutually 278 separated for further simplicity. This will allow solutions for each 279 type of exchange to be independently optimized. 281 Furthermore, in the context of shared WLAN deployments, the mutual 282 separation of control and data also addresses security concerns. In 283 particular, given the likelihood of different logical groups, such as 284 those established by different virtual APs, being managed by 285 different administrators, separation of control and data is a first 286 step towards individually containing and securing the logical groups. 288 It is also important to ensure that traffic from each logical group 289 be mutually separated to maintain the integrity and independence of 290 the logical groups. 292 Protocol Requirement: 294 The CAPWAP Protocol MUST define transport control messages such that 295 the transport of control messages is separate from the transport of 296 data messages. 298 Motivation and Protocol Benefits: 300 The aim of separating data and control aspects of the protocol is to 301 simplify the protocol. It also allows for the flexibility of 302 addressing each type of traffic in the most appropriate manner. 304 Furthermore, this requirement will help remotely located WTPs to 305 handle data traffic in alternative ways without the need for 306 forwarding them across a wide network to the WLAN controller. 308 Separation of WTP control and data also aids in the secure 309 realization of shared WLAN deployments. 311 Relation to Problem Statement: 313 Broadly, this objective relates to the challenge of managing 314 complexity in large-scale WLANs. The requirement for traffic 315 separation simplifies control as this is separated from the task of 316 data transport. 318 5.1.3 Wireless Terminal Transparency 320 Classification: Operations 322 Description: 324 The CAPWAP protocol is applicable between a centralized WLAN 325 controller and a number of WTPs, i.e. it affects only the switching 326 segment of the centralized WLAN architecture. Its operations should 327 therefore be independent of the wireless terminal. Wireless 328 terminals should not be required to be aware of the existence of the 329 CAPWAP protocol. 331 Protocol Requirement: 333 Wireless terminals MUST NOT be required to recognize or be aware of 334 the CAPWAP protocol. 336 Motivation and Protocol Benefits: 338 IEEE 802.11 based wireless terminals are mature and widely available. 339 It would be beneficial for CAPWAP not to impose new requirements on 340 these wireless terminals. In effect, this requirement ensures that 341 the setup cost of the protocol is reduced as the numerous existing 342 wireless terminals need not be altered. 344 Relation to Problem Statement: 346 The Problem Statement highlights the challenges faced by large WLANs 347 consisting of many WTPs. It does not refer to the operations of 348 wireless terminals and this objective emphasizes the independence. 350 5.1.4 Configuration Consistency 352 Classification: Operations 354 Description: 356 WLANs in the CAPWAP framework contain numerous WTPs, each of which 357 need to be configured and managed in a consistent manner. The main 358 concern in ensuring consistency is availability of appropriate 359 information corresponding to WTP configuration states. So 360 configuration consistency can be achieved by providing the 361 centralized WLAN controller with regular updates on the state of WTP 362 operations. The centralized WLAN controller can in turn apply 363 information from the regular updates to ensure consistently among the 364 WTPs. 366 Protocol Requirement: 368 The CAPWAP protocol MUST include support for regular exchanges of 369 state information between WTPs and WLAN controller. Examples of 370 state information include WTP processing load and memory utilization. 372 Motivation and Protocol Benefits: 374 A protocol that provides access to regular state information can in 375 turn be used to enhance WLAN configuration and performance. The 376 CAPWAP protocol will be better equipped to address configuration 377 related problems with the regularly available state information. So 378 with greater state information, control and management operations can 379 be improved. 381 Relation to Problem Statement: 383 One of the major challenges described in the Problem Statement is 384 that of maintaining consistent configuration across the numerous WTPs 385 of a WLAN. This objective addresses the fundamental issue behind 386 this - availability of timely state information. 388 5.1.5 Firmware Trigger 390 Classification: Operations 392 Description: 394 One specific aspect of configuration consistency is the firmware used 395 by various WTPs. The scale of large WLANs introduces possibilities 396 for variations in the firmware used among WTPs. This objective 397 highlights the need for the CAPWAP protocol to trigger the delivery 398 of appropriate versions of firmware to WTPs. The actual delivery of 399 firmware need not be inclusive to the protocol. 401 Protocol Requirement: 403 The CAPWAP protocol MUST support a trigger for delivery of firmware 404 updates. 406 Motivation and Protocol Benefits: 408 The CAPWAP protocol interfaces many WTPs to a centralized WLAN 409 controller. Firmware distribution allows these interfaces to be 410 compatible. This in turn results in consistent configuration and 411 simplified management. So the protocol benefits by including 412 triggers for the distribution of firmware updates. 414 Relation to Problem Statement: 416 Inconsistencies in the configuration of WTPs has been identified as a 417 major challenge for large-scale WTPs. This objectives helps overcome 418 the challenge by providing for a way for the CAPWAP protocol to 419 initiate delivery of firmware updates that are compatible among all 420 WTPs. 422 5.1.6 Monitoring and Exchange of System-wide Resource State 424 Classification: Operations 426 Description: 428 The centralized WLAN architecture is made up of a switching segment 429 and wireless medium segment. In the switching segment, network 430 congestion, WTP status and firmware information have to be monitored. 431 In the wireless medium segment, the dynamic nature of the medium 432 itself has to be monitored. Overall, there are also various 433 statistics need to be considered for efficient WLAN operation. 435 The CAPWAP protocol should be capable of monitoring the various 436 information sources and deliver the resulting information to the 437 relevant WLAN devices - either WTPs or WLAN controller. Moreover, 438 given the relationship among information sources, the CAPWAP protocol 439 should combine state information from them. For example, statistics 440 information and status signals from WTPs may be merged before being 441 exchanged. 443 Examples of statistics information that the CAPWAP protocol should 444 monitor and exchange include; congestion state, interference levels, 445 loss rates and various delay factors. 447 Protocol Requirement: 449 The CAPWAP protocol MUST allow for the exchange of statistics, 450 congestion and other WLAN state information. 452 Motivation and Protocol Benefits: 454 The effectivness of a protocol is based on the relevance of 455 information on which it operates. This requirement for resource 456 monitoring and exchange can provide the appropriate information to 457 the CAPWAP protocol. 459 Relation to Problem Statement: 461 The Problem Statement highlights the challenge of dealing with large 462 numbers of WTPs and the dynamic nature of the wireless medium. 463 Information on the state of WTPs and the medium is important to deal 464 with them effectively. So this objective relates to the problem of 465 managing consistency in large WLANs. 467 5.1.7 Resource Control Objective 469 Classification: Operations 471 Description: 473 Integral to the success of any wireless network system is the 474 performance and quality it can offer its subscribers. Since CAPWAP 475 based WLANs combine a switching segment and a wireless medium 476 segment, performance and quality need to be coordinated across both 477 of these segments. So QoS performance must be enforced system-wide. 479 This objective highlights QoS over the entire WLAN system which 480 includes the switching segment and the wireless medium segment. 481 Given the fundamental differences between the two, it is likely that 482 there are alternate QoS mechanisms between WTPs and wireless service 483 subscribers and between WTPs and WLAN controllers. For instance, the 484 former will be based on IEEE 802.11e while the latter will be an 485 alternative. So resources need to be adjusted in a coordinated 486 fashion over both segments. The CAPWAP protocol should ensure that 487 these adjustments are appropriately exchanged between WLAN 488 controllers and WTPs. 490 In addition to IEEE 802.11e, there are a number of other IEEE 802.11 491 Task Groups that may affect network resources. These include IEEE 492 802.11 TGk, TGu and TGv, which are currently under progress. CAPWAP 493 should therefore not be restricted to IEEE 802.11e based mapping. 495 Protocol Requirement: 497 The CAPWAP protocol MUST map the IEEE 802.11e QoS priorities to 498 equivalent QoS priorities across the switching and wireless medium 499 segments 501 Motivation and Protocol Benefits: 503 A protocol that addresses QoS aspects of WLAN systems will deliver 504 high performance thereby being beneficial for subscribers and for 505 resource utilization efficiency. Since CAPWAP deals with WTPs 506 directly and with the wireless medium indirectly, both of these must 507 be considered for performance. 509 For the wireless medium segment, QoS aspects in the protocol enable 510 high quality communications within the domain of a WLAN controller. 511 Since each domain generally covers an enterprise or a group of 512 service providers, such protocol performance has wide-ranging 513 effects. 515 Within the switching segment of CAPWAP, a QoS-enabled protocol 516 minimizes the adverse effects of dynamic traffic characteristics so 517 as to ensure system-wide performance. 519 Relation to Problem Statement: 521 QoS control is critical to large WLANs and relates to a number of 522 aspects. In particular, this objective can help address the problem 523 of managing dynamic conditions of the wireless medium. 525 Furthermore, traffic characteristics in large scale WLANs are 526 constantly varying. So network utilization becomes inefficient and 527 user experience is unpredictable. 529 The interaction and coordination between the two aspects of system- 530 wide QoS is therefore critical for performance. 532 5.1.8 CAPWAP Protocol Security 534 Classification: Security 536 Description: 538 This objective addresses the security of the CAPWAP protocol. 540 The CAPWAP protocol MUST first provide for the participating entities 541 - WLAN controller and WTPs - to be explicitly mutually authenticated. 542 This is to ensure that rogue elements do not gain access to the WLAN 543 system. Rogue WTPs should not be allowed to breach legitimate WLANs 544 and at the same time rogue WLAN controllers should not be allowed to 545 gain control of legitimate WTPs. For example, WTPs may need to 546 regularly renew their authentication state with the WLAN controller 547 and similarly for WLAN controllers. 549 If authentication is performed via an authenticated key exchange, 550 future knowledge of derived keys is not sufficient for 551 authentication. 553 Any session keys used between the WLAN controller and WTP MUST be 554 mutually derived using entropy contributed by both parties. This 555 ensures that no one party has control over the resulting session 556 keys. 558 Once WTPs and WLAN controller have been mutually authenticated, 559 information exchanges between them must be secured against various 560 security threats. This should cover illegitimate modifications to 561 protocol exchanges, eavesdropping and DoS attacks, among other 562 potential compromises. So the protocol must be provide 563 confidentiality, integrity and authenticity for those exchanges. 565 As a result of realizing this objective it should not be possible for 566 individual WTP breaches to affect the security of the WLAN as a 567 whole. So WTP mis-use will be protected against. 569 Additionally, the key establishment protocol for authentication and 570 securing CAPWAP exchanges must be designed to minimize the 571 possibility of future compromises after the keys are established. 573 CAPWAP MUST NOT prevent the use of asymmetric authentication. The 574 security considerations of such asymmetric authentication are 575 described in the Security Considerations section. 577 Protocol Requirement: 579 The CAPWAP protocol MUST support mutual authentication of WTPs and 580 the centralized controller. It must also ensure that information 581 exchanges between them are secured. 583 Motivation and Protocol Benefits: 585 WLANs are increasingly deployed in critical aspects of enterprise and 586 consumer networks. In these contexts, protocol security is crucial 587 to assure the privacy and integrity expected from network 588 administrators and end-users. So securing the CAPWAP protocol has 589 direct benefits in addressing these concerns. 591 In many cases, the network path between a WTP and WLAN controller 592 contains untrusted links. Such links could be leveraged by rogue 593 WTPs to gain access to the WLAN system. They could also be used by 594 rogue WLAN controllers to gain control of legitimate WTPs and their 595 associated terminals to either redirect or compromise terminal 596 traffic. These security concerns can be mitigated with this 597 objective. 599 Relation to Problem Statement: 601 Security problems in large-scale WLANs are detailed in the Problem 602 Statement. These include complications arising from rogue WTPs and 603 compromised interfaces between WTPs and WLAN controller. The 604 requirement for protocol security addresses these problems and 605 highlights the importance of protecting against them. 607 5.1.9 System-wide Security 609 Classification: Security 611 Description: 613 The emphasis of this objective is on the security threats external to 614 the centralized CAPWAP segment of a WLAN system. The focus is 615 therefore on rogue wireless clients and other illegitimate wireless 616 interferences. There are a number of specific external threats that 617 need to be addressed within the CAPWAP framework. 619 i. PMK Sharing 621 One aspect of this objective relates to recent discussions on PMK 622 sharing in the CAPWAP framework. This objective highlights the need 623 to prevent exploitation of this ambiguity by rogue wireless clients. 624 It is to ensure that any ambiguities arising from the CAPWAP 625 framework are not cause for security breaches. 627 Protocol Requirement: 629 The design of the CAPWAP protocol MUST NOT allow for any compromises 630 to the WLAN system by external entities. 632 Motivation and Protocol Benefits: 634 The external threats to the centralized WLAN architecture become 635 increasingly crucial given the low cost of wireless clients. Since 636 it is relatively inexpensive for rogue individuals to mount attacks, 637 it is important that WLAN systems are protected against them. 638 Adequate mechanisms to thwart such external threats will be of 639 tremendous benefit to the WLAN systems controlled and managed with 640 the CAPWAP protocol. 642 Relation to Problem Statement: 644 This objective is based on the security needs highlighted in the 645 Problem Statement. Specifically, the Problem Statement discusses the 646 effects of the shared wireless medium. This represents the external 647 aspects of the CAPWAP framework from which certain threats can arise. 648 The system-wide security objective addresses such threats in relation 649 to the Problem Statement. 651 5.1.10 IEEE 802.11i Considerations 653 Classification: Operations 655 Description: 657 The CAPWAP protocol must support authentication in the centralized 658 WLAN architecture in which the authenticator and encryption points 659 can be located on distinct entities, i.e. WLAN controller or WTP. 660 The Architecture Taxonomy illustrates a number of variants, in both 661 local-MAC and split-MAC designs, in which the authenticator is 662 located at the WLAN controller and the encryption points are at the 663 WTPs. The CAPWAP protocol must be applicable to these variants and 664 allow authentication mechanisms and their consistituent processes to 665 be operable in these cases. 667 An important issue to consider in this case is the exchange of key 668 information when authenticator and encryption points are located on 669 distinct entities. For example, consider the case where IEEE 802.11i 670 is used in a WLAN in which the WLAN controller realizes the 671 authenticator, some WTPs realize encryption (possibly local-MAC WTPs) 672 and other WTPs rely on the WLAN controller for encryption (possibly 673 split-MAC WTPs). 675 Here, CAPWAP will first need to identify the location of the 676 authenticator and encryption points between each WLAN controller-WTP 677 pair. This will likely be part of the initial WTP configuration. 678 Subsequently, the WTPs which realize encryption will need CAPWAP to 679 exchange key information with the authenticator at the WLAN 680 controller. For the WTPs which do not realize encryption, CAPWAP 681 need to adapt its control to bypass the key exchange phase. 683 Clearly, the centralized WLAN architecture presents a different 684 platform for authentication mechanisms compared to legacy WLANs in 685 which a WTP realized both authenticator and encryption roles. So 686 this objective highlights the need for CAPWAP to support 687 authentication and key management in the centralized WLAN 688 architecture. 690 Protocol Requirement: 692 The CAPWAP protocol MUST determine the exact structure of the 693 centralized WLAN architecture in which authentication needs to be 694 supported, i.e. the location of major authentication components. 695 This may be achieved during WTP initialization where major 696 capabilities are distinguished. 698 The protocol must allow for the exchange of key information when 699 authenticator and encryption roles are located in distinct entities. 701 Motivation and Protocol Benefits: 703 The immediate focus of CAPWAP is on supporting IEEE 802.11 based 704 WLANs. As such, it is necessary for the protocol to recognize the 705 major distinction in WLAN design with respect to IEEE 802.11i 706 authenticator and encryption points. This represents a significant 707 variation that has been highlighted in the Architecture Taxonomy. 708 The CAPWAP protocol benefits by accommodating such a major 709 consideration fro IEEE 802.11i. 711 These requirements will be common for all authentication mechanisms 712 over the centralized WLAN architecture. So they are applicable to 713 IEEE 802.11i, UMA and other mechanisms. 715 Relation to Problem Statement: 717 The Problem Statement highlights the availability of different WTP 718 designs and the need to ensure interoperability among them. In this 719 regard, operational changes occuring due to the separation of the 720 IEEE 802.11i authenticator and encryption points need to be 721 accommated within the CAPWAP protocol. 723 5.1.11 Interoperability Objective 725 Classification: Architecture 727 Description: 729 Two major designs of the centralized WLAN architecture are local-MAC 730 and split-MAC. With the focusing of standardization efforts on these 731 two designs, it is crucial to ensure mutual interoperation among 732 them. 734 This objective for the CAPWAP protocol is to ensure that WTPs of both 735 local-MAC and split-MAC architecture designs are capable of 736 interoperation within a single WLAN. Consequently, a single WLAN 737 controller will be capable of controlling both types of WTPs using a 738 single CAPWAP protocol. Integral support for these designs comprises 739 a number of protocol aspects. 741 i. Capability negotiations between WLAN controller and WTPs 743 WTP designs differ in the degree of IEEE 802.11 MAC functionalities 744 that each type of WTP realizes. The major distinctions, split-MAC 745 and local-MAC differ in the processing of IEEE 802.11 MAC frames. In 746 this regard, the CAPWAP protocol should include functionality that 747 allows for negotiationg of significant capabilities between WTPs and 748 WLAN controller. 750 As a first step, such negotiations could cover the type of WTP - 751 split-MAC or local-MAC - as this provides substantial information on 752 their respective capabilities. 754 ii. Establishment of alternative interfaces 756 The capability differences among different WTPs essentially equates 757 to alternative interfaces with a WLAN controller. So the CAPWAP 758 protocol should be capable of adapting its operations to the major 759 different interfaces. In a first case, this would include 760 accommodating capability differences between local-MAC and split-MAC 761 WTPs. 763 The definition of these interfaces in terms of finer granularity of 764 functionalities will be based on AP functionality documents produced 765 by the IEEE 802.11 AP Functionality (APF) Ad-Hoc Committee. 767 Protocol Requirement: 769 The CAPWAP protocol MUST include sufficient capabilities negotiations 770 to distinguish between major types of WTPs. 772 Motivation and Protocol Benefits: 774 The benefits of realizing this architecture objective are both 775 technical and practical. First, there are substantial overlaps in 776 the control operations of local-MAC and split-MAC architecture 777 designs. The Architecture Taxonomy tabulates major common features 778 of the two designs. As a result, it is technically practical to 779 devise a single protocol that manages both types of devices. 781 Next, the ability to operate a CAPWAP protocol for both types of 782 architectural designs enhances its practical prospects as it will 783 have wider appeal. 785 Furthermore, the additional complexity resulting from such 786 alternative interfaces is marginal. Consequently, the benefits of 787 this objective will far outweigh any cost of realizing it. 789 Relation to Problem Statement: 791 The objective for supporting both local-MAC and split-MAC WTPs is 792 fundamental to addressing the Problem Statement. It forms the basis 793 for those problems to be uniformly addressed across the major WLAN 794 architectures. This is the ultimate aim of standardization efforts. 795 The realization of this objective will ensure the development of a 796 comprehensive set of mechanisms that address the challenges of large- 797 scale WLAN deployments. 799 5.1.12 Protocol Specifications 801 Classification: General 803 Description: 805 WLAN equipment vendors require sufficient details from protocol 806 specifications so that implementing them will allow for compatibility 807 with other equipment that run the same protocol. In this light, it 808 is important for the CAPWAP protocol specifications to be reasonably 809 complete for realization. 811 Protocol Requirement: 813 Any WTP or WLAN controller vendor or any person MUST be able to 814 implement the CAPWAP protocol from the specification itself and by 815 that it is required that all such implementations do interoperate. 817 Motivation and Protocol Benefits: 819 It is beneficial for WLAN equipment vendors to refer to a single set 820 of specifications while implementing the CAPWAP protocol. This helps 821 to ease and quicken the development process. 823 Relation to Problem Statement: 825 This requirement is based on WG discussions that have determined to 826 be important for CAPWAP. 828 5.1.13 Vendor Independence 830 Classification: General 832 Description: 834 Rapid developments in WLAN technologies results in equipment vendors 835 constantly modifying their devices. In many cases, developments are 836 independently made for WLAN controllers and WTPs. The CAPWAP 837 protocol should not affect the the independence of device 838 modificaitons. 840 Protocol Requirement: 842 A WTP vendor SHOULD be able to make modifications to hardware without 843 any WLAN controller vendor involvement. 845 Motivation and Protocol Benefits: 847 Independence in the type of hardware for WLAN equipment ensures that 848 new developments do not hamper protocol operation. 850 Relation to Problem Statement: 852 This requirement is based on WG discussions that have determined to 853 be important for CAPWAP. 855 5.1.14 Vendor Flexibility 857 Classification: General 859 Description: 861 The CAPWAP protocol must not be specified for a particular type of 862 wireless MAC design. It should be compatible with both local-MAC and 863 split-MAC WTPs. 865 Protocol Requirement: 867 The CAPWAP protocol MUST NOT limit WTP vendors in their choice of 868 local-MAC or split-MAC WTPs. It MUST be compatible with both types 869 of WTPs. 871 Motivation and Protocol Benefits: 873 This requirement is to ensure that WTP vendors have sufficient 874 flexibility in selecting the type of wireless MAC design that they 875 consider best for deployments. 877 Relation to Problem Statement: 879 This requirement is based on WG discussions that have determined to 880 be important for CAPWAP. 882 5.1.15 NAT Traversal 884 Classification: General 886 Description: 888 WLAN deployments may involve WTPs and the WLAN controller 889 communicating across NATs. The CAPWAP protocol must be capable of 890 operating across topologies that contain known NAT configurations. 891 It requires appropriate discovery and identification mechanisms 892 NAT traversal. 894 Protocol Requirement: 896 The CAPWAP protocol MUST NOT prevent the operation of established 897 methods of NAT traversal. 899 Motivation and Protocol Benefits: 901 The wide-spread adoption of WLANs raises the possibility for WLAN 902 topologies containing NATs. It is important for the CAPWAP protocol 903 to be applicable within such topologies. This requirement aims to 904 make the CAPWAP protocol relevant for NAT traversal. 906 Relation to Problem Statement: 908 This requirement is based on WG discussions that have determined to 909 be important for CAPWAP. 911 5.2 Desirable Objectives 913 These objectives have been determined to be desirable for a CAPWAP 914 protocol but not mandatory. Realizing these objectives may help 915 improve control of WLANs but need not necessarily be required for all 916 networks or scenarios. 918 5.2.1 Multiple Authentication Mechanisms 920 Classification: Architecture 922 Description: 924 Shared WLAN infrastructure raise the issue of multiple authentication 925 mechanisms. This is because each logical group is likely to be 926 associated with different service providers or WLAN domains. As a 927 result, the authentication needs withing them will be different. 928 While CAPWAP is required to support IEEE 802.11i, it is also 929 necessary for it to support other authentication mechanisms. For 930 example, one logical group may use IEEE 802.11i while another may use 931 web authentication. CAPWAP must be able to operate in such shared 932 WLANs. 934 Protocol Requirement: 936 The CAPWAP protocol MUST support different authentication mechanisms 937 in addition to IEEE 802.11i. 939 Motivation and Protocol Benefits: 941 The benefit of supporting various authentication mechanisms is that 942 the protocol then becomes flexible for use in various deployments. 943 The protocol will therefore not mandate the use of any particular 944 mechanisms which may not be appropriate for a particular deployment. 946 Relation to Problem Statement: 948 This objective relates to the problem of management complexity. 949 Shared WLAN deployments simplifies management of large networks. 951 5.2.2 Support for Future Wireless Technologies 953 Classification: Architecture 955 Description: 957 The rapid pace of technology developments means that new advances 958 need to be catered for in current analyses. Among these is the 959 support for new wireless technologies within the CAPWAP protocol, 960 such as IEEE 802.16. The protocol should therefore not rely on 961 specifics of IEEE 802.11 technology. 963 In all cases where the CAPWAP protocol messages contain specific 964 layer 2 information elements, the definition of the protocol needs to 965 provide for extensibility so that these elements can be defined for 966 specific layer 2 wireless protocols. This may entail assigning a 967 layer 2 wireless protocol type and version field to the message PDU. 968 Examples of other wireless protocols that might be supported include 969 but are not limited to 802.16e, 802.15.x, etc. 971 Protocol Requirement: 973 CAPWAP protocol messages MUST be designed to be extensible for 974 specific layer 2 wireless technologies. It should not be limited to 975 the transport of elements relating to IEEE 802.11. 977 Motivation and Protocol Benefits: 979 There are many benefits to an extensible protocol. It allows for 980 application in different networks and provides greater scope. 981 Furthermore, service providers require WLAN solutions that will be 982 able to meet current and future market requirements. 984 Relation to Problem Statement: 986 The Problem Statement describes some of the advances taking place in 987 other standards bodies like the IEEE. It is important for the CAPWAP 988 protocol to reflect the advances and provide a framework in which 989 they can be supported. 991 5.2.3 Support for New IEEE Requirements 993 Classification: Architecture 995 Description: 997 The IEEE 802.11 APF Ad-Hoc Committee has reviewed IEEE 802.11 998 functionality and has made more thorough definitions for them. The 999 CAPWAP protocol must be able to incorporate these definitions with 1000 minimal change. Furthermore, a number of extensions for IEEE 802.11 1001 are currently being standardized. The CAPWAP protocol must also be 1002 able to incorporate these new extensions with minimal change. 1004 Protocol Requirement: 1006 The CAPWAP protocol MUST be openly designed to support new IEEE 1007 802.11 definitions and extensions. 1009 Motivation and Protocol Benefits: 1011 There are a number of advances being made within the IEEE regarding 1012 the functionality of IEEE 802.11 technology. Since this represents 1013 one of the major wireless technologies in use today, it will be 1014 beneficial for CAPWAP to incorporate the relevant new extensions. 1016 Relation to Problem Statement: 1018 The Problem Statement presents an overview of the task of the IEEE 1019 802.11 working group. This group is focussed on defining the 1020 functional architecture of WTPs and new extensions for it. It is 1021 necessary for the CAPWAP protocol to reflect these definitions and 1022 extensions. 1024 5.2.4 Interconnection Objective 1026 Classification: Architecture 1028 Description: 1030 Large scale WLAN deployments are likely to use a variety of 1031 interconnection technologies between different devices of the 1032 network. It should therefore be possible for the CAPWAP protocol to 1033 operate over various interconnection technologies. 1035 As a result of realizing this objective, the protocol will be capable 1036 of operation over both IPv4 and IPv6. It will also be designed such 1037 that it can operate within tightly administered networks, such as 1038 enterprise networks, or on open, public access networks. For 1039 example, VLAN tunnels can be used across different types of networks 1040 over which CAPWAP will operate. 1042 Protocol Requirement: 1044 The CAPWAP protocol MUST NOT be constrained to specific underlying 1045 transport mechanisms. 1047 Motivation and Protocol Benefits: 1049 The main aim of the CAPWAP protocol is to achieve interoperability 1050 among various WTPs and WLAN controllers. As such, the motivation for 1051 this requirement is for the protocol to be operable independent of 1052 underlying interconnection technologies. 1054 Relation to Problem Statement: 1056 The Problem Statement discusses the complexity of configuring large 1057 WLANs. The selection of available interconnection technologies for 1058 large-scale deployments further intensifies this complexity. This 1059 requirement avoids part of the complexity by advocating independence 1060 of the operational aspects of the protocol from from underlying 1061 transport. 1063 5.2.5 Access Control 1065 Classification: Operations 1067 Description: 1069 This objective focuses on the informational needs of WLAN access 1070 control and specifically the role of the CAPWAP protocol in 1071 transporting this information between WTPs and their WLAN controller. 1073 The following are some specific information aspects that need to be 1074 transported by the CAPWAP protocol; 1076 i. IEEE 802.11 association and authentication 1078 The association of wireless clients is distinct for initial and 1079 roaming cases. As a result, access control mechanisms requires 1080 specific contextual information regarding each case. Additionally, 1081 load balancing, QoS, security and congestion information in both 1082 wireless medium segments and switching segments need to be 1083 considered. 1085 ii. WTP Access Control 1087 In addition to controlling access for wireless clients, it is also 1088 necessary to control admission of new WTPs. Given the threat of 1089 rogue WTPs, it is important for CAPWAP to relay appropriate 1090 authentication information between new WTPs and the WLAN controller. 1092 Protocol Requirement: 1094 The CAPWAP protocol MUST be capable of exchanging information 1095 required for access control of WTPs and wireless terminals. 1097 Motivation and Protocol Benefits: 1099 Due to the scale of deployments in which CAPWAP will be employed, 1100 comprehensive access control is crucial. The effectiveness of access 1101 control in turn is affected by the information on which such control 1102 is based. As a result, this objective has critical relevance to a 1103 CAPWAP protocol. 1105 Relation to Problem Statement: 1107 This objective addresses the issue of access control in large WLANs. 1108 Broadly, it relates the problem of managing the complexity scale of 1109 such networks. With collective information of both switching and 1110 wireless medium segments, realizing this objective will help control 1111 and manage complexity. 1113 5.3 Non-Objectives 1115 The following objectives have been prioritized as non-objectives 1116 during the course of working group consultations. They have been 1117 prioritized so in the context of CAPWAP and its considerations. They 1118 may however be applicable in alternative contexts. 1120 5.3.1 Support for Non-CAPWAP WTPs 1122 Classification: Architecture 1124 Description: 1126 The CAPWAP protocol should provide an engine-mechanism to spring WTP 1127 auto-configuration and/or software version updates and should support 1128 integration with existing network management system. WLAN controller 1129 as a management agent is optional. 1131 If entities other than WLAN controllers manage some aspects of WTPs, 1132 such as software downloads, the CAPWAP protocol may be used for WTPs 1133 to notify WLAN controllers of any changes made by the other entities. 1135 Protocol Requirement: 1137 The CAPWAP protocol SHOULD be capable of recognizing legacy WTPs and 1138 existing network management systems. 1140 Motivation and Protocol Benefits: 1142 It is expected that in many cases, the centralized WLAN architecture 1143 will be deployed incrementally with legacy systems. In this regard, 1144 it is necessary for the protocol to be used in scenarios with mixed 1145 WLAN devices. 1147 Relation to Problem Statement: 1149 The Problem Statement highlights management complexity as a major 1150 issue with large WLANs. One part of this comlpexity can be related 1151 to the incremental deployment of centralized WLAN devices for which 1152 this objective is applicable. 1154 5.3.2 Technical Specifications 1156 Classification: General 1158 Description: 1160 The CAPWAP protocol must not require AC and WTP vendors to share 1161 technical specifications to establish compatibility. The protocol 1162 specifications alone must be sufficient for compatibility. 1164 Protocol Requirement: 1166 WTP vendors SHOULD NOT have to share technical specifications for 1167 hardware and software to AC vendors in order for interoperability to 1168 be achieved. 1170 Motivation and Protocol Benefits: 1172 It is beneficial for WLAN equipment vendors to refer to a single set 1173 of specifications while implementing the CAPWAP protocol. This helps 1174 to ease and quicken the development process. 1176 Relation to Problem Statement: 1178 This requirement is based on WG discussions that have determined to 1179 be important for CAPWAP. 1181 This objective has been prioritized as a non objective as it is a 1182 duplicate of the Protocol Specifications objective (Section 5.1.12). 1184 5.4 Operator Requirements 1186 The following objectives have been provided by network service 1187 operators. They represent the requirements from those ultimately 1188 deploying the CAPWAP protocol in their WLANs. 1190 5.4.1 AP Fast Handoff 1192 Classification: Operations 1194 Description: 1196 Network service operators consider handoffs crucially because of the 1197 mobile nature of their customers. In this regard, the CAPWAP 1198 protocol should not adversely affect AP fast handoff procedures. The 1199 protocol may support optimizations for fast handoff procedures so as 1200 to allow better support for real-time services during handoffs. 1202 Protocol Requirement: 1204 CAPWAP protocol operations MUST NOT impede or obstruct the efficacy 1205 of AP fast handoff procedures. 1207 6. Summary and Conclusion 1209 The objectives presented in this document address three main aspects 1210 of the CAPWAP protocol, namely; 1212 i. Architecture 1213 ii. Operations 1214 iii. Security 1216 These requirements are aimed to focus standardization efforts on a 1217 simple, interoperable protocol for managing large-scale WLANs. The 1218 architecture requirements specify the structural features of the 1219 protocol such as those relating to WTP types (local-MAC and split- 1220 MAC) and WTP structures (logical groups). The operations 1221 requirements address the functional aspects dealing with WTP 1222 configuration and management. Finally, the security requirements 1223 cover authentication and integrity aspects of protocol exchanges. 1225 The objectives have additionally been prioritized to reflect their 1226 immediate significance to the development and evaluation of an 1227 interoperable CAPWAP protocol. The priorities are Mandatory and 1228 Accepted, Desirable and Non-objectives. They reflect working group 1229 consensus on the effectiveness of the requirements in the context of 1230 protocol design. 1232 Additionally, this document includes requirements from network 1233 service operators that have been derived based on their experience in 1234 operating large- scale WLANs. 1236 The resulting requirements from this document will be used in 1237 conjunction with the CAPWAP Problem Statement [I-D.ietf-capwap- 1238 problem-statement] and CAPWAP Architecture Taxonomy [I-D.ietf-capwap- 1239 arch] to develop and evalute an interoperable protocol for the 1240 control and provisioning of WTPs in large-scale WLANs. 1242 7. Security Considerations 1244 The CAPWAP framework highlights support for both local-MAC and split- 1245 MAC WTPs. In deployments where both types of WTPs are used, it is 1246 crucial to ensure that each be secured in consideration of their 1247 capabilities. The Architecture Taxonomy illustrates how different 1248 WTPs incorporate varying levels of functionalities. Development of 1249 the CAPWAP protocol should ensure that the deployment of both local- 1250 MAC and split-MAC WTPs within a single WLAN do not present loopholes 1251 for security compromises. 1253 In shared WLAN deployments made of a number of logical groups, 1254 traffic from each group needs to be mutually separated. So in 1255 addition to protocol related exchanges, data traffic from wireless 1256 terminals should also be segregated with respect to the logical 1257 groups to which they belong. It should not be possible for data or 1258 control traffic from one logical group to stray to or influence 1259 another logical group. 1261 The use of IEEE 802.11i over the centralized WLAN architecture allows 1262 for implementations in which the PMK is shared across WTPs. This 1263 raises the ambiguity between legitimate sharing and illegitimate 1264 copies. Wireless terminals may unknowingly fall prey to or exploit 1265 this ambiguity. The resolution of this issue is currently being 1266 evaluted by the IEEE 802 and IETF liaisons. 1268 The low-cost of launching attacks on WLANs makes the CAPWAP protocol 1269 a target. A first step in securing against any form of attacks is to 1270 continuously monitor the WLAN for conditions of potential threats 1271 from rogue WTPs or wireless terminals. For example, profiles for DoS 1272 and replay attacks need to be considered for the CAPWAP protocol to 1273 effectively monitor security conditions. 1275 The open environment of many WLAN deployments makes physical security 1276 breaches highly probable. Compromises resulting from theft and 1277 physical damage must be considered during protocol development. For 1278 instance, it should not be possible for a single compromised WTP to 1279 affect the WLAN as a whole. 1281 Considering asymmetric, non-mutual authentication between WTPs and 1282 WLAN controller, there is a risk of a rogue participant exploiting 1283 such an arrangement. It is preferrable to avoid non-mutual 1284 authentication. In some cases, the legitimacy of the protocol 1285 exchange participants may be verified externally, for example by 1286 means of physical containment within a close environment. Asymmetric 1287 authentication may be appropriate here without risk of security 1288 compromises. 1290 8. Acknowledgements 1292 The authors would like to thank the Working Group Chairs, Dorothy 1293 Gellert and Mahalingam Mani, for their support and patience with this 1294 document. We would also like to thank participants of the Working 1295 Group who have helped shape the objectives. In particular, the 1296 authors thank James Kempf, Pat Calhoun, Inderpreet Singh, Dan 1297 Harkins, T. Sridhar, Charles Clancy and Emek Sadot for their 1298 invaluable inputs. We also extend our gratitude to the IEEE 802.11 1299 Ad-Hoc Committee for their evaluation of the document. The authors 1300 also acknowledge the contributions from Meimei Dang, Satoshi Iino, 1301 Mikihito Sugiura and Dong Wang. 1303 9. References 1305 [I-D.ietf-capwap-arch] 1306 Yang, L., Zerfos, P., and E. Sadot, "Architecture Taxonomy 1307 for Control and Provisioning of Wireless Access 1308 Points(CAPWAP)", draft-ietf-capwap-arch-06 (work in 1309 progress), November 2004. 1311 [I-D.ietf-capwap-problem-statement] 1312 Calhoun, P., "CAPWAP Problem Statement", 1313 draft-ietf-capwap-problem-statement-02 (work in progress), 1314 September 2004. 1316 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1317 Requirement Levels", BCP 14, RFC 2119, March 1997. 1319 Authors' Addresses 1321 Saravanan Govindan 1322 Panasonic Singapore Laboratories 1323 Block 1022, Tai Seng Industrial Estate 1324 #06-3530, Tai Seng Avenue 1325 Singapore 534 415 1326 Singapore 1328 Phone: +65 6550 5441 1329 Email: saravanan.govindan@sg.panasonic.com 1330 Zhonghui Yao 1331 Huawei Longgang Production Base 1332 Shenzhen 518 129 1333 P. R. China 1335 Phone: +86 755 2878 0808 1336 Email: yaoth@huawei.com 1338 Wenhui Zhou 1339 China Mobile 1340 53A, Xibianmen Ave, Xuanwu District 1341 Beijing 100 053 1342 P. R. China 1344 Phone: +86 10 6600 6688 ext.3061 1345 Email: zhouwenhui@chinamobile.com 1347 L. Lily Yang 1348 Intel Corp. 1349 JF3-206, 2111 NE 25th Ave. 1350 Hilsboro, OR 97124 1351 USA 1353 Phone: +1 503 264 8813 1354 Email: lily.l.yang@intel.com 1356 Hong Cheng 1357 Panasonic Singapore Laboratories 1358 Block 1022, Tai Seng Industrial Estate 1359 #06-3530, Tai Seng Avenue 1360 Singapore 534 415 1361 Singapore 1363 Phone: +65 6550 5447 1364 Email: hong.cheng@sg.panasonic.com 1366 Intellectual Property Statement 1368 The IETF takes no position regarding the validity or scope of any 1369 Intellectual Property Rights or other rights that might be claimed to 1370 pertain to the implementation or use of the technology described in 1371 this document or the extent to which any license under such rights 1372 might or might not be available; nor does it represent that it has 1373 made any independent effort to identify any such rights. Information 1374 on the procedures with respect to rights in RFC documents can be 1375 found in BCP 78 and BCP 79. 1377 Copies of IPR disclosures made to the IETF Secretariat and any 1378 assurances of licenses to be made available, or the result of an 1379 attempt made to obtain a general license or permission for the use of 1380 such proprietary rights by implementers or users of this 1381 specification can be obtained from the IETF on-line IPR repository at 1382 http://www.ietf.org/ipr. 1384 The IETF invites any interested party to bring to its attention any 1385 copyrights, patents or patent applications, or other proprietary 1386 rights that may cover technology that may be required to implement 1387 this standard. Please address the information to the IETF at 1388 ietf-ipr@ietf.org. 1390 Disclaimer of Validity 1392 This document and the information contained herein are provided on an 1393 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1394 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1395 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1396 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1397 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1398 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1400 Copyright Statement 1402 Copyright (C) The Internet Society (2005). This document is subject 1403 to the rights, licenses and restrictions contained in BCP 78, and 1404 except as set forth therein, the authors retain all their rights. 1406 Acknowledgment 1408 Funding for the RFC Editor function is currently provided by the 1409 Internet Society.