idnits 2.17.1 draft-mani-capwap-arch-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == Mismatching filename: the document gives the document name as 'draft-mani-ietf-capwap-arch-00', but the file name used is 'draft-mani-capwap-arch-00' == 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 are 6 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 186 has weird spacing: '...h which an AP...' == Line 347 has weird spacing: '... in a str...' == Line 376 has weird spacing: '...fferent parad...' == Line 695 has weird spacing: '...traffic in th...' == Line 837 has weird spacing: '...sioning an AP...' == (4 more instances...) == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (October 20, 2003) is 7493 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '4' is defined on line 1178, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 1186, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 1192, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 1199, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 1201, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Downref: Normative reference to an Informational RFC: RFC 3610 (ref. '3') -- Possible downref: Normative reference to a draft: ref. '4' -- Possible downref: Normative reference to a draft: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '8' == Outdated reference: A later version (-09) exists of draft-ietf-eap-rfc2284bis-06 -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' -- Possible downref: Non-RFC (?) normative reference: ref. '12' -- Possible downref: Non-RFC (?) normative reference: ref. '13' -- Possible downref: Non-RFC (?) normative reference: ref. '14' -- Possible downref: Non-RFC (?) normative reference: ref. '15' -- Possible downref: Non-RFC (?) normative reference: ref. '16' Summary: 5 errors (**), 0 flaws (~~), 16 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Mani 3 Internet-Draft Avaya Inc. 4 Expires: April 19, 2004 B. O'Hara 5 Airespace 6 L. Yang 7 Intel Corp. 8 October 20, 2003 10 Architecture for Control and Provisioning of Wireless Access 11 Points(CAPWAP) 12 draft-mani-ietf-capwap-arch-00 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that other 21 groups may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at http:// 29 www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on April 19, 2004. 36 Copyright Notice 38 Copyright (C) The Internet Society (2003). All Rights Reserved. 40 Abstract 42 While conventional wisdom has it that Wireless Access Points are 43 strictly Layer 2 bridges, such devices today perform some higher 44 layer functions of routers or switches in wired Infrastructure in 45 addition to bridging the wired and wireless networks. For example, 46 in 802.11 networks, Access Points can function as Network Access 47 Servers. For this reason, Access Points have IP addresses and can 48 function as IP devices. 50 This Document analyzes WLAN (Wireless LAN) functions and services; 51 and describes a flexible balance of such AP (Access Point) functions 52 as allowed in the Standards and practiced in the industry, to be 53 meaningfully split between lightweight Access Point (LAP) framework 54 and AP Controllers or AR (Access Router) framework managing them. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 59 1.1 Conventions used in this document . . . . . . . . . . . . . 4 60 1.2 CAPWAP Purpose and Scope . . . . . . . . . . . . . . . . . . 4 61 1.3 Document Organization . . . . . . . . . . . . . . . . . . . 4 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 63 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 3.1 The IEEE 802.11 in Brief . . . . . . . . . . . . . . . . . . 7 65 3.2 CAPWAP Motivation . . . . . . . . . . . . . . . . . . . . . 9 66 3.3 AP to AR Network Topology Considerations . . . . . . . . . . 10 67 4. CAPWAP Component Architecture . . . . . . . . . . . . . . . 12 68 4.1 WLAN functions and Services . . . . . . . . . . . . . . . . 12 69 4.1.1 Access Point Functions and Services . . . . . . . . . . . . 14 70 4.1.2 Access Controller Functions and Services . . . . . . . . . . 14 71 4.1.3 Other Conventional WLAN Functions and Services . . . . . . . 15 72 4.1.4 Architectural Trends . . . . . . . . . . . . . . . . . . . . 15 73 4.2 CAPWAP Network Topology . . . . . . . . . . . . . . . . . . 16 74 4.2.1 Functional Distribution of WLAN Services . . . . . . . . . . 16 75 4.2.2 AP to AR Topologies . . . . . . . . . . . . . . . . . . . . 16 76 4.3 CAPWAP Security . . . . . . . . . . . . . . . . . . . . . . 18 77 4.3.1 WLAN Security . . . . . . . . . . . . . . . . . . . . . . . 19 78 4.3.2 Mutual Authentication of AP and AR . . . . . . . . . . . . . 20 79 4.3.3 Path Security of AP and AR . . . . . . . . . . . . . . . . . 21 80 4.4 AP Provisioning . . . . . . . . . . . . . . . . . . . . . . 21 81 4.4.1 AP Identity . . . . . . . . . . . . . . . . . . . . . . . . 21 82 4.4.2 AP Configuration . . . . . . . . . . . . . . . . . . . . . . 21 83 4.4.3 Access Router Availability . . . . . . . . . . . . . . . . . 21 84 4.5 Access Point Service Management . . . . . . . . . . . . . . 22 85 4.5.1 Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . 22 86 4.5.2 Control . . . . . . . . . . . . . . . . . . . . . . . . . . 22 87 4.6 Access Router Discovery . . . . . . . . . . . . . . . . . . 23 88 4.6.1 Access Router Availability . . . . . . . . . . . . . . . . . 23 89 4.6.2 Capabilities Negotiation . . . . . . . . . . . . . . . . . . 23 90 4.7 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 24 91 5. Prior Work . . . . . . . . . . . . . . . . . . . . . . . . . 25 92 5.1 DIRAC . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 93 5.2 ForCES . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 94 5.2.1 Similarities in Objectives and Architectural 95 Considerations . . . . . . . . . . . . . . . . . . . . . . . 26 96 5.2.2 Overlap in Topology Considerations . . . . . . . . . . . . . 27 97 5.2.3 Differences in Design Approach . . . . . . . . . . . . . . . 27 98 5.2.4 Differences in the Functionality Controlled . . . . . . . . 27 99 5.2.5 Similarties in Security Requirements . . . . . . . . . . . . 27 100 5.2.6 Difference in Operation Scope . . . . . . . . . . . . . . . 28 101 5.2.7 Comparision in Protocols . . . . . . . . . . . . . . . . . . 28 102 6. Security Considerations . . . . . . . . . . . . . . . . . . 29 103 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 104 References . . . . . . . . . . . . . . . . . . . . . . . . . 31 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 32 106 Intellectual Property and Copyright Statements . . . . . . . 33 108 1. Introduction 110 1.1 Conventions used in this document 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in RFC 2119 [7]. 116 1.2 CAPWAP Purpose and Scope 118 The purpose of CAPWAP work is to define the framework reflecting the 119 architectural trend that delegates and aggregates selected WLAN 120 functions and services from APs to ARs to enhance WLAN resource 121 management. On the basis of such definition CAPWAP aims to provide a 122 secure protocol to enable AP-to-AR communications and AP provisioning 123 & management. 125 1.3 Document Organization 127 Overview section describes the IEEE 802.11 WLAN architecture and 128 services in brief followed by AP-AR network topological 129 considerations leading to CAPWAP motivation. 131 Subsequent section describes the CAPWAP architecture and its 132 components. 134 The section that follows discusses related research work and an 135 applicable standards topology. 137 The document concludes with Security Considerations which are also 138 discussed in Architecture. 140 2. Terminology 142 LWAP: Lightweight Access Point 144 AB/AR: Access Bridges/Routers 146 AC: Access Controllers 148 AP: access point 150 BSS: basic service set 152 ESS: extended service set 154 SSID: service set identifier 156 WLAN: wireless local area network 158 RSN: robust security network 160 TSN: transition security network 162 PMK: pair-wise master key 164 PTK: pair-wise transient key 166 TK: temporal key 168 GMK: group master key 170 GTK: group transient key 172 KCK: key confirmation key 174 KEK: key encryption key 176 PSK: pre-shared key 178 WEP: wired equivalent privacy 180 Throughout the document the terminologies of AR (Access Router), AC 181 (Access Controller) and AB (Access Bridge) are used synonymously in 182 contexts of allowable network topology arguments. In other cases the 183 distinction is called out explicityl. 185 However, at the outset AC is to be assumed the generic term for the 186 entity with which an AP registers or associates - which terms will 187 be qualified later in the CAPWAP architecture sections (Section 4). 189 AR is called out in the context that the Access Controller that an AP 190 associates with is over an allowed L3 cloud between the wired network 191 backend of APs and the ACs. 193 Access Bridge (or WLAN switch) is called out in the context of such 194 network cloud or connectivity may be over a predominantly L2 network. 196 It may be observed in following sections that the proposed 197 architecture chooses to stay agnostic and equivalent to either 198 Network Protocol and focuses on the interface and generic 199 encapsulation that shall allow for both. The Protocol MAY end up 200 specifying merely for IP. 202 3. Overview 204 Prior to setting out on details, a snapshot of WLAN standards are in 205 order to put the CAPWAP motivation and standardization benefits in 206 perspective, particularly when the required interfaces appear in the 207 landscape bordering L2 and L3 standards scope. 209 3.1 The IEEE 802.11 in Brief 211 The IEEE 802.11 standard for wireless local area networks [1] 212 specifies a MAC protocol, several PHYs, and a MAC management 213 protocol. Each of these operates over the air, between two or more 214 802.11 devices. 802.11 also describes how mobile devices can 215 associate together into a basic service set (BSS), the rough 216 equivalent of a single broadcast domain or a segment of a bridged 217 Ethernet LAN. A BSS is identified by a common service set identifier 218 (SSID) or name. An SSID is an arbitrary byte string, up to 32 bytes 219 long, though most implementations utilize ASCII strings for 220 readability. 802.11 also describes the functionality of a specific 221 device, called an access point (AP), that translates frames between 222 mobile 802.11 devices and hosts on a wired network. When more than 223 one AP is connected via a broadcast layer 2 network and all are using 224 the same SSID, an extended service set (ESS) is created. An ESS is 225 also similar to a single broadcast domain, where a mobile device 226 associated with one AP can successfully ARP for the address of a 227 mobile device associated with any other AP in the ESS. Within an 228 ESS, a mobile station can roam from one AP to another through only 229 layer 2 transitions coordinated by the 802.11 MAC management 230 protocol. Higher layer protocols, including IP are unaware that the 231 network attachment point of the mobile device has moved. 233 The 802.11 working group is currently proceeding on work related to 234 layer 2 security and quality of service. The 802.11i task group is 235 addressing the security issues of the original 802.11 standard in the 236 areas of authentication and encryption. This work refers to other 237 standards, including 802.1X Port Based Access Control [14] and the 238 Extensible Authentication Protocol [9]. The 802.11e task group is 239 addressing layer 2 quality of service items through extending the 240 access method, frame definitions, and MAC management protocol of the 241 original standard. This work refers to the 802.1Q [15] standard. 243 802.11 PHYs are wireless, by definition, and principally use radio 244 technology for communication. An aspect of an 802.11 WLAN that is 245 not addressed by the standard is the necessity to manage the 246 self-interference of one AP when operating on a radio channel equal 247 to or near the radio channel of another AP within reception range. 248 Managing self-interference within the WLAN involves both measurement 249 of the level of interference, as well as control of the transmit 250 power and transmitting channel in each of the APs. Work currently in 251 process in the 802.11k task group is addressing the issue of radio 252 resource measurement, which will provide the information on level of 253 interference, among other things. 255 Some definitions of 802.11 terminology is in order, since it is 256 unique to the 802.11 standard. 258 * "Distribution" is the service of forwarding MSDUs for an 259 associated station by an AP. As it is described in 802.11, 260 distribution by an AP is providing sufficient information to 261 enable a frame received from an associated station to be 262 successfully delivered to its proper destination. For the most 263 part, this involves translating the frame format from 802.11 to 264 Ethernet (typically) and removing any SNAP encapsulation that was 265 applied to the 802.11 frame, due to its lack of an equivalent to 266 the Ethertype field. This is similar to standard bridging, except 267 that 802.11 APs are not 802.1D bridges. APs typically do not 268 implement spanning tree protocols or algorithms. They are 269 considered to be edge devices, connected only to leaf nodes with 270 no further bridging taking place down stream from them. This is 271 not always a valid assumption and can sometimes result in 272 unanticipated bridging loops. 274 * "Integration" is a concept unique to 802.11 that is a result of 275 the underlying architecture. 802.11 considers that the individual 276 APs that make up a WLAN, an extended service set (ESS) in 802.11 277 terminology, are connected by a closed system, called the 278 distribution system. Only frames that are "within" the ESS are 279 carried by the distribution system. This includes frames that are 280 moving from one AP to another for delivery to a mobile station, 281 frames received from outside the ESS for delivery to a mobile 282 station, and frames from a mobile station to be delivered outside 283 the ESS. Connecting the closed distribution system to the outside 284 world is a "portal". The portal is the single point at which the 285 distribution system exchanges frames with the network outside of 286 the ESS. 288 The problem with the 802.11 architecture, or maybe just with the AP 289 implementations, is that AP implementations do not adhere to this 290 architecture. An AP typically implements both the distribution and 291 integration services, and the portal function, inside the skin of the 292 AP. In this sense, every AP is its own, isolated ESS and no APs 293 actually implement the architecture described in the standard. When 294 a set of APs is connected together to create a WLAN, what is actually 295 created is a set of independent ESSs that happen to communicate, in 296 spite of the implementation. 298 In addition to the 802.11 standard, the 802.11 working group produced 299 a recommended practice for inter-AP communication, 802.11F [12]. The 300 recommended practice describes the use of a new application protocol, 301 the Inter-AP Protocol (IAPP), carried on UDP or TCP. It permits APs 302 to exchange information about roaming mobile devices, including an 303 envelope for general context transfer purposes, and to push layer 2 304 keying information to neighboring APs in preparation for the roaming 305 of mobile devices to those neighboring APs. The recommended practice 306 specifies the use of 802.2 XID frames for updating layer 2 devices 307 when a mobile device's point of attachment to the network has changed 308 due to a roaming event. 802.11F also specifies the use of RADIUS for 309 the authentication of one AP to another and, along with portions of 310 the IAPP protocol, to establish secure IAPP packets exchanged between 311 participating APs. 313 The IAPP is not applicable to this architecture, though it may be 314 implemented in the access controller for communication with other 315 access controllers as 802.11 intended it to be used between 316 individual APs. It is not applicable within the CAPWAP architecture 317 because, presumably, the communications defined by CAPWAP would be 318 internal to the access controller and not require such a protocol to 319 be utilized. 321 3.2 CAPWAP Motivation 323 As evidenced over the past few months, there is overwhelming support 324 in the market for a new WLAN architecture. This architecture moves 325 much of the functions that would reside in a traditional access point 326 (AP) to a centralized access router (AR). Some of the benefits that 327 come out of this new architecture include: 329 o Ease of Use: By centrally managing a WLAN as a system rather than 330 as a series of discrete components, management and control of the 331 WLAN is much easier 333 o Increased Security: Having a centralized AR enforce policies and 334 being able to detect potential threats across a much larger RF 335 domain increases the security of the network. 337 o Enhanced Mobility: By terminating the WLAN "management" protocol 338 in the AR, these messages may be used as "mobility triggers", 339 providing mobility across an RF domain without the need for any 340 client software. 342 o Quality of Service: By allowing the centralized AR manage the RF 343 links, offers systemic perspective to perform efficient load 344 balancing across multiple Access Points - thus increasing the 345 efficiency of the wireless network. It also offers scope to have 346 higher layer applications influence roaming and placement policies 347 in a streamlined manner. 349 All of the above can be providing by terminating the 802.11 350 management frames in the AR. This approach is also commonly referred 351 to as Split AP, where the real-time components of the 802.11 protocol 352 are handled in the Access Point, while the access control components 353 of the 802.11 protocol terminate in the Access Router. 355 Having a module in the AR that understands 802.11 management frames 356 and 802.11 WLANs will provide much better control and optimization of 357 the WLAN operation than will an abstract, protocol-agnostic control 358 module. Adding support to CAPWAP/LWAPP for other wireless 359 technologies then becomes a task of encapsulating the new frames and 360 adding a new control module to the AR to handle the new technology. 361 Presumably, the LWAPP protocol and CAPWAP architecture will need 362 little, if any change. 364 3.3 AP to AR Network Topology Considerations 366 APs and ARs are linked directly as required by some architectures. 367 Among such classifications 369 1. ARCH0: The classic AP is at one of the spectrum interfaces to the 370 Infrastructure Network cloud with no specific connectivity to a 371 controller. In this case the AP can be considered to have a 372 self-contained controller possibly communicating with other APs 373 in the ESS to form a WDS. 375 2. ARCH1: APs which defer all WLAN functions other than real-time 376 services (Section 4.1) create a vastly different paradigm of 377 vertical (real-time frontend AP and aggregated backend AC) 378 functional distribution calling for a trust model between the two 379 and a discovery process of AC by AP. The latter (discovery) is 380 accentuated when the connectivity is through a cloud and there's 381 potential for m-to-n correspondence of AP-AR. 383 3. ARCH2: APs which tend to shift some normally real-time functions 384 as well to the backend with benefits such as extending OTA 385 (over-the-air) protection for AP-AR thus allowing for an extended 386 Trust Model for client data. 388 4. ARCH3: There's the case which carries (3) to render the AC as a 389 single "AP-switch" treating all connected APs as smart antennae. 391 While, at the outset, the architectures seem at wider variance, the 392 varied market requirements of 393 1. deployment scope 395 2. scalability 397 3. performance and 399 4. end-end security demands 401 seem to allow for all such architectures to have a role with varying 402 scope and limitations. This further underscores the argument to 403 provide a negotiable interface protocol. 405 4. CAPWAP Component Architecture 407 Given the preliminary outline of the three primary architecture types 408 (and a fourth variant) in Section 3.3 the predominant architectural 409 components are presented in three perspectives: 411 1. Functional & Service-based (WLAN standards) 413 2. Architectural Split 415 3. Topological 417 This is required as a means to realize the way the three aspects are 418 inter-dependent. 420 The Figure 1 illustrates the basic outline of communications 421 architecture between AP & AC. 423 | _ | 424 | Control/Provisioning ( )-|----Security 425 |<------------------------|-|>| 426 | Status/Download (_) | 427 | | 428 | _ | 429 | Data ( )-|----Security 430 |<------------------------|-|>| 431 | Forwarding (_) | 432 | | 433 | | 434 | Discovery | 435 |<--------------------------->| 436 | | 437 | | 438 | | 439 +------+ +--------+ 440 |Light | | Access | 441 |Weight| | Router | 442 | AP | | | 443 +------+ +--------+ 445 Figure 1: Basic Communications Framework 447 4.1 WLAN functions and Services 449 The IEEE 802.11 standard [1] says very little about the functionality 450 required of an AP. There is some discussion of the AP at a block 451 diagram level, in the General Description in clause 5 of the 452 standard. There, an AP is described as containing functional blocks 453 for 802.11 station services and for distribution system services. 454 Station services consist of the following four services: 456 a) Authentication 458 b) Deauthentication 460 c) Privacy 462 d) MSDU Delivery 464 Distribution system services consist of the following five services: 466 a) Association 468 b) Disassociation 470 c) Distribution 472 d) Integration 474 e) Reassociation 476 There are additional services that are required of an AP, that are 477 described in the MAC Layer Management Entity (MLME) in clause 11. 478 These additional management services are 480 a) Beaconing 482 b) Synchronization 484 c) Power Management 486 Other functionality that is not described, except implicitly in the 487 MIB, is control and management of the radio-related functions of an 488 AP. These include: 490 a) Channel Assignment 492 b) Transmit Power Control 494 c) Clear Channel Assessment 495 d) Radio Resource Measurement (work currently under way in IEEE 496 802.11k) 498 The 802.11h [13] amendment to the base 802.11 standard specifies the 499 operation of a MAC management protocol to accomplish the requirements 500 of some regulatory bodies (principally in Europe, but expanding to 501 others) in these areas: 503 a) RADAR detection 505 b) Transmit Power Control 507 c) Dynamic Channel Selection 509 4.1.1 Access Point Functions and Services 511 The services that MUST be in a lightweight AP are those that are 512 directly related to the real-time aspects of the 802.11 MAC protocol 513 and those related to the radio nature of an 802.11 AP. These 514 functions are: 516 a) Privacy 518 b) MSDU Delivery 520 c) Beaconing 522 d) Synchronization 524 e) Power Management 526 f) Channel Assignment 528 g) Transmit Power Control 530 h) Clear Channel Assignment 532 i) Radio Resource Measurement 534 j) RADAR detection 536 4.1.2 Access Controller Functions and Services 538 The functions that MAY be moved from the lightweight AP and located 539 in the AR are those dealing with the management and control aspects 540 of an 802.11 AP. These are the distribution system services, in 541 addition to authentication and deauthentication services. These 542 functions are: 544 a) Authentication 546 b) Deauthentication 548 c) Association 550 d) Disassociation 552 e) Reassociation 554 f) Distribution 556 g) Integration 558 h) Dynamic Channel Selection 560 i) Dynamic Control of transmit power 562 4.1.3 Other Conventional WLAN Functions and Services 564 "Heavy" Access Points being the bridge to the wired world MAY (and 565 normally do) also support various services and protocols that provide 566 seamless connectivity of WLAN clients to the wired network such as 568 a) Port and Protocol-based VLANs 570 b) SNMP 572 c) QoS (DiffServ and 802.1Q) mapping 574 d) IP routing 576 e) DHCP relay/server 578 f) RADIUS client/proxy 580 g) MobileIP (client proxy) 582 Based on the definition of lightweight access points these services 583 SHOULD qualify for offloading to the AR. 585 4.1.4 Architectural Trends 586 4.2 CAPWAP Network Topology 588 The CAPWAP network topology primarily consists of the WLAN topology 589 and the AP-AC (AP-AR) topology. 591 The WLAN topology is straightforward and is as described in Overview 592 section. This is not of much current interest as the relevant portal 593 variants of WLAN are applicable equally to all new AP-AC topologies. 595 4.2.1 Functional Distribution of WLAN Services 597 Functional distribution of WLAN services described in earlier 598 sub-sections are partly an artifact of the architecture types 599 ARCH0-3. However, they may result in AP-AC topological constraints. 600 Such constraints include direct connectivity to the AC being required 601 and in most cases mandate L2 connectivity. 603 4.2.2 AP to AR Topologies 605 CAPWAP assumes that the AR and AP are within the same administrative 606 domain, i.e. they are owned/controlled by the same entity. CAPWAP 607 makes no topological assumptions beyond these, meaning there are 608 several topologies which must be considered for our purposes. 610 --------------------------------------------------------------------- 612 -------+------ LAN 613 | 614 +-------+-------+ 615 | + + AR + + | 616 +----+-----+----+ 617 | | 618 +---+ +---+ 619 | | 620 +--+--+ +--+--+ 621 | AP | | AP | 622 +--+--+ +--+--+ 624 --------------------------------------------------------------------- 626 Figure 2: Directly Connected 628 --------------------------------------------------------------------- 630 -------+------ LAN 631 | 632 +-------+-------+ 633 | + + AR + + | 634 +----+-----+----+ 635 | | 636 +---+ +---+ 637 | | 638 +--+--+ +-----+-----+ 639 | AP | | Switch | 640 +--+--+ +---+-----+-+ 641 | | 642 +--+--+ +----+ 643 | AP | | 644 +--+--+ +--+---+ 645 | host | 646 +------+ 648 --------------------------------------------------------------------- 650 Figure 3: Switched Connections 652 --------------------------------------------------------------------- 654 +-------+-------+ 655 | + + AR + + | 656 +-------+-------+ 657 | 658 --------+------ LAN 659 | 660 +-------+-------+ 661 | router | 662 +-------+-------+ 663 | 664 -----+--+--+--- LAN 665 | | 666 +---+ +---+ 667 | | 668 +--+--+ +--+--+ 669 | AP | | AP | 670 +--+--+ +--+--+ 672 --------------------------------------------------------------------- 674 Figure 4: Routed Connections 676 4.3 CAPWAP Security 678 The CAPWAP architecture spans more than the topology over the air. 679 IEEE 802.11 (and now 802.11i) describes the single-hop security 680 over-the-air. 682 The resulting security scheme only protects the data frames 683 (multicast, broadcast and unicast) between stations and AP. 685 This leaves a security gap in the CAPWAP topology between AP and AC 686 (AR). 688 As discussed earlier security of control and management traffic 689 between the AP and AR subsystem, needs to be secured, failing which 690 control of AP can be compromised. 692 In addition there may be explicit requirements to secure the data 693 flow between AP and AR segment. This is end-end traffic between WLAN 694 stations and their WLAN/wireline destinations invariant to CAPWAP 695 considerations. Protection of this traffic in this segment may 696 incidentally ensue in architectures such as in ARCH2 and ACRH3. 698 4.3.1 WLAN Security 700 802.11 provides layer 2 authentication and privacy services. Severe 701 deficiencies have been documented in the mechanisms of the original 702 standard. The current task group, 802.11i, is completing work on an 703 amendment to the standard that addresses these deficiencies. The 704 requirements for 802.11i are more difficult than simply providing the 705 desired level of protection for the information carried by 802.11 706 frames in new equipment. 802.11i must also provide a mechanism that 707 can be used by equipment already deployed, to eliminate the 708 deficiencies of the original standard to which the equipment was 709 built. 711 WLAN Security offers over-the-air single-hop MAC-layer frame security 712 for data frames between Mobile Stations and AP's. This is built on 713 top of 802.1X-based authentication and Session and Data-encryption 714 Key Exchanges derived thereof. 716 4.3.1.1 Authentication - EAP over LAN (802.1X) 718 802.11i specifies an extensible authentication method, based on 719 negotiation between the AP and mobile device that occurs during the 720 association process. After successfully negotiating the particular 721 authentication method to be used, the mobile device is allowed to 722 associate, but must immediately complete the negotiated 723 authentication before any data exchange will be permitted. 725 The default mechanism for authentication defined by 802.11i is to 726 piggyback on the 802.1X standard, using EAP to authenticate the 727 mobile device or user after 802.11 association with an AP has 728 completed. In the terms defined in 802.1X, an AP is an authenticator 729 and a mobile device is a supplicant. The AP, as authenticator, 730 proxies the supplicant's communications to an authentication system. 731 An example authentication system is a RADIUS server. The AP 732 communicates with the RADIUS server, as a RADIUS proxy for the 733 client, using EAP. The AP is responsible for blocking the (logical) 734 controlled port for the associated device until the successful 735 completion of the 802.1X authentication. At the conclusion of the 736 802.1X authentication, keying material is available to both the 737 mobile device and AP that can be used for frame security. 739 4.3.1.2 Frame Security (802.11i) 741 802.11i Frame Security offers Encryption, Message Integrity and 742 Replay Protection services. 744 To meet the requirements of improving security for both existing 745 devices and new devices, 802.11i specifies two security mechanisms, 746 the Transition Security Network (TSN) and the Robust Security Network 747 (RSN). Both TSN and RSN utilize keying material derived from an 748 802.1X-based authentication exchange to deliver a pair-wise master 749 key (PMK) to both the mobile device and AP. TSN can also use a 750 preshared key (PSK) to derive a PMK without the use of an 751 authentication exchange. From the PMK is derived a pair-wise 752 transient key (PTK). The PTK is used to create a pair-wise temporal 753 key (TK), an EAPOL key encryption key (KEK), and an EAPOL key 754 confirmation key (KCK). An 802.1X exchange is also used to deliver 755 the keying material to derive a group master key (GMK). From the GMK 756 is derived a group transient key (GTK). The GTK is used to create a 757 group temporal key (TK) used by the AP to encrypt multicast frames 758 and by the mobile devices to decrypt multicast frames. 760 TSN specifies a means to improve the security of equipment built with 761 the original RC4-based wired equivalent privacy (WEP) cipher. TSN 762 requires that the encryption key used with WEP be rotated on every 763 packet. TSN specifies the algorithm for this key rotation, based on 764 the pair-wise TK and the frame sequence counter. In addition, TSN 765 specifies an algorithm for a keyed message integrity code (MIC) (more 766 often called message authentication code (MAC), but that acronym is 767 already utilized in the 802.11 standard), called Michael. Michael is 768 a compromise between strength and computational requirements, because 769 this must operate on legacy equipment with fixed computational 770 capabilities. As a result, TSN also specifies some rather severe 771 countermeasures to be implemented when an attack against the MIC is 772 suspected. 774 RSN specifies an encapsulation and algorithm for new equipment that 775 is significantly stronger than either WEP or TSN. The algorithm is 776 an AES mode called Counter Mode with CBC-MAC (CCM)[3]. This AES mode 777 provides data privacy, data integrity, and source integrity with low 778 additional computational requirements beyond data privacy, alone. 780 4.3.2 Mutual Authentication of AP and AR 782 As detailed in Section 4.3, the need to enforce secure communication 783 requires a mutual strong authentication protocol and an associated 784 Key Management protocol that derives from the trust established the 785 authentication phase. The resulting key material is used to derive 786 session keys and subsequent key agreement for setting up secure 787 encapsulation of AP-AR meta-communications. 789 The Key Management protocol choices are governed by the worst-case 790 specification of Lightweight AP (LAP) capabilities. 792 4.3.3 Path Security of AP and AR 794 The secure communications MUST support confidentiality, message 795 authentication and replay protection. The choice of ciphers should 796 consider the required strength and threat model as well as the 797 compute capabilities, real-time nature and relative bandwidth of such 798 traffic. 800 4.4 AP Provisioning 802 In order to create a trust model between the AP subsystem and AC 803 subsystem for secure communications enabling automatic discovery, 804 configuration and adaptive resource management the AP's need to be 805 set up securely in the AC(AR)'s domain. 807 4.4.1 AP Identity 809 Identity of the AP is established reliably by cryptographically 810 secure binding of an AP's unique identity such one of its wireline 811 MAC addresses to a cryptographic key. 813 4.4.2 AP Configuration 815 Configuration of an AP includes providing the parameters necessary 816 for the AP to advertise and provide service for one or more WLANs. 817 These parameters are both physical and logical. 819 Physical parameters are related to the operation of the AP's radio 820 interface. These include the channel on which the AP is to operate, 821 the maximum power at which the AP is to transmit, antenna selections, 822 the supported data rates, and the timing for the periodic 823 announcements of the WLANs provisioned on the AP. 825 Logical parameters are related to the individual WLANs that are 826 provisioned on the AP. These include the SSID of the WLANs, the 827 allowed authentication methods, the allowed privacy methods, values 828 for the contention-free period and DTIM, VLAN associations, IP 829 addresses and netmasks, authentication server addresses, any 830 pre-shared keys for WLANs or authentication servers, regulatory 831 (country) information, and other 802.11-specific capabilities to be 832 advertised for the WLANs. 834 4.4.3 Access Router Availability 836 Also discussed later in Section 4.6 in discovery context, as part of 837 provisioning an AP one may configure the ability to offer redundancy 838 of ACs or based on negotiated architecture. Constrained architectures 839 with limited AP-AR topologies may be unable to offer flexible 840 redundancies and may require hardware supported alternatives. 842 4.5 Access Point Service Management 844 In a large WLAN system with many APs, continuous management of those 845 APs is necessary to enable quick reaction to changes in service 846 capabilities caused by internal or external factors such as 847 dynamically varying hotspot loads and time-variant fluctuations in 848 RF interferences due to extraneous negihborhood devices. An adaptive 849 RF management based on dynamic systemic monitoring and power and 850 frequency management is needed to be driven from ACs (or at times a 851 hierarchy of ACs). 853 4.5.1 Monitoring 855 Each AP in a WLAN must be monitored for a number of variables. This 856 is needed to be able to assess the ability of the individual AP to 857 meet the service demands placed upon it. Among the variables that 858 need to be monitored are: 860 a) instantaneous data load 862 b) peak and average load over a configurable monitoring period 864 c) Measurements of interference from neighboring BSS's 866 d) number of mobile devices associated 868 e) statistics for each associated mobile device 870 f) Signal Strength of Received Frames 872 g) RADAR detection 874 4.5.2 Control 876 Maintaining the operation of a large WLAN system at or near its peak 877 capability requires that the individual APs that comprise that system 878 must be controlled to adapt to changes in the internal or external 879 factors that affect the performance of the system as a whole. In 880 particular, the aspects of an AP that require control are the 881 following: 883 a) Access Controller to which the AP is connected 884 b) enabling and disabling the operation of the AP 886 c) Enabling and Disabling operation of individual radios at an AP 888 d) establishment and update of session keys for protection of AC/AP 889 communication 891 e) Radio channel for transmission 893 f) Transmit Power 895 4.6 Access Router Discovery 897 When a AP comes alive on a network it may authenticate and register 898 with one or more ARs it detects on the network it is connected to. In 899 some architectures today the ARs are the bridges they directly 900 connect to. It performs a AR discovery procedure in its network 901 neighborhood. Based on the Network Topology and Layering it MAY 902 attempt a L2 or IP discovery of ACs. This will also depend partly on 903 the architectural capabilities of the AP and of available ARs. The 904 type of discovery protocol is also dependent on prior one-time 905 Provisioning of AP (configuration). The identification of ARs is only 906 dependent on the L2 or IP protocol used but is expected to be 907 architecture-agnostic. It is the Capability Negotiation Phase 908 (Section 4.6.2) that follows which resolves the mutual capabilities 909 of AP and AC which lets them decide to AP register with one or more 910 AC. 912 4.6.1 Access Router Availability 914 CAPWAP discovery entails the ability of an AP to failover to another 915 AR in the same domain (ESS) in the event of the failure of the 916 current AR. 918 Failure detection and failover may use existing IP protocols such as 919 VRRP or extensions thereof. 921 4.6.2 Capabilities Negotiation 923 An AP performs AR discovery in its network neighborhood. Upon having 924 discovered available ARs the AP enters into a capabilities exchange 925 phase with the candidate ACs. If the architectural types match during 926 the exchange - the AP registers with the AC and configures itself 927 based on the policies it derives from the AC after mutually 928 authenticating with the AC. The capabilities negotiated by 929 architectural type match will decide the applicable API's between AP 930 and AC. 932 4.7 Summary 934 The CAPWAP allows for a set of flexible architectures as described in 935 Section 4.1.4 The architecture proposes the following set of CAPWAP 936 services to achieve the Security, Ease of Management, Enhanced QoS 937 and Mobility objectives across the WLAN domain: 939 o AC Discovery 941 o Capability Negotiation 943 o Mutual Authentication of AP and AC 945 o Secure Encapsulation Protocol based on Secure Key Management 947 o Secure AP Configuration from AC 949 o Secure Encapsulation of Control and/or Data between AP & AC 951 5. Prior Work 953 Related work on such problems have been dealt with in Academia 954 (Section 5.1) and standards (Section 5.2). The former is more 955 directly related to the proposed CAPWAP architecture. The latter is a 956 generic solution attempted to address distributed data-forwarding 957 front-ends with highly available control-plane backends. 959 5.1 DIRAC 961 DIRAC is a DIstributed Router ArChitecture for wireless networks, 962 independently developed by a research group in UCLA. DIRAC [16] 963 adopts a very similar distributed architecture to what is proposed 964 here that is composed of a generic Router Core (RC) shared by the 965 wireless subnets and a lightweight and network specific Router Agent 966 (RA) at each access point/base station. The Router Core in DIRAC 967 corresponds to AR in CAPWAP while the Router Agents are the APs. 969 While the architecture and end goals of DIRAC are very similar to 970 CAPWAP, there are several difference that are worth pointing out: 972 o The Router Core at DIRAC is intended to be generic and agnostic to 973 the L2 radio technology being used between the Router Agent and 974 the client terminals. This is achieved by terminating the radio 975 specific L2 connection at the Router Agent while the statistics/ 976 actions(i.e.,control)/events messages that are exchanged between 977 the Router Core and the Router Agent are abstracted into a 978 different and generic packet format. CAPWAP, on the other hand, 979 simply encapsulates the 802.11 management frames from APs to ARs 980 so that ARs have to fully understand 802.11 frame format. 982 o No security is being considered in the DIRAC work which is 983 probably ok for academic research but not ok for IETF standard. 985 o The DIRAC paper focuses less on the protocol between the RC and RA 986 but a lot more on the architecture and implementation issues in 987 this work. The protocol consists of three kinds of messages: 988 statistics, actions (i.e., controls) and (asynchronous) events. 989 DIRAC does not consider the issue of discovery and firmware image 990 downloading etc. 992 o The DIRAC paper provides three prototype wireless services that 993 are implemented within the DIRAC framework to demonstrate not only 994 the potential performance gain but also the viability of these new 995 wireless services being enabled by such a framework. These 996 examples provide some nice academic data points for CAPWAP. 998 5.2 ForCES 1000 The IETF ForCES (Forwarding and Control Element Separation) group was 1001 chartered to "define a framework and associated mechanisms for 1002 standardizing the exchange of information between the logically 1003 separate functionality of the control plane, including entities such 1004 as routing protocols, admission control, and signaling, and the 1005 forwarding plane, where per-packet activities such as packet 1006 forwarding, queuing, and header editing occur. By defining a set of 1007 standard mechanisms for control and forwarding separation, ForCES 1008 will enable rapid innovation in both the control and forwarding 1009 planes. A standard separation mechanism allows the control and 1010 forwarding planes to innovate in parallel while maintaining 1011 interoperability." 1013 5.2.1 Similarities in Objectives and Architectural Considerations 1015 While ForCES aims to provide interoperability between CEs and FEs 1016 from different vendors, CAPWAP has a very similar goal in mind -- to 1017 allow APs and ARs from different vendors interoperable when mixed and 1018 matched in the wireless access networks. Even though ForCES 1019 originally was heavily focused on routers to achieve interoperability 1020 between Forwarding Elements (FEs) and Control Elements (CEs) inside a 1021 router (i.e., Network Element -- NE), many similarities or analogies 1022 can be found between ForCES architecture and CAPWAP architecture: 1024 o "The APs can be considered as remote RF interfaces, being 1025 controlled by the AR" [LWAPP spec] -- it is clear that APs in the 1026 CAPWAP architecture can be viewed as FEs in the ForCES 1027 architecture, or more precisely, APs can be viewed as a specific 1028 wireless port function (Logical Functional Block, LFB, using 1029 ForCES's terminology) that is part of the FEs. 1031 o The LWAPP-related functionality of AR in the wireless access 1032 network is mostly control plane related and hence the AR can be 1033 considered a CE from the ForCES point of view. It should be noted 1034 that the AR also performs forwarding functions, and as such, could 1035 also be internally viewed as a CE/FE combination, although usage 1036 of ForCES to control APs by the AR would not necessitate usage of 1037 ForCES within the AR. 1039 o "AR + multiple lite-weight APs" as a whole then can be considered 1040 as a distributed router with some parts of the FEs (APs) 1041 physically separated from the CEs. 1043 5.2.2 Overlap in Topology Considerations 1045 While it is possible to construct a NE out of CEs and FEs which are 1046 physically separated by a routed (L3) cloud, ForCES constraint itself 1047 to focus on very close localities consisting of CE and FEs that are 1048 either components in the same physical box, or are separated at most 1049 by one local network (L3) hop. This topology overlaps with the three 1050 topologies -- directly connected, switched (L2), or routed (L3) -- 1051 considered by CAPWAP as well. But if CAPWAP support arbitrary routed 1052 cloud (with multiple L3 hops) between AP and AR, we need to carefully 1053 examine ForCES and see if it can accommodate such topology while 1054 still satisfying all the requirements including security. 1056 5.2.3 Differences in Design Approach 1058 The general design behind ForCES is to separate the base protocol 1059 from the actual information elements that carry the control/ 1060 configuration/monitoring/events messages between the CE and FE, due 1061 to the diversity of FE functions among data plane vendors. The 1062 information elements that are specific to any particular FE (e.g., 1063 IPv4 forwarding, or DiffServ, or MPLS) are represented in FE model. 1064 Such design allows ForCES to be very flexible and extensible to 1065 accommodate wide spectrum of data plane functions, possibly including 1066 IEEE 802.11 wireless AP functions. The current LWAPP protocol is 1067 taking a very different design approach. LWAPP is a very domain 1068 specific protocol. While the general domain for LWAPP can potentially 1069 include any wireless radio technologies, the current spec of LWAPP is 1070 very much IEEE 802.11 specific and many of the 802.11 functions are 1071 assumed and built into the protocol directly. 1073 5.2.4 Differences in the Functionality Controlled 1075 The FE functions being controlled by CE via ForCES are mostly L3 and 1076 L4, but sometimes L2 (e.g., ARP). On the other hand, the AP 1077 functions that are being controlled by ARs are mostly L2 (IEEE 1078 802.11MAC), but sometimes higher layer as well (if those functions 1079 reside on APs). 1081 5.2.5 Similarties in Security Requirements 1083 The security requirements in both the CAPWAP and ForCES appear to 1084 overlap significantly, in terms of secure association, 1085 authentication, confidentiality, integrity, anti-replay, etc. Even 1086 though ForCES has not finalized on its protocol selection (among 1087 three proposals) yet, ForCES framework document recommends that 1088 ForCES adopt one of the standard security mechanisms (IPsec or TLS). 1089 More close examination of security requirements and mechanisms 1090 employed in ForCES and CAPWAP is needed here. 1092 5.2.6 Difference in Operation Scope 1094 Even though no specific discovery mechanism is specified in the 1095 current LWAPP spec, CAPWAP does consider AR discovery in scope; on 1096 the other hand, ForCES considers the process of CE and FE discovering 1097 each other out of scope. ForCES assumes CEs and FEs enter the 1098 post-association phase with knowledge of which corresponding entities 1099 they are authorized to communicate with, but ForCES itself does not 1100 address how pre-association is done. 1102 5.2.7 Comparision in Protocols 1104 ForCES currently has three protocol proposals and the WG has just 1105 started the protocol evaluation and selection process. Therefore, it 1106 is difficult to compare LWAPP with ForCES at the moment from the 1107 protocol view-point, unless one compares LWAPP with all the three 1108 proposals first. 1110 But ForCES requirement document captures all the important 1111 requirements that ForCES protocol is supposed to support. Merely 1112 comparing LWAPP with this set of requirements can already provide 1113 some insight. 1115 The most obvious difference in the two protocols may very well be due 1116 to fundamentally different design philosophies behind the two as 1117 pointed out in Section 5.2.4. LWAPP is a domain specific protocol 1118 withsome messages assuming 802.11 sematics, while the base ForCES 1119 protocol only supports the general procedures involved for setting up 1120 association between the CE and FE, CE querying FE its capability and 1121 configuration state (if any), CE provisioning FE according to the 1122 basic capability leaned in the querying stage, and FE reporting 1123 statistics and asynchronous events to CE, etc. In the context of 1124 ForCES, the messages with 802.11 specific semantics would not appear 1125 in the base ForCES protocol. Instead, an 802.11 FE (or LFB) model 1126 would have to be specified to support all the 802.11 specific 1127 configuration, statistics, and events. 1129 Another major difference is on reliability requirement. The ForCES 1130 protocol is required to support strict reliability for mission 1131 critical payloads. On the other hand, LWAPP does not assume any 1132 reliability between the AR and AP, because it is built on top of L2 1133 or IP directly. 1135 One thing that LWAPP supports but none of the ForCES protocol 1136 proposals directly address is firmware image downloading. 1138 6. Security Considerations 1140 One of the major goals of the CAPWAP architecture is to ensure strong 1141 authentication of AP to the registered AR and secure communications 1142 between them as described in the preceding sections. 1144 AR-AP traffic can be classified into: data traffic (e.g. from or to 1145 an end user), and control traffic which is strictly between the AR 1146 and AP. Since data traffic may be secured end-to-end security 1147 mechanisms outside the scope of this work, we confine our solution to 1148 control traffic. The resulting security consists of two components: 1149 an authenticated key exchange, and control traffic security 1150 encapsulation. The security encapsulation may be accomplished using 1151 relatively lightweight mechanisms such as CCM, described in [2]. 1152 This encapsulation provides for strong AES-based message 1153 authentication and encryption. Detailed discussions of such possible 1154 security protocol alternatives is out of scope in this document. 1156 7. Acknowledgements 1158 The authors wish to thank the timely inputs and discussions provided 1159 by Pat Calhoun towards completion of this document in a very short 1160 time. In no less measure our thanks go to Scott Kelly et al in kindly 1161 consenting to let us adapt from their topological and architectural 1162 analysis in [5] that helped us shorten the time to draft. The authors 1163 also wish to thank IESG & IAB for their feedback, particularly Randy 1164 Bush, James Kempf and Bernard Aboba for the discussions that has 1165 helped focus this draft objective. Thanks are also due to Dorothy 1166 Stanley in this regard for the IEEE perspective. 1168 References 1170 [1] "IEEE WLAN MAC and PHY Layer Specifications", August 1999, 1171 . 1173 [2] "Advanced Encryption Standard (AES)", November 2001, . 1176 [3] "Counter with CBC-MAC (CCM)", September 2003, . 1178 [4] "Light Weight Access Point Protocol (LWAPP)", June 2003, 1179 . 1182 [5] "Security Requirements for a Light Weight Access Point 1183 Protocol", August 2003, . 1186 [6] "The Internet Standards Process Revision 3", October 1996, 1187 . 1189 [7] "Key words for use in RFCs to Indicate Requirement Levels", 1190 March 1997, . 1192 [8] "Mobility Related Terminology", April 2003, . 1195 [9] "Extensible Authentication Protocol (EAP)", September 2003, 1196 . 1199 [10] "WiFi Protected Access (WPA) ver 2.0", April 2003. 1201 [11] "IEEE Std 802.11i/6.0: Specification for Enhanced Security", 1202 September 2003. 1204 [12] "IEEE Std 802.11F: Recommended Practice for Multi-Vendor Access 1205 Point Interoperability via an Inter-Access Point Protocol 1206 across Distribution Systems Support 802.11 Operation", July 1207 2003. 1209 [13] "IEEE Std 802.11h: Spectrum and Transmit Power Management 1210 Extensions in the 5 GHz Band in Europe", October 2003. 1212 [14] "IEEE Std 802.1X: Port-based Network Access Control", June 1213 2001. 1215 [15] "IEEE Std 802.1Q: Virtual Bridged Local Area Networks", May 1216 2003. 1218 [16] "DIRAC: A Software-based Wireless Router System", 2003. 1220 Authors' Addresses 1222 Mahalingam Mani 1223 Avaya Inc. 1224 1001 Murphy Ranch Rd 1225 Milpitas, CA 95035 1227 Phone: +1 408-321-4840 1228 EMail: mmani@avaya.com 1230 Bob O'Hara 1231 Airespace 1232 110 Nortech Parkway 1233 San Jose, CA 95134 1235 Phone: +1 408-635-2025 1236 EMail: bob@airespace.com 1238 L. Lily Yang 1239 Intel Corp. 1240 MS JF3 206, 2111 NE 25th Avenue 1241 Hillsboro, OR 97124 1243 Phone: +1 503-264-8813 1244 EMail: lily.l.yang@intel.com 1246 Intellectual Property Statement 1248 The IETF takes no position regarding the validity or scope of any 1249 intellectual property or other rights that might be claimed to 1250 pertain to the implementation or use of the technology described in 1251 this document or the extent to which any license under such rights 1252 might or might not be available; neither does it represent that it 1253 has made any effort to identify any such rights. Information on the 1254 IETF's procedures with respect to rights in standards-track and 1255 standards-related documentation can be found in BCP-11. Copies of 1256 claims of rights made available for publication and any assurances of 1257 licenses to be made available, or the result of an attempt made to 1258 obtain a general license or permission for the use of such 1259 proprietary rights by implementors or users of this specification can 1260 be obtained from the IETF Secretariat. 1262 The IETF invites any interested party to bring to its attention any 1263 copyrights, patents or patent applications, or other proprietary 1264 rights which may cover technology that may be required to practice 1265 this standard. Please address the information to the IETF Executive 1266 Director. 1268 Full Copyright Statement 1270 Copyright (C) The Internet Society (2003). All Rights Reserved. 1272 This document and translations of it may be copied and furnished to 1273 others, and derivative works that comment on or otherwise explain it 1274 or assist in its implementation may be prepared, copied, published 1275 and distributed, in whole or in part, without restriction of any 1276 kind, provided that the above copyright notice and this paragraph are 1277 included on all such copies and derivative works. However, this 1278 document itself may not be modified in any way, such as by removing 1279 the copyright notice or references to the Internet Society or other 1280 Internet organizations, except as needed for the purpose of 1281 developing Internet standards in which case the procedures for 1282 copyrights defined in the Internet Standards process must be 1283 followed, or as required to translate it into languages other than 1284 English. 1286 The limited permissions granted above are perpetual and will not be 1287 revoked by the Internet Society or its successors or assignees. 1289 This document and the information contained herein is provided on an 1290 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1291 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1292 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1293 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1294 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1296 Acknowledgment 1298 Funding for the RFC Editor function is currently provided by the 1299 Internet Society.