idnits 2.17.1 draft-ietf-capwap-objectives-01.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.a on line 25. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1260. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1237. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1244. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1250. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. ** There is 1 instance 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 2005) is 6981 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) ** 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: 10 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: August 5, 2005 ZH. Yao 5 Huawei 6 WH. Zhou 7 China Mobile 8 L. Yang 9 Intel 10 H. Cheng 11 Panasonic 12 March 2005 14 Objectives for Control and Provisioning of Wireless Access Points 15 (CAPWAP) 16 draft-ietf-capwap-objectives-01.txt 18 Status of this Memo 20 This document is an Internet-Draft and is subject to all provisions 21 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 22 author represents that any applicable patent or other IPR claims of 23 which he or she is aware have been or will be disclosed, and any of 24 which he or she become aware will be disclosed, in accordance with 25 RFC 3668. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as 30 Internet-Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 This Internet-Draft will expire on August 5, 2005. 45 Copyright Notice 47 Copyright (C) The Internet Society (2005). 49 Abstract 51 This document presents objectives for an interoperable protocol for 52 the Control and Provisioning of Wireless Access Points (CAPWAP). The 53 document aims to establish a set of focused requirements for the 54 development and evaluation of a CAPWAP protocol. The objectives 55 address Architecture, Operation, Security and Network Operator 56 Requirements that are necessary to enable interoperability among 57 wireless local area network (WLAN) devices of alternative designs. 59 Table of Contents 61 1. Requirements notation . . . . . . . . . . . . . . . . . . . 3 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 64 4. Objectives Overview . . . . . . . . . . . . . . . . . . . . 6 65 5. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 5.1 Mandatory and Accepted Objectives . . . . . . . . . . . . 7 67 5.1.1 Logical Groups . . . . . . . . . . . . . . . . . . . . 7 68 5.1.2 Support for Traffic Separation . . . . . . . . . . . . 8 69 5.1.3 Wireless Terminal Transparency . . . . . . . . . . . . 9 70 5.1.4 Configuration Consistency . . . . . . . . . . . . . . 10 71 5.1.5 Firmware Trigger . . . . . . . . . . . . . . . . . . . 11 72 5.1.6 Monitoring and Exchange of System-wide Resource 73 State . . . . . . . . . . . . . . . . . . . . . . . . 11 74 5.1.7 Resource Control Objective . . . . . . . . . . . . . . 12 75 5.1.8 CAPWAP Protocol Security . . . . . . . . . . . . . . . 14 76 5.1.9 System-wide Security . . . . . . . . . . . . . . . . . 15 77 5.1.10 IEEE 802.11i Considerations . . . . . . . . . . . . 16 78 5.1.11 Interoperability Objective . . . . . . . . . . . . . 17 79 5.2 Desirable Objectives . . . . . . . . . . . . . . . . . . . 19 80 5.2.1 Multiple Authentication Mechanisms . . . . . . . . . . 19 81 5.2.2 Support for Future Wireless Technologies . . . . . . . 20 82 5.2.3 Support for New IEEE Requirements . . . . . . . . . . 21 83 5.2.4 Interconnection Objective . . . . . . . . . . . . . . 22 84 5.2.5 Access Control . . . . . . . . . . . . . . . . . . . . 22 85 5.3 Rejected Objectives . . . . . . . . . . . . . . . . . . . 24 86 5.3.1 Support for Non-CAPWAP WTPs . . . . . . . . . . . . . 24 87 5.4 Operator Requirements . . . . . . . . . . . . . . . . . . 24 88 5.4.1 AP Fast Handoff . . . . . . . . . . . . . . . . . . . 25 89 6. Summary and Conclusion . . . . . . . . . . . . . . . . . . . 26 90 7. Security Considerations . . . . . . . . . . . . . . . . . . 27 91 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 92 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 28 94 Intellectual Property and Copyright Statements . . . . . . . 30 96 1. Requirements notation 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in [RFC2119]. 102 2. Terminology 104 This document follows the terminologies of [I-D.ietf-capwap-arch]. 105 Additionally, the following terms are defined; 107 Switching Segment: Those aspects of a centralized WLAN that primarily 108 deal with switching or routing of control and data information 109 between Wireless Termination Points (WTPs) and the WLAN controller. 111 Wireless Medium Segment: Those aspects of a centralized WLAN that 112 primarily deal with the wireless interface between WTPs and wireless 113 terminals. The Wireless Medium Segment is specific to layer 2 114 wireless technology, such as IEEE 802.11. 116 CAPWAP Framework: A term that covers the local-MAC and split-MAC 117 designs of the Centralized WLAN Architecture. Standardization 118 efforts are focussed on these designs. 120 CAPWAP Protocol: The protocol between WLAN controller and WTPs in the 121 CAPWAP framework. It facilitates control, management and 122 provisioning of WTPs in an interoperable manner. 124 3. Introduction 126 The growth in large-scale wireless local area network (WLAN) 127 deployments has brought to focus a number of technical challenges. 128 Among them is the complexity of managing large numbers of wireless 129 termination points (WTPs), which is further exacerbated by variations 130 in their design. Another challenge is the maintenance of consistent 131 configurations among the numerous WTPs of a system. The dynamic 132 nature of the wireless medium is also a concern together with WLAN 133 security. The challenges affecting large-scale WLAN deployments have 134 been highlighted in [I-D.ietf-capwap-problem-statement]. 136 Many vendors have addressed these challenges by developing new 137 architectures and solutions. A survey of the various developments 138 was conducted to better understand the context of these challenges. 139 This survey is a first step towards designing interoperability among 140 the solutions. The Architecture Taxonomy [I-D.ietf-capwap-arch] is a 141 result of this survey in which major WLAN architecture families are 142 classified. Broadly, these are the autonomous, centralized WLAN and 143 distributed mesh architectures. 145 The Architecture Taxonomy identified that the current majority of 146 large-scale deployments follow the centralized WLAN architecture in 147 which portions of the wireless medium access control (MAC) operations 148 are centralized in a WLAN controller. This centralized WLAN 149 architecture is further classified into remote-MAC, split-MAC and 150 local-MAC designs. Each differs in the degree of separation of 151 wireless MAC layer capabilities between WTPs and WLAN controller. 153 This document puts forward critical objectives for achieving 154 interoperability in the CAPWAP framework. It presents requirements 155 that address the challenges of controling and provisioning 156 large-scale WLAN deployments. The realization of these objectives in 157 a CAPWAP protocol will ensure that WLAN equipment of major design 158 types may be integrally deployed and managed. 160 4. Objectives Overview 162 The objectives for CAPWAP have been broadly classified to address 163 architecture, operation and security requirements of managing 164 large-scale WLAN deployments. 166 Architecture objectives deal with system level aspects of the CAPWAP 167 protocol. They address issues of protocol extensibility, diversity 168 in network deployments and architecture designs and differences in 169 transport technologies. 171 Operational objectives address the control and management features of 172 the CAPWAP protocol. They deal with operations relating to WLAN 173 monitoring, resource management, QoS and access control. 175 Security objectives address potential threats to WLANs and their 176 containment. In the CAPWAP context, security requirements cover both 177 the protocol between WLAN controller and WTPs and also the WLAN 178 system as a whole. 180 5. Objectives 182 The objectives described in this document have been prioritized based 183 on their immediate significance in the development and evaluation of 184 a control and provisioning protocol for large-scale WLAN deployments. 185 Additionally, one category is provided for requirements gathered from 186 network service operators. These are specific need that arise from 187 operators' experiencese in deploying and managing large-scale WLANs. 188 The priorities are; 190 i. Mandatory and Accepted Objectives 191 ii. Desirable Objectives 192 iii. Rejected Objectives 193 iv. Operator Requirements 195 The priorities have been assigned to individual objectives in 196 accordance with working group discussions. 198 5.1 Mandatory and Accepted Objectives 200 Objectives prioritized as Mandatory and Accepted have been deemed 201 crucial for the control and provisioning of WTPs. They directly 202 address the challenges of large-scale WLAN deployments and must be 203 realized by a CAPWAP protocol. 205 5.1.1 Logical Groups 207 [Ed. Note: Was 5.2.3i] 209 Classification: Architecture 211 Description: 213 Large WLAN deployments are complex and expensive. Furthermore, 214 enterprises deploying such networks are under pressure to improve the 215 efficiency of their expenditures. 217 Shared WLAN deployments, where a single physical WLAN infrastructure 218 supports a number of logical networks, are increasingly used to 219 address these two issues of large-scale WLANs. These are popular as 220 they allow deployment and management costs to be spread across 221 businesses. 223 In traditional WLANs, each physical WTP represents one complete 224 subset of a larger WLAN system. Shared WLANs differ in that each 225 physical WTP represents a number of logical subsets of possibly a 226 number of larger WLAN systems. Each logical division of a physical 227 WTP is referred to as a logical group. For example, each BSSID of a 228 physical WTP can be construed to be a logical group. So WLANs are 229 managed in terms of logical groups instead of physical WTPs. Virtual 230 APs are examples of logical groups. 232 Protocol Requirement: 234 WLAN deployment trends require the CAPWAP protocol to be capable of 235 controlling and managing physical WTPs in terms of logical groups. 237 Motivation and Protocol Benefits: 239 Commercial realities necessitate that WLANs be manageable in terms of 240 its logical groups. This allows separation of logical services and 241 underlying infrastructure management. A protocol that realizes this 242 need ensures simlper and cost effective WLANs, which directly address 243 the requirements of network service operators. 245 Relation to Problem Statement: 247 This objective addresses the problem of management complexity in 248 terms of costs. Cost complexity is reduced by sharing WLAN 249 deployments. Consequently, deployment and management 250 cost-efficiencies are realized. 252 5.1.2 Support for Traffic Separation 254 [Ed. Note: Was 5.2.7 and 5.2.3ii] 256 Classification: Operations 258 Description: 260 The centralized WLAN architecture simplifies complexity associated 261 with large-scale deployments by consolidating portions of wireless 262 MAC functionality at a central WLAN controller and distributing the 263 remaining across WTPs. As a result, WTPs and WLAN controller 264 exchange control and data information between them. This objective 265 states that control and data aspects of the exchanges be mutually 266 separated for further simplicity. This will allow solutions for each 267 type of exchange to be independently optimized. 269 Furthermore, in the context of shared WLAN deployments, the mutual 270 separation of control and data also addresses security concerns. In 271 particular, given the likelihood of different logical groups being 272 managed by different administrators, separation of control and data 273 is a first step towards individually containing and securing the 274 logical groups. 276 It is also important to ensure that traffic from each logical group 277 be mutually separated to maintain the integrity and independence of 278 the logical groups. 280 Protocol Requirement: 282 In order to maintain the separation of control and data traffic, the 283 CAPWAP protocol is required to define control messages such that they 284 do not involve piggybacking or other combination with data traffic. 286 Motivation and Protocol Benefits: 288 The aim of separating data and control aspects of the protocol is to 289 simplify the protocol. It also allows for the flexibility of 290 addressing each type of traffic in the most appropriate manner. 292 Furthermore, such separation provides for the separation of data and 293 control paths. This will help remotely located WTPs to handle data 294 traffic in alternative ways without the need for forwarding them 295 across a wide network to the WLAN controller. 297 Separation of WTP control and data also aids in the secure 298 realization of shared WLAN deployments. 300 Relation to Problem Statement: 302 Broadly, this objective relates to the challenge of managing 303 complexity in large-scale WLANs. The requirement for traffic 304 separation simplifies control as this is separated from the task of 305 data transport. 307 5.1.3 Wireless Terminal Transparency 309 [Ed. Note: Was 5.2.4iii] 311 Classification: Operations 313 Description: 315 The CAPWAP protocol is applicable between a centralized WLAN 316 controller and a number of WTPs, i.e. it affects only the switching 317 segment of the centralized WLAN architecture. Its operations should 318 therefore be independent of the wireless terminal. Wireless 319 terminals should not be required to be aware of the existence of the 320 CAPWAP protocol. 322 Protocol Requirement: 324 Wireless terminals should not be required to recognize or be aware of 325 the CAPWAP protocol. 327 Motivation and Protocol Benefits: 329 IEEE 802.11 based wireless terminals are mature and widely available. 330 It would be beneficial for CAPWAP not to impose new requirements on 331 these wireless terminals. In effect, this requirement ensures that 332 the setup cost of the protocol is reduced as the numerous existing 333 wireless terminals need not be altered. 335 Relation to Problem Statement: 337 The Problem Statement highlights the challenges faced by large WLANs 338 consisting of many WTPs. It does not refer to the operations of 339 wireless terminals and this objective emphasizes the independence. 341 5.1.4 Configuration Consistency 343 [Ed. Note: Was 5.2.5i] 345 Classification: Operations 347 Description: 349 WLANs in the CAPWAP framework contain numerous WTPs, each of which 350 need to be configured and managed in a consistent manner. This is 351 possible by providing the centralized WLAN controller with regular 352 updates on the state of their operations. The centralized WLAN 353 controller can in turn apply information from the regular updates to 354 consistently configure the WTPs. 356 Protocol Requirement: 358 The CAPWAP protocol must allow for regular exchanges of state 359 information between WTPs and WLAN controller. Examples of state 360 information include WTP processing load and memory utilization. 362 Motivation and Protocol Benefits: 364 A protocol that has access to regular state information can in turn 365 use this to enhance WLAN performance. The CAPWAP protocol will be 366 better equipped to address configuration related problems with the 367 state information. So with greater state information, control and 368 management operations can be improved. 370 Relation to Problem Statement: 372 One of the major challenges described in the Problem Statement is 373 that of maintaining consistent configuration across the numerous WTPs 374 of a WLAN. This objective fundamentally addresses this challenge by 375 providing relevant state information based on which configurations 376 can be appropriately maintained. 378 5.1.5 Firmware Trigger 380 [Ed. Note: Was 5.2.5i] 382 [Ed. Note: Was titled "Firmware Distribution] 384 Classification: Operations 386 Description: 388 One specific aspect of configuration consistency is the firmware used 389 by various WTPs. The scale of large WLANs introduces possibilities 390 for variations in the firmware used among WTPs. This objective 391 highlights the need for the CAPWAP protocol to trigger the delivery 392 of appropriate versions of firmware to WTPs. The actual delivery of 393 firmware need not be inclusive to the prtoocol. 395 Protocol Requirement: 397 The CAPWAP protocol must support a trigger for delivery of firmware 398 updates. 400 Motivation and Protocol Benefits: 402 The CAPWAP protocol interfaces many WTPs to a centralized WLAN 403 controller. Firmware distribution allows these interfaces to be 404 appropriately equivalent. This in turn results in consistent 405 configuration and simplified management. So the protocol benefits by 406 including triggers for the distribution of firmware updates. 408 Relation to Problem Statement: 410 Inconsistencies in the configuration of WTPs has been identified as a 411 major challenge for large-scale WTPs. This objectives helps overcome 412 the challenge by providing for a way for the protocol to initiate 413 delivery of equivalent versions of firmware to all WTPs. 415 5.1.6 Monitoring and Exchange of System-wide Resource State 417 [Ed. Note: Was 5.2.5ii] 419 [Ed. Note: Was titled "System-wide Resource State"] 420 Classification: Operations 422 Description: 424 The centralized WLAN architecture is made up of a switching segment 425 and wireless medium segment. In the switching segment, network 426 congestion, WTP status and firmware information have to be monitored. 427 In the wireless medium segment, the dynamic nature of the medium 428 itself has to be monitored. Overall, there are also various 429 statistics need to be considered for efficient WLAN operation. 431 The CAPWAP protocol should be capable of monitoring the various 432 information sources and deliver the resulting information to the 433 relevant WLAN devices - either WTPs or WLAN controller. Moreover, 434 given the relationship among information sources, the CAPWAP protocol 435 should combine state information from them. For example, statistics 436 information and status signals from WTPs may be merged before being 437 exchanged. 439 Examples of statistics information that the CAPWAP protocol should 440 monitor and exchange include; congestion state, interference levels, 441 loss rates and various delay factors. 443 Protocol Requirement: 445 The CAPWAP protocol must allow for the exchange of statistics, 446 congestion and other WLAN state information. 448 Motivation and Protocol Benefits: 450 The effectivness of a protocol is based on the relevance of 451 information on which it operates. This requirement for resource 452 monitoring and exchange can provide the appropriate information to 453 the CAPWAP protocol. 455 Relation to Problem Statement: 457 The Problem Statement highlights the challenge of dealing with large 458 numbers of WTPs and the dynamic nature of the wireless medium. 459 Information on the state of WTPs and the medium is important to deal 460 with them effectively. So this objective relates to the problem of 461 managing consistency in large WLANs. 463 5.1.7 Resource Control Objective 465 [Ed. Note: Was 5.2.6] 467 Classification: Operations 468 Description: 470 Integral to the success of any wireless network system is the 471 performance and quality it can offer its subscribers. Since CAPWAP 472 based WLANs combine a switching segment and a wireless medium 473 segment, performance and quality need to be coordinated across both 474 of these segments. So QoS performance must be enforced system-wide. 476 This objective highlights QoS over the entire WLAN system which 477 includes the switching segment and the wireless medium segment. 478 Given the fundamental differences between the two, it is likely that 479 there are alternate QoS mechanisms between WTPs and wireless service 480 subscribers and between WTPs and WLAN controllers. For instance, the 481 former will be based on IEEE 802.11e while the latter will be an 482 alternative. So resources need to be adjusted in a coordinated 483 fashion over both segments. The CAPWAP protocol should ensure that 484 these adjustments are appropriately exchanged between WLAN 485 controllers and WTPs. 487 In addition to IEEE 802.11e, there are a number of other IEEE Task 488 Groups that may affect network resources. These include IEEE TGk, 489 TGu and TGv, which are currently under progress. CAPWAP should 490 therefore not be restricted to IEEE 802.11e based mapping. 492 Protocol Requirement: 494 The CAPWAP protocol must maintain IEEE 802.11e QoS mappings across 495 the switching and wireless medium segments. 497 Motivation and Protocol Benefits: 499 A protocol that addresses QoS aspects of WLAN systems will deliver 500 high performance thereby being beneficial for subscribers and for 501 resource utilization efficiency. Since CAPWAP deals with WTPs 502 directly and with the wireless medium indirectly, both of these must 503 be considered for performance. 505 For the wireless medium segment, QoS aspects in the protocol enable 506 high quality communications within the domain of a WLAN controller. 507 Since each domain generally covers an enterprise or a group of 508 service providers, such protocol performance has wide-ranging 509 effects. 511 Within the switching segment of CAPWAP, a QoS-enabled protocol 512 minimizes the adverse effects of dynamic traffic characteristics so 513 as to ensure system-wide performance. 515 Relation to Problem Statement: 517 QoS control is critical to large WLANs and relates to a number of 518 aspects. In particular, this objective can help address the problem 519 of managing dynamic conditions of the wireless medium. 521 Furthermore, traffic characteristics in large scale WLANs are 522 constantly varying. So network utilization becomes inefficient and 523 user experience is unpredictable. 525 The interaction and coordination between the two aspects of 526 system-wide QoS is therefore critical for performance. 528 5.1.8 CAPWAP Protocol Security 530 [Ed. Note: Was 5.2.10] 532 Classification: Security 534 Description: 536 This objective addresses the security of the CAPWAP protocol. 538 The CAPWAP protocol must first provide for the participating entities 539 - WLAN controller and WTPs - to be mutually authenticated. This is 540 to ensure that rogue WTPs do not breach legitimate WLAN systems. For 541 example, WTPs may need to regularly renew their authentication state 542 with the WLAN controller. 544 Once WTPs and WLAN controller have been mutually authenticated, 545 information exchanges between them must be secured against various 546 security threats. This should cover illegitimate modifications to 547 protocol exchanges, eavesdropping and DoS attacks, among other 548 potential compromises. So the protocol must be provide 549 confidentiality, integrity and authenticity for those exchanges. 551 As a result of realizing this objective it should not be possible for 552 individual WTP breaches to affect the security of the WLAN as a 553 whole. So WTP mis-use will be protected against. 555 Additionally, the key establishment protocol for authentication and 556 securing CAPWAP exchanges must be designed to minimize the 557 possibility of future compromises after the keys are established. 559 While mutual authentication is necessary for CAPWAP, the protocol 560 should not prevent the use of asymmetric, non-mutual authentication. 561 The security considerations of such asymmetric authentication are 562 described in the Security Considerations section. 564 Protocol Requirement: 566 The CAPWAP protocol must support mutual authentication of WTPs and 567 the centralized controller. It must also ensure that information 568 exchanges between them are secured. 570 Motivation and Protocol Benefits: 572 WLANs are increasingly deployed in critical aspects of enterprise and 573 consumer networks. In these contexts, protocol security is crucial 574 to assure the privacy and integrity expected from network 575 administrators and end-users. So securing the CAPWAP protocol has 576 direct benefits in addressing these concerns. 578 Relation to Problem Statement: 580 Security problems in large-scale WLANs are detailed in the Problem 581 Statement. These include complications arising from rogue WTPs and 582 compromised interfaces between WTPs and WLAN controller. The 583 requirement for protocol security addresses these problems and 584 highlights the importance of protecting against them. 586 5.1.9 System-wide Security 588 [Ed. Note: Was 5.2.11] 590 Classification: Security 592 Description: 594 The emphasis of this objective is on the security threats external to 595 the centralized CAPWAP segment of a WLAN system. The focus is 596 therefore on rogue wireless clients and other illegitimate wireless 597 interferences. There are a number of specific external threats that 598 need to be addressed within the CAPWAP framework. 600 i. PMK Sharing 602 One aspect of this objective relates to recent discussions on PMK 603 sharing in the CAPWAP framework. This objective highlights the need 604 to prevent exploitation of this ambiguity by rogue wireless clients. 605 It is to ensure that any ambiguities arising from the CAPWAP 606 framework are not cause for security breaches. 608 Protocol Requirement: 610 The design of the CAPWAP protocol should not allow for any 611 compromises to the WLAN system by external entities. 613 Motivation and Protocol Benefits: 615 The external threats to the centralized WLAN architecture become 616 increasingly crucial given the low cost of wireless clients. Since 617 it is relatively inexpensive for rogue individuals to mount attacks, 618 it is important that WLAN systems are protected against them. 619 Adequate mechanisms to thwart such external threats will be of 620 tremendous benefit to the WLAN systems controlled and managed with 621 the CAPWAP protocol. 623 Relation to Problem Statement: 625 This objective is based on the security needs highlighted in the 626 Problem Statement. Specifically, the Problem Statement discusses the 627 effects of the shared wireless medium. This represents the external 628 aspects of the CAPWAP framework from which certain threats can arise. 629 The system-wide security objective addresses such threats in relation 630 to the Problem Statement. 632 5.1.10 IEEE 802.11i Considerations 634 [Ed. Note: Was 5.2.15] 636 Classification: Operations 638 Description: 640 The CAPWAP protocol must support authentication in the centralized 641 WLAN architecture in which the authenticator and encryption points 642 can be located on distinct entities, i.e. WLAN controller or WTP. 643 The Architecture Taxonomy illustrates a number of variants, in both 644 local-MAC and split-MAC designs, in which the authenticator is 645 located at the WLAN controller and the encryption points are at the 646 WTPs. The CAPWAP protocol must be applicable to these variants and 647 allow authentication mechanisms and their consistituent processes to 648 be operable in these cases. 650 An important issue to consider in this case is the exchange of key 651 information when authenticator and encryption points are located on 652 distinct entities. For example, consider the case where IEEE 802.11i 653 is used in a WLAN in which the WLAN controller realizes the 654 authenticator, some WTPs realize encryption (possibly local-MAC WTPs) 655 and other WTPs rely on the WLAN controller for encryption (possibly 656 split-MAC WTPs). 658 Here, CAPWAP will first need to identify the location of the 659 authenticator and encryption points between each WLAN controller-WTP 660 pair. This will likely be part of the initial WTP configuration. 661 Subsequently, the WTPs which realize encryption will need CAPWAP to 662 exchange key information with the authenticator at the WLAN 663 controller. For the WTPs which do not realize encryption, CAPWAP 664 need to adapt its control to bypass the key exchange phase. 666 Clearly, the centralized WLAN architecture presents a different 667 platform for authentication mechanisms compared to legacy WLANs in 668 which a WTP realized both authenticator and encryption roles. So 669 this objective highlights the need for CAPWAP to support 670 authentication and key management in the centralized WLAN 671 architecture. 673 Protocol Requirement: 675 The CAPWAP protocol must determine the exact structure of the 676 centralized WLAN architecture in which authentication needs to be 677 supported, i.e. the location of major authentication components. 678 This may be achieved during WTP initialization where major 679 capabilities are distinguished. 681 The protocol must allow for the exchange of key information when 682 authenticator and encryption roles are located in distinct entities. 684 Motivation and Protocol Benefits: 686 The immediate focus of CAPWAP is on supporting IEEE 802.11 based 687 WLANs. As such, it is necessary for the protocol to recognize the 688 major distinction in WLAN design with respect to IEEE 802.11i 689 authenticator and encryption points. This represents a significant 690 variation that has been highlighted in the Architecture Taxonomy. 691 The CAPWAP protocol benefits by accommodating such a major 692 consideration fro IEEE 802.11i. 694 These requirements will be common for all authentication mechanisms 695 over the centralized WLAN architecture. So they are applicable to 696 IEEE 802.11i, UMA and other mechanisms. 698 Relation to Problem Statement: 700 The Problem Statement highlights the availability of different WTP 701 designs and the need to ensure interoperability among them. In this 702 regard, operational changes occuring due to the separation of the 703 IEEE 802.11i authenticator and encryption points need to be 704 accommated within the CAPWAP protocol. 706 5.1.11 Interoperability Objective 708 [Ed. Note: Was 5.2.1] 710 Classification: Architecture 711 Description: 713 Two major designs of the centralized WLAN architecture are local-MAC 714 and split-MAC. With the focusing of standardization efforts on these 715 two designs, it is crucial to ensure mutual interoperation among 716 them. 718 This objective for the CAPWAP protocol is to ensure that WTPs of both 719 local-MAC and split-MAC architecture designs are capable of 720 interoperation within a single WLAN. Consequently, a single WLAN 721 controller will be capable of controlling both types of WTPs using a 722 single CAPWAP protocol. Integral support for these designs comprises 723 a number of protocol aspects. 725 i. Capability negotiations between WLAN controller and WTPs 727 WTP designs differ in the degree of IEEE 802.11 MAC functionalities 728 that each type of WTP realizes. The major distinctions, split-MAC 729 and local-MAC differ in the processing of IEEE 802.11 MAC frames. In 730 this regard, the CAPWAP protocol should include functionality that 731 allows for negotiationg of significant capabilities between WTPs and 732 WLAN controller. 734 As a first step, such negotiations could cover the type of WTP - 735 split-MAC or local-MAC - as this provides substantial information on 736 their respective capabilities. 738 ii. Establishment of alternative interfaces 740 The capability differences among different WTPs essentially equates 741 to alternative interfaces with a WLAN controller. So the CAPWAP 742 protocol should be capable of adapting its operations to the major 743 different interfaces. In a first case, this would include 744 accommodating capability differences between local-MAC and split-MAC 745 WTPs. 747 The definition of these interfaces in terms of finer granularity of 748 functionalities will be based on the outcome of the IEEE AP 749 Functionality (APF) Ad-Hoc Committee. The APF Ad-Hoc Committee will 750 provide appropriate insight in to specific functional blocks which 751 may be used for finer capabilities negotiations within the CAPWAP 752 protocol. 754 Protocol Requirement: 756 The CAPWAP protocol must include sufficient capabilities negotiations 757 to distinguish between major types of WTPs. 759 Motivation and Protocol Benefits: 761 The benefits of realizing this architecture objective are both 762 technical and practical. First, there are substantial overlaps in 763 the control operations of local-MAC and split-MAC architecture 764 designs. The Architecture Taxonomy tabulates major common features 765 of the two designs. As a result, it is technically practical to 766 devise a single protocol that manages both types of devices. 768 Next, the ability to operate a CAPWAP protocol for both types of 769 architectural designs enhances its practical prospects as it will 770 have wider appeal. 772 Furthermore, the additional complexity resulting from such 773 alternative interfaces is marginal. Consequently, the benefits of 774 this objective will far outweigh any cost of realizing it. 776 Relation to Problem Statement: 778 The objective for supporting both local-MAC and split-MAC WTPs is 779 fundamental to addressing the Problem Statement. It forms the basis 780 for those problems to be uniformly addressed across the major WLAN 781 architectures. This is the ultimate aim of standardization efforts. 782 The realization of this objective will ensure the development of a 783 comprehensive set of mechanisms that address the challenges of 784 large-scale WLAN deployments. 786 5.2 Desirable Objectives 788 These objectives have been determined to be desirable for a CAPWAP 789 protocol but not mandatory. Realizing these objectives may help 790 improve control of WLANs but need not necessarily be required for all 791 networks or scenarios. 793 5.2.1 Multiple Authentication Mechanisms 795 [Ed. Note: Was 5.2.3iii] 797 Classification: Architecture 799 Description: 801 Shared WLAN infrastructure raise the issue of multiple authentication 802 mechanisms. This is because each logical group is likely to be 803 associated with different service providers or WLAN domains. As a 804 result, the authentication needs withing them will be different. 805 While CAPWAP is required to support IEEE 802.11i, it is also 806 necessary for it to support other authentication mechanisms. For 807 example, one logical group may use IEEE 802.11i while another may use 808 web authentication. CAPWAP must be able to operate in such shared 809 WLANs. 811 Protocol Requirement: 813 The CAPWAP protocol must support different authentication mechanisms 814 in addition to IEEE 802.11i. 816 Motivation and Protocol Benefits: 818 The benefit of supporting various authentication mechanisms is that 819 the protocol then becomes flexible for use in various deployments. 820 The protocol will therefore not mandate the use of any particular 821 mechanisms which may not be appropriate for a particular deployment. 823 Relation to Problem Statement: 825 This objective relates to the problem of management complexity. 826 Shared WLAN deployments simplifies management of large networks. 828 5.2.2 Support for Future Wireless Technologies 830 [Ed. Note: Was 5.2.4i] 832 Classification: Architecture 834 Description: 836 The rapid pace of technology developments means that new advances 837 need to be catered for in current analyses. Among these is the 838 support for new wireless technologies within the CAPWAP protocol, 839 such as IEEE 802.16. The protocol should therefore not rely on 840 specifics of IEEE 802.11 technology. 842 In all cases where the CAPWAP protocol messages contain specific 843 layer 2 information elements, the definition of the protocol needs to 844 provide for extensibility so that these elements can be defined for 845 specific layer 2 wireless protocols. This may entail assigning a 846 layer 2 wireless protocol type and version field to the message PDU. 847 Examples of other wireless protocols that might be supported include 848 but are not limited to 802.16e, 802.15.x, etc. 850 Protocol Requirement: 852 CAPWAP protocol messages must be designed to be extensible for 853 specific layer 2 wireless technologies. It should not be limited to 854 the transport of elements relating to IEEE 802.11. 856 Motivation and Protocol Benefits: 858 There are many benefits to an extensible protocol. It allows for 859 application in different networks and provides greater scope. 860 Furthermore, service providers require WLAN solutions that will be 861 able to meet current and future market requirements. 863 Relation to Problem Statement: 865 The Problem Statement describes some of the advances taking place in 866 other standards bodies like the IEEE. It is important for the CAPWAP 867 protocol to reflect the advances and provide a framework in which 868 they can be supported. 870 5.2.3 Support for New IEEE Requirements 872 [Ed. Note: Was 5.2.4ii] 874 Classification: Architecture 876 Description: 878 The IEEE is currently reviewing IEEE 802.11 functionality. It is 879 expected that the review by the IEEE AP Functionality Ad-Hoc 880 Committee may result in new definitions of functional blocks, 881 interfaces or information flows. The CAPWAP protocol must be able to 882 incorporate these revisions with minimal change. 884 Protocol Requirement: 886 The CAPWAP protocol must be openly designed to support new IEEE 887 extensions. 889 Motivation and Protocol Benefits: 891 There are a number of advances being made within the IEEE regarding 892 the functionality of IEEE 802.11 technology. Since this represents 893 one of the major wireless technologies in use today, it will be 894 beneficial for CAPWAP to incorporate the relevant new extensions. 896 Relation to Problem Statement: 898 The Problem Statement presents an overview of the task of the IEEE 899 802.11 working group. This group is focussed on defining the 900 functional architecture of WTPs. It is necessary for the CAPWAP 901 protocol to reflect these definitions. 903 5.2.4 Interconnection Objective 905 [Ed. Note: Was 5.2.2] 907 Classification: Architecture 909 Description: 911 Large scale WLAN deployments are likely to use a variety of 912 interconnection technologies between different devices of the 913 network. It should therefore be possible for the CAPWAP protocol to 914 operate over various interconnection technologies. 916 As a result of realizing this objective, the protocol will be capable 917 of operation over both IPv4 and IPv6. It will also be designed such 918 that it can operate within tightly administered networks, such as 919 enterprise networks, or on open, public access networks. For 920 example, VLAN tunnels can be used across different types of networks 921 over which CAPWAP will operate. 923 Protocol Requirement: 925 The CAPWAP protocol must not be constrained to specific underlying 926 transport mechanisms. 928 Motivation and Protocol Benefits: 930 The main aim of the CAPWAP protocol is to achieve interoperability 931 among various WTPs and WLAN controllers. As such, the motivation for 932 this requirement is for the protocol to be operable independent of 933 underlying interconnection technologies. 935 Relation to Problem Statement: 937 The Problem Statement discusses the complexity of configuring large 938 WLANs. The selection of available interconnection technologies for 939 large-scale deployments further intensifies this complexity. This 940 requirement avoids part of the complexity by advocating independence 941 of the operational aspects of the protocol from from underlying 942 transport. 944 5.2.5 Access Control 946 [Ed. Note: Was 5.2.8] 948 [Ed. Note: Was titled "STA Admission Control Objective"] 950 Classification: Operations 952 [Ed. Note: Priority of this objectives needs to be confirmed by WG.] 954 Description: 956 This objective focuses on the informational needs of WLAN access 957 control and specifically the role of the CAPWAP protocol in 958 transporting this information between WTPs and their WLAN controller. 960 The following are some specific information aspects that need to be 961 transported by the CAPWAP protocol; 963 i. IEEE 802.11 association and authentication 965 The association of wireless clients is distinct for initial and 966 roaming cases. As a result, access control mechanisms requires 967 specific contextual information regarding each case. Additionally, 968 load balancing, QoS, security and congestion information in both 969 wireless medium segments and switching segments need to be 970 considered. 972 ii. WTP Access Control 974 In addition to controlling access for wireless clients, it is also 975 necessary to control admission of new WTPs. Given the threat of 976 rogue WTPs, it is important for CAPWAP to relay appropriate 977 authentication information between new WTPs and the WLAN controller. 979 Protocol Requirement: 981 The CAPWAP protocol must be capable of exchanging information 982 required for access control of WTPs and wireless terminals. 984 Motivation and Protocol Benefits: 986 Due to the scale of deployments in which CAPWAP will be employed, 987 comprehensive access control is crucial. The effectiveness of access 988 control in turn is affected by the information on which such control 989 is based. As a result, this objective has critical relevance to a 990 CAPWAP protocol. 992 Relation to Problem Statement: 994 This objective addresses the issue of access control in large WLANs. 995 Broadly, it relates the problem of managing the complexity scale of 996 such networks. With collective information of both switching and 997 wireless medium segments, realizing this objective will help control 998 and manage complexity. 1000 5.3 Rejected Objectives 1002 The following objectives have been rejected during the course of 1003 working group consultations. These objectives have been rejected in 1004 the context of CAPWAP and its considerations. They may however be 1005 applicable in alternative contexts. 1007 5.3.1 Support for Non-CAPWAP WTPs 1009 [Ed. Note: Was 5.2.12] 1011 [Ed. Note: Was titled "Centralized WTP Management"] 1013 Classification: Architecture 1015 Description: 1017 The CAPWAP protocol should provide an engine-mechanism to spring WTP 1018 auto-configuration and/or software version updates and should support 1019 integration with existing network management system. WLAN controller 1020 as a management agent is optional. 1022 If entities other than WLAN controllers manage some aspects of WTPs, 1023 such as software downloads, the CAPWAP protocol may be used for WTPs 1024 to notify WLAN controllers of any changes made by the other entities. 1026 Protocol Requirement: 1028 The CAPWAP protocol should be capable of recognizing legacy WTPs and 1029 existing network management systems. 1031 Motivation and Protocol Benefits: 1033 It is expected that in many cases, the centralized WLAN architecture 1034 will be deployed incrementally with legacy systems. In this regard, 1035 it is necessary for the protocol to be used in scenarios with mixed 1036 WLAN devices. 1038 Relation to Problem Statement: 1040 The Problem Statement highlights management complexity as a major 1041 issue with large WLANs. One part of this comlpexity can be related 1042 to the incremental deployment of centralized WLAN devices for which 1043 this objective is applicable. 1045 5.4 Operator Requirements 1047 The following objectives have been provided by network service 1048 operators. They represent the requirements from those ultimately 1049 deploying the CAPWAP protocol in their WLANs. 1051 5.4.1 AP Fast Handoff 1053 [Ed. Note: Operator requirements from China Mobile] 1055 Classification: Operations 1057 Description: 1059 Network service operators consider handoffs crucially because of the 1060 mobile nature of their customers. In this regard, the CAPWAP 1061 protocol should not adversely affect AP fast handoff procedures. The 1062 protocol may support optimizations for fast handoff procedures so as 1063 to allow better support for real-time services during handoffs. 1065 Protocol Requirement: 1067 CAPWAP protocol operations must not impede or obstruct the efficacy 1068 of AP fast handoff procedures. 1070 6. Summary and Conclusion 1072 The objectives presented in this document address three main aspects 1073 of the CAPWAP protocol, namely; 1075 i. Architecture 1076 ii. Operations 1077 iii. Security 1079 These requirements are aimed to focus standardization efforts on a 1080 simple, interoperable protocol for managing large-scale WLANs. The 1081 architecture requirements specify the structural features of the 1082 protocol such as those relating to WTP types (local-MAC and 1083 split-MAC) and WTP structures (logical groups). The operations 1084 requirements address the functional aspects dealing with WTP 1085 configuration and management. Finally, the security requirements 1086 cover authentication and integrity aspects of protocol exchanges. 1088 The objectives have additionally been prioritized to reflect their 1089 immediate significance to the development and evaluation of an 1090 interoperable CAPWAP protocol. The priorities are Mandatory and 1091 Accepted, Desirable and Rejected. They reflect working group 1092 consensus on the effectiveness of the requirements in the context of 1093 protocol design. 1095 Additionally, this document includes requirements from network 1096 service operators that have been derived based on their experience in 1097 operating large- scale WLANs. 1099 The resulting requirements from this document will be used in 1100 conjunction with the CAPWAP Problem Statement 1101 [I-D.ietf-capwap-problem-statement] and CAPWAP Architecture Taxonomy 1102 [I-D.ietf-capwap-arch] to develop and evalute an interoperable 1103 protocol for the control and provisioning of WTPs in large-scale 1104 WLANs. 1106 7. Security Considerations 1108 The CAPWAP framework highlights support for both local-MAC and 1109 split-MAC WTPs. In deployments where both types of WTPs are used, it 1110 is crucial to ensure that each be secured in consideration of their 1111 capabilities. The Architecture Taxonomy illustrates how different 1112 WTPs incorporate varying levels of functionalities. Development of 1113 the CAPWAP protocol should ensure that the deployment of both 1114 local-MAC and split-MAC WTPs within a single WLAN do not present 1115 loopholes for security compromises. 1117 In shared WLAN deployments made of a number of logical groups, 1118 traffic from each group needs to be mutually separated. So in 1119 addition to protocol related exchanges, data traffic from wireless 1120 terminals should also be segregated with respect to the logical 1121 groups to which they belong. It should not be possible for data or 1122 control traffic from one logical group to stray to or influence 1123 another logical group. 1125 The use of IEEE 802.11i over the centralized WLAN architecture allows 1126 for implementations in which the PMK is shared across WTPs. This 1127 raises the ambiguity between legitimate sharing and illegitimate 1128 copies. Wireless terminals may unknowingly fall prey to or exploit 1129 this ambiguity. The resolution of this issue is currently being 1130 evaluted by the IEEE 802 and IETF liaisons. 1132 The low-cost of launching attacks on WLANs makes the CAPWAP protocol 1133 a target. A first step in securing against any form of attacks is to 1134 continuously monitor the WLAN for conditions of potential threats 1135 from rogue WTPs or wireless terminals. For example, profiles for DoS 1136 and replay attacks need to be considered for the CAPWAP protocol to 1137 effectively monitor security conditions. 1139 The open environment of many WLAN deployments makes physical security 1140 breaches highly probable. Compromises resulting from theft and 1141 physical damage must be considered during protocol development. For 1142 instance, it should not be possible for a single compromised WTP to 1143 affect the WLAN as a whole. 1145 Considering asymmetric, non-mutual authentication between WTPs and 1146 WLAN controller, there is a risk of a rogue participant exploiting 1147 such an arrangement. It is preferrable to avoid non-mutual 1148 authentication. In some cases, the legitimacy of the protocol 1149 exchange participants may be verified externally, for example by 1150 means of physical containment within a close environment. Asymmetric 1151 authentication may be appropriate here without risk of security 1152 compromises. 1154 8. Acknowledgements 1156 The authors would like to thank the Working Group Chairs, Dorothy 1157 Gellert and Mahalingam Mani, for their support and patience with this 1158 document. We would also like to thank participants of the Working 1159 Group who have helped shape the objectives. In particular, the 1160 authors thank James Kempf, Pat Calhoun, Inderpreet Singh and T. 1161 Sridhar for their invaluable inputs. The authors also acknowledge 1162 the contributions from Meimei Dang, Satoshi Iino, Mikihito Sugiura 1163 and Dong Wang. 1165 9. References 1167 [I-D.ietf-capwap-arch] 1168 Yang, L., Zerfos, P. and E. Sadot, "Architecture Taxonomy 1169 for Control and Provisioning of Wireless Access 1170 Points(CAPWAP)", Internet-Draft draft-ietf-capwap-arch-06, 1171 November 2004. 1173 [I-D.ietf-capwap-problem-statement] 1174 Calhoun, P., "CAPWAP Problem Statement", 1175 Internet-Draft draft-ietf-capwap-problem-statement-02, 1176 September 2004. 1178 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1179 Requirement Levels", BCP 14, RFC 2119, March 1997. 1181 Authors' Addresses 1183 Saravanan Govindan 1184 Panasonic Singapore Laboratories 1185 Block 1022, Tai Seng Industrial Estate 1186 #06-3530, Tai Seng Avenue 1187 Singapore 534 415 1188 Singapore 1190 Phone: +65 6550 5441 1191 Email: sgovindan@psl.com.sg 1193 Zhonghui Yao 1194 Huawei Longgang Production Base 1195 Shenzhen 518 129 1196 P. R. China 1198 Phone: +86 755 2878 0808 1199 Email: yaoth@huawei.com 1200 Wenhui Zhou 1201 China Mobile 1202 53A, Xibianmen Ave, Xuanwu District 1203 Beijing 100 053 1204 P. R. China 1206 Phone: +86 10 6600 6688 ext.3061 1207 Email: zhouwenhui@chinamobile.com 1209 L. Lily Yang 1210 Intel Corp. 1211 JF3-206, 2111 NE 25th Ave. 1212 Hilsboro, OR 97124 1213 USA 1215 Phone: +1 503 264 8813 1216 Email: lily.l.yang@intel.com 1218 Hong Cheng 1219 Panasonic Singapore Laboratories 1220 Block 1022, Tai Seng Industrial Estate 1221 #06-3530, Tai Seng Avenue 1222 Singapore 534 415 1223 Singapore 1225 Phone: +65 6550 5447 1226 Email: hcheng@psl.com.sg 1228 Intellectual Property Statement 1230 The IETF takes no position regarding the validity or scope of any 1231 Intellectual Property Rights or other rights that might be claimed to 1232 pertain to the implementation or use of the technology described in 1233 this document or the extent to which any license under such rights 1234 might or might not be available; nor does it represent that it has 1235 made any independent effort to identify any such rights. Information 1236 on the procedures with respect to rights in RFC documents can be 1237 found in BCP 78 and BCP 79. 1239 Copies of IPR disclosures made to the IETF Secretariat and any 1240 assurances of licenses to be made available, or the result of an 1241 attempt made to obtain a general license or permission for the use of 1242 such proprietary rights by implementers or users of this 1243 specification can be obtained from the IETF on-line IPR repository at 1244 http://www.ietf.org/ipr. 1246 The IETF invites any interested party to bring to its attention any 1247 copyrights, patents or patent applications, or other proprietary 1248 rights that may cover technology that may be required to implement 1249 this standard. Please address the information to the IETF at 1250 ietf-ipr@ietf.org. 1252 Disclaimer of Validity 1254 This document and the information contained herein are provided on an 1255 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1256 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1257 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1258 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1259 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1260 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1262 Copyright Statement 1264 Copyright (C) The Internet Society (2005). This document is subject 1265 to the rights, licenses and restrictions contained in BCP 78, and 1266 except as set forth therein, the authors retain all their rights. 1268 Acknowledgment 1270 Funding for the RFC Editor function is currently provided by the 1271 Internet Society.