ŠĀ CAPWAP Working Group L. Yang (Editor) Internet-Draft Intel Corp. Expires: December 28, 2004 P. Zerfos UCLA E. Sadot Avaya June 29, 2004 Architecture Taxonomy for Control and Provisioning of Wireless Access Points(CAPWAP) draft-ietf-capwap-arch-03 Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 28, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document provides a taxonomy of the architectures employed in the existing IEEE 802.11 products in the market, by analyzing WLAN (Wireless LAN) functions and services and describing the different variants in distributing these functions and services among the architectural entities. This taxonomy may be utilized by the IEEE Yang (Editor), et al. Expires December 28, 2004 [Page 1] Internet-Draft CAPWAP Arch. Taxonomy June 2004 802.11 Working Group as input to their task of defining the Access Point (AP) functional architecture. Table of Contents 1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1 Conventions used in this document . . . . . . . . . . . . 4 1.2 IEEE 802.11 Definitions . . . . . . . . . . . . . . . . . 4 1.3 Terminology Used in this Document . . . . . . . . . . . . 5 1.4 Terminology Used Historically but Not Recommended . . . . 7 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.1 IEEE 802.11 WLAN Functions . . . . . . . . . . . . . . . . 8 2.2 CAPWAP Functions . . . . . . . . . . . . . . . . . . . . . 10 2.3 WLAN Architecture Proliferation . . . . . . . . . . . . . 11 2.4 Taxonomy Methodology and Document Organization . . . . . . 13 3. Autonomous Architecture . . . . . . . . . . . . . . . . . . . 15 3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.2 Security . . . . . . . . . . . . . . . . . . . . . . . . . 15 4. Centralized WLAN Architecture . . . . . . . . . . . . . . . . 17 4.1 Interconnection Topology between WTPs and ACs . . . . . . 18 4.2 Overview of Three Centralized WLAN Architectures . . . . . 19 4.3 Local MAC . . . . . . . . . . . . . . . . . . . . . . . . 21 4.4 Split MAC . . . . . . . . . . . . . . . . . . . . . . . . 24 4.5 Remote MAC . . . . . . . . . . . . . . . . . . . . . . . . 29 4.6 Comparisons of Local MAC, Split MAC and Remote MAC . . . . 29 4.7 Communication Interface between WTPs and ACs . . . . . . . 30 4.8 Security . . . . . . . . . . . . . . . . . . . . . . . . . 31 4.8.1 Client Data Security . . . . . . . . . . . . . . . . . 31 4.8.2 Security of control channel between WTP and AC . . . . 32 5. Distributed Mesh Architecture . . . . . . . . . . . . . . . . 33 5.1 Security . . . . . . . . . . . . . . . . . . . . . . . . . 34 6. Summary and Conclusions . . . . . . . . . . . . . . . . . . . 35 7. Security Considerations . . . . . . . . . . . . . . . . . . . 38 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 39 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 41 A. WLAN Architecture Survey Template . . . . . . . . . . . . . . 42 B. Survey Contribution For Architecture 1 . . . . . . . . . . . . 43 C. Survey Contribution For Architecture 2 . . . . . . . . . . . . 48 D. Survey Contribution For Architecture 3 . . . . . . . . . . . . 52 E. Survey Contribution For Architecture 4 . . . . . . . . . . . . 55 F. Survey Contribution For Architecture 5 . . . . . . . . . . . . 59 G. Survey Contribution For Architecture 6 . . . . . . . . . . . . 63 H. Survey Contribution For Architecture 7 . . . . . . . . . . . . 67 I. Survey Contribution For Architecture 8 . . . . . . . . . . . . 69 J. Survey Contribution For Architecture 9 . . . . . . . . . . . . 72 K. Survey Contribution For Architecture 10 . . . . . . . . . . . 76 L. Survey Contribution For Architecture 11 . . . . . . . . . . . 79 Yang (Editor), et al. Expires December 28, 2004 [Page 2] Internet-Draft CAPWAP Arch. Taxonomy June 2004 M. Survey Contribution For Architecture 12 . . . . . . . . . . . 84 N. Survey Contribution For Architecture 13 . . . . . . . . . . . 86 O. Survey Contribution For Architecture 14 . . . . . . . . . . . 88 P. Survey Contribution For Architecture 15 . . . . . . . . . . . 90 Q. Survey Contribution For Architecture 16 . . . . . . . . . . . 92 Intellectual Property and Copyright Statements . . . . . . . . 96 Yang (Editor), et al. Expires December 28, 2004 [Page 3] Internet-Draft CAPWAP Arch. Taxonomy June 2004 1. Definitions 1.1 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [4]. 1.2 IEEE 802.11 Definitions Station (STA): Any device that contains an IEEE 802.11 conformant medium access control (MAC) and physical layer (PHY) interface to the wireless medium (WM). Access Point (AP): Any entity that has station functionality and provides access to the distribution services, via the wireless medium (WM) for associated stations. Basic Service Set (BSS): A set of stations controlled by a single coordination function. Station Service (SS): The set of services that support transport of medium access control (MAC) service data units (MSDUs) between stations within a basic service set (BSS). Distribution System (DS): A system used to interconnect a set of basic service sets (BSSs) and integrated local area networks (LANs) to create an extended service set (ESS). Extended Service Set (ESS): A set of one or more interconnected basic service sets (BSSs) with the same SSID and integrated local area networks (LANs) that appears as a single BSS to the logical link control layer at any station associated with one of those BSSs. Portal: The logical point at which medium access control (MAC) service data units (MSDUs) from a non-IEEE 802.11 local area network (LAN) enter the distribution system (DS) of an extended service set (ESS). Distribution System Service (DSS): The set of services provided by the distribution system (DS) that enable the medium access control (MAC) to transport MAC service data units (MSDUs) between stations that are not in direct communication with each other over a single instance of the wireless medium (WM). These services include transport of MSDUs between the access points (APs) of basic service sets (BSSs) within an extended service set (ESS), transport of MSDUs between portals and BSSs within an ESS, and transport of MSDUs between stations in the same BSS in cases where the MSDU has a Yang (Editor), et al. Expires December 28, 2004 [Page 4] Internet-Draft CAPWAP Arch. Taxonomy June 2004 multicast or broadcast destination address or where the destination is an individual address, but the station sending the MSDU chooses to involve DSS. DSSs are provided between pairs of IEEE 802.11 MACs. Integration: The service that enables delivery of medium access control (MAC) service data units (MSDUs) between the distribution system (DS) and an existing, non-IEEE 802.11 local area network (via a portal). Distribution: The service that, by using association information, delivers medium access control (MAC) service data units (MSDUs) within the distribution system (DS). 1.3 Terminology Used in this Document One of the motivations in defining new terminology in this document is to clarify some of the ambiguity and confusion surrounding some conventional terms. One of such terms is "Access Point (AP)". Typically ,when people talk about "AP", they refer to the physical entity (box) that has an antenna, implements 802.11 PHY and receives/ transmits the station (STA) traffic over the air. However, 802.11 Standards [1] describes AP mostly as a logical entity that implements a set of logical services so that station traffic can be received and transmitted effectively over the air. So when people talk about "AP functions", they usually mean the logical functions the whole WLAN access networks support, not just the part of the functions supported by the physical entity (box) that the STAs communicate to directly. Such confusion can be especially profound when the logical functions is implemented across a network instead of within a single physical entity. So to avoid further confusion, we define the following terminology used in this document: CAPWAP: Control and Provisioning of Wireless Access Points. IEEE 802.11 WLAN Functions: a set of logical functions defined by IEEE 802.11 Working Group, including all the MAC services, Station Services, and Distribution Services. These logical functions are required to be implemented in the IEEE 802.11 Wireless LAN (WLAN) access networks by IEEE 802.11 Standards [1]. CAPWAP Functions: a set of WLAN control functions that are not directly defined by IEEE 802.11 Standards, but deemed essential for effective control, configuration and management of the 802.11 WLAN access networks. Wireless Termination Point (WTP): the physical or network entity that contains RF antenna and 802.11 PHY to transmit and receive station traffics for the IEEE 802.11 WLAN access networks. Such physical Yang (Editor), et al. Expires December 28, 2004 [Page 5] Internet-Draft CAPWAP Arch. Taxonomy June 2004 entities are often called "Access Points" (AP) previously, but "AP" can also be used to refer to logical entity that implements 802.11 services. So we recommend using "WTP" instead to explicitly refer to the physical entity. Autonomous WLAN Architecture: the WLAN access network architecture family in which all the logical functions including both IEEE 802.11 functions and CAPWAP functions (wherever applicable) are implemented within each Wireless Termination Point (WTP) in the network. The WTPs in such networks are also called the standalone APs, or fat APs, because these devices implement the full functions that enable the devices to function without any other support from the network. Centralized WLAN Architecture: the WLAN access network architecture family in which the logical functions including both IEEE 802.11 functions and CAPWAP functions (wherever applicable) are implemented across a hierarchy of network entities. At the low level of such hierarchy are the WTPs while at the higher level are the Access Controllers (ACs) which are responsible to control, configure and manage the entire WLAN access networks. Distributed WLAN Architecture: the WLAN access network architecture family in which some of the control functions (e.g., CAPWAP functions) are implemented across a distributed network consisting of peer entities. A wireless mesh network can be considered as an example of such architecture. Access Controller (AC): The network entity in the Centralized WLAN architectures that provide WTPs access to the centralized hierarchical network infrastructure, either in the data plane, control plane, or management plane, or a combination therein. Standalone WTP: referred to the WTP in Autonomous WLAN Architecture. Controlled WTP: referred to the WTP in Centralized WLAN Architecture. Split MAC Architecture: A sub-group of the Centralized WLAN Architecture, with the characteristic that WTPs in such WLAN access networks only implement the delay sensitive MAC services (like the control frame processing) for IEEE 802.11, while tunneling all the management and data frames to AC for centralized processing. The IEEE 802.11 MAC as defined by IEEE 802.11 Standards in [1] is effectively split between the WTP and AC. Remote MAC Architecture: A sub-group of the Centralized WLAN Architecture, where the entire set of 802.11 MAC functions (including delay-sensitive functions) are implemented at the AC. The WTP terminates the 802.11 PHY functions. Yang (Editor), et al. Expires December 28, 2004 [Page 6] Internet-Draft CAPWAP Arch. Taxonomy June 2004 Local MAC Architecture: A sub-group of the Centralized WLAN Architecture, where the majority or entire set of 802.11 MAC functions (including most of the 802.11 management frame processing) are implemented at the WTP. Therefore, the 802.11 MAC stays intact and local in the WTP, along with PHY. 1.4 Terminology Used Historically but Not Recommended While some terminology has been used by vendors historically to describe "Access Points", we recommend to stop using in order to avoid further confusion. A list of such terms and the recommended new terminology are provided below: Split WLAN Architecture: use Centralized WLAN Architecture. Hierarchical WLAN Architecture: use Centralized WLAN Architecture. Standalone Access Point: use WTP or Standalone WTP. Fat Access Point: the same as Standalone Access Point. Use WTP or Standalone WTP. Thin Access Point: use WTP, or Controlled WTP. Light Weight Access Point: the same as Thin Access Point, use WTP, or Controlled WTP. Split AP Architecture: use Local MAC Architecture. Antenna AP Architecture: use Remote MAC Architecture. Yang (Editor), et al. Expires December 28, 2004 [Page 7] Internet-Draft CAPWAP Arch. Taxonomy June 2004 2. Introduction As IEEE 802.11 Wireless LAN (WLAN) technology matures, large scale deployment of WLAN networks is highlighting certain technical challenges. As outlined in [2], management, monitoring and control of large number of Access Points (APs) in the network may prove to be a significant network administration burden. Distributing and maintaining a consistent configuration throughout the entire set of APs in the WLAN is a difficult task. The shared and dynamic nature of the wireless medium also demands effective coordination among the APs to minimize radio interference and maximize network performance. Network security issues which have always been a concern in WLAN's, have even more challenges in large deployments and new architectures. Recently many vendors have begun offering partially proprietary solutions to address some or all of the above mentioned problems. Since interoperable solutions allow a broader choice, a standardized interoperable solution addressing the above mentioned problems is desirable. As the first step toward establishing interoperability in the market place, this document attempts to provide a taxonomy of the architectures employed in existing WLAN products. We hope to provide a cohesive understanding of the market practices for the standard bodies involved (including the IETF and IEEE 802.11). This document may be reviewed and utilized by the IEEE 802.11 Working Group as input to their task of defining the functional architecture of an access point. 2.1 IEEE 802.11 WLAN Functions The IEEE 802.11 specifications are wireless standards that specify an "over-the-air" interface between a wireless client (STA) and an Access Point (AP), as well as among wireless clients. 802.11 also describes how mobile devices can associate together into a basic service set (BSS). A BSS is identified by a basic service set identifier (BSSID) or name. The WLAN architecture can be considered as a sort of the 'cell' architecture where each cell is the Basic Service Set (BSS) and each BSS is controlled by the Access Point (AP). When more than one AP is connected via a broadcast layer 2 network and all are using the same SSID, an extended service set (ESS) is created. The architectural component used to interconnect BSSs is the distribution system (DS). An access point (AP) is a STA that provides access to the DS by providing DS services in addition to acting as a STA. Another logical architectural component -- portal -- is introduced to integrate the IEEE 802.11 architecture with a traditional wired LAN. It is possible for one device to offer both the functions of an AP and a portal. Yang (Editor), et al. Expires December 28, 2004 [Page 8] Internet-Draft CAPWAP Arch. Taxonomy June 2004 IEEE 802.11 explicitly does not specify the details of DS implementations. Instead, the 802.11 standard defines services that provide the functions that the LLC layer requires for sending MAC Service Data Units (MSDUs) between two entities on the network. These services can be classified into two categories: the station service (SS) and the distribution system service (DSS). Both categories of service are used by the IEEE 802.11 MAC sublayer. Station services consist of the following four services: o Authentication: The service used to establish the identity of one station as a member of the set of stations authorized to associate with another station. o Deauthentication: The service that voids an existing authentication relationship. o Confidentiality: The service used to prevent the content of messages from being read by other than the intended recipients. o MSDU Delivery: The service to deliver the MAC service data unit (MSDU) for the Stations. Distribution system services consist of the following five services: o Association: The service used to establish access point/station (AP/STA) mapping and enable STA invocation of the distribution system services. o Disassociation: The service that removes an existing association. o Reassociation: The service that enables an established association [between access point (AP) and station (STA)] to be transferred from one AP to another (or the same) AP. o Distribution: The service that provides MSDU forwarding by APs for the STAs associated with them. MSDUs can be either forwarded to the Wireless destination or to the Wired (Ethernet) destination (or both) using the "Distribution System" concept of 802.11. o Integration: The service to translate the MSDU received from the Distribution System to the non-802.11 format and vice versa. Any MSDU that is received from the DS invokes the "Integration" services of the DSS before the 'Distribution' services are invoked. The point of connection of the DS to the wired LAN is termed as 'portal'. Apart from these services the IEEE 802.11 also defines additional MAC services that must be implemented by the APs in the WLAN. For example: o Beacon Generation o Probe Response/Transmission o Processing of Control Frames: RTS/CTS/ACK/PS-Poll/CF-End/CF-ACK o Synchronization o Retransmissions o Transmission Rate Adaptation o Privacy: 802.11 Encryption/Decryption Yang (Editor), et al. Expires December 28, 2004 [Page 9] Internet-Draft CAPWAP Arch. Taxonomy June 2004 In addition to the services offered by the 802.11, the IEEE 802.11 WG is also developing technologies to support the Quality of Service (802.11e), Security Algorithms (802.11i), Inter-AP Protocol (IAPP, or 802.11F -- recommended practice) to update APs when a STA roams from one BSS to the other, Radio Resource Management (802.11k) etc. IEEE 802.11 does not exactly specify how all these functions get implemented, nor does it specify that these functions be implemented all in one physical device (e.g., the WTP). Conceptually, all it requires is that the WTPs and the rest of the DS together implements all these services. Typically, vendors implement not only the services defined in the IEEE 802.11 standard, they also implement a variety of value-added services or functions, like load balancing support, QoS, station mobility support, rogue AP detection, etc. What will become clear from the rest of this document is that vendors do take advantage of the flexibility in the 802.11 architecture, and have come up with many different flavors of architectures and implementations of the WLAN services. Because many vendors choose to implement these WLAN services across multiple network elements, we want to make a clear distinction between the logical WLAN access network functions, and the physical devices that are typically referred to as AP (or thin AP, or mesh AP, depends on the architecture family as described below). Each of these physical devices may implement only part of the logical functions. But the DS including all the physical devices as a whole implements all, or most of the functions. 2.2 CAPWAP Functions In order to address the four problems identified in the [2] (management, consistent configuration, RF control, security) additional functions, esp. in the control plane and management plane, are typically offered by vendors to assist better coordination and control across the entire ESS network. Such functions are especially important when the IEEE 802.11 WLAN functions are implemented across a large scale of network of multiple entities, instead of within one single entity. Such functions are: o RF monitoring, like Radar detection, noise and interference detection and measurement. o RF configuration, e.g., for retransmission, channel, transmission power, etc. o WTP configuration, e.g., for SSID, etc. o WTP firmware loading, e.g., automatic loading and upgrading of WTP firmware for network wide consistency. o Network-wide STA state information database, including the information needed to support value-added services, such as mobility, load balancing etc. Yang (Editor), et al. Expires December 28, 2004 [Page 10] Internet-Draft CAPWAP Arch. Taxonomy June 2004 o Mutual authentication between network entities, e.g., for AC and WTP authentication in a Centralized WLAN Architecture. The services listed are concerned with configuration and control of the radio resource ('RF Monitoring' and 'RF Configuration'), management and configuration of the WTP device ('WTP Configuration', 'WTP Firmware upgrade'), and also security regarding the registration of the WTP to an AC ('AC/WTP mutual authentication'). Moreover, the device from which other services such as mobility management across subnets, and load balancing can obtain state information regarding the STA(s) associated with the wireless network, is also reported as a service ('STA state info database'). The above list of CAPWAP functions does not attempt to be an exhaustive enumeration of all additional services offered by vendors. Instead, we included only those functions that were frequently encountered in the survey data, and are also pertinent to the understanding of the central problem of interoperability. Most of these functions are not explicitly specified by IEEE 802.11, but some of the functions are. For example, control and management of the radio-related functions of an AP are described implicitly in the MIB, such as: o Channel Assignment o Transmit Power Control o Radio Resource Measurement (work currently under way in IEEE 802.11k) The 802.11h [6] amendment to the base 802.11 standard specifies the operation of a MAC management protocol to accomplish the requirements of some regulatory bodies (principally in Europe, but expanding to others) in these areas: o RADAR detection o Transmit Power Control o Dynamic Channel Selection 2.3 WLAN Architecture Proliferation This document provides a taxonomy of the WLAN network architectures developed by the vendor community in an attempt to address some or all of the problems outlined in [2]. As IEEE 802.11 standard explicitly does not specify the details of DS implementations, different architectures proliferate in the market. While these different architectures all conform to the IEEE 802.11 standard as a whole, the individual functional components in these architectures are not standardized, and the interfaces between the network architecture components are mostly proprietary, hence there is no guarantee of cross-vendor interoperability even within similar Yang (Editor), et al. Expires December 28, 2004 [Page 11] Internet-Draft CAPWAP Arch. Taxonomy June 2004 architecture family. In order to achieve interoperability in the market place, the IETF CAPWAP working group is taking on the first logical task of documenting both the functional and the network architectures offered by the existing WLAN vendors today. The end result of this task is this taxonomy document. After analyzing about a dozen different vendors' architectures, we believe that the existing 802.11 WLAN access network architectures can be broadly categorized into three distinct architecture families based on the characteristics of the Distribution Systems that are employed to provide the 802.11 functions. o Autonomous WLAN Architecture: The first architecture family is the traditional WLAN architecture, where each WTP is one physical device that implements all the 802.11 services, including both the distribution and integration services, and the portal function. Such an AP architecture is called Autonomous WLAN Architecture, because each WTP is autonomous in its functionality, and it does not require 802.11 specific support from any other network elements. The WTP in such architecture is typically configured and controlled individually and can be monitored and managed via typical network management protocols like SNMP. But no explicit 802.11 support is needed outside of the WTP. So the WTPs in this architecture are the traditional Access Points most people are familiar with. Sometimes such WTPs are referred to as "Fat APs" or "Standalone APs". o Centralized WLAN Architecture: The second WLAN architecture family is a newly emerging hierarchical architecture utilizing one or multiple centralized controller for large number of WTP devices. The centralized controller is commonly referred to as an Access Controller (AC), whose main function in the network is to control, manage and monitor the WTP devices that are present in the network. In addition to being a centralized entity for control and management plane, because the AC is typically situated in a centralized location in the wireless access network, it may also become a natural data plane aggregation point and co-located with a L2 bridge or switch or a L3 router, and hence may be referred to as Access Bridge, or Access Router in those particular cases. Therefore, an Access Controller could be either a L3 or L2 device, and Access Controller is the generic terminology we use through this document. This architecture family has several distinct characteristics that are worth noting. First of all, the hierarchical architecture and the centralized AC afford much better manageability for the large scale networks. Secondly, since the IEEE 802.11 functions and the CAPWAP control functions are provided by the WTP devices and the AC together, the WTP devices themselves may not implement the full 802.11 functions as Yang (Editor), et al. Expires December 28, 2004 [Page 12] Internet-Draft CAPWAP Arch. Taxonomy June 2004 defined in the standards any more. Therefore, it can be said that the full 802.11 functions are implemented across two physical network devices, namely, the WTPs and ACs. Since the WTP devices only implement a portion of the functions that standalone APs implement, WTP devices in this architecture are sometimes referred to as light weight or thin APs. o Distributed WLAN Architecture: The third emerging WLAN architecture family is distributed architectures in which the participating wireless nodes are capable of forming a distributed network among themselves, via either wired or wireless media. A wireless mesh network is one example in the distributed architecture family, where the nodes themselves form a mesh network connecting with neighboring nodes via 802.11 wireless links, and some of the nodes also have wired Ethernet connections to the gateway to get to the external network. 2.4 Taxonomy Methodology and Document Organization Before the IETF CAPWAP working group started documenting the various WLAN architectures, we conducted an open survey soliciting WLAN architecture description contributions via the IETF CAPWAP mailing list. We received 16 contributions in the form of short text descriptions, 13 of them are from WLAN vendors (AireSpace, Aruba, Avaya, Chantry Networks, Cisco, Cranite Systems, Extreme Networks, Intoto, Panasonic, Trapeze, Instant802, Strix Systems, Symbol, Janusys Networks, Nortel) and one from an academic researcher (UCLA). Out of the 16 contributions, one described an Autonomous WLAN Architecture, three Distributed Mesh Architectures, while the rest twelve entries represent architectures that fall into the family of Centralized WLAN Architecture. The 16 entries that were submitted for the architecture survey are included in this document in its original form in the Appendix sections. The information provided by the vendors in the Centralized WLAN Architecture category are compactly presented in the form of the "Functionality Distribution Matrix" in this document and the Appendix. The matrix is intended for the use of creating this architectural taxonomy only. It represents the contributor's view of the architecture from an engineering perspective and does not necessarily imply an existing product, shipping or not, nor an intent by the vendor to build such a product. The interesting data we try to get out of these survey data is not which vendor does what, but what are the general categories and trends in WLAN architecture evolution, and what are the common characteristics and what are being done differently, and why. In order to represent the survey data in a compact format, a "Functional Distribution Matrix" is used in this document to tabulate the Yang (Editor), et al. Expires December 28, 2004 [Page 13] Internet-Draft CAPWAP Arch. Taxonomy June 2004 various services and functions in various vendor's offerings. These services and functions are classified into three main categories: o Architecture Considerations: the choice of the interconnection topology between the AC and the AP is an architecture consideration. Also, design choices regarding the physical device on which processing of management, control, and data frames of the 802.11 takes place are also interesting to point out. o 802.11 Functions: as described in Section 2.1. o CAPWAP Functions: as described in Section 2.2. For each one of these categories, the mapping of each individual function to network entities implemented by each vendor is shown in tabular form. The rows in the Functional Distribution Matrix represent the individual functions that are organized into the above mentioned three categories, while each column of the Matrix represents one vendor's architecture offering in the survey data. Such matrix will be used throughout the rest of the document to represent the data set we have collected from the survey. The rest of this document is organized around the three broad WLAN architecture families that were introduced in Section 2.3. Each architecture family is discussed in a separate section. The section on Centralized Architecture contains more in-depth details than the other two families, largely due to the large number of the survey data (11 out of 14) collected falling into the Centralized Architecture category. Summary and conclusions are provided at the end of the document to highlight the basic findings from this taxonomy exercise. Yang (Editor), et al. Expires December 28, 2004 [Page 14] Internet-Draft CAPWAP Arch. Taxonomy June 2004 3. Autonomous Architecture 3.1 Overview Figure 1 shows an example network of the Autonomous WLAN Architecture. This architecture combines all the 802.11 functionality in a single physical device, the WTP. A common embodiment of this architecture is a WTP that translates between 802.11 frames to/from its radio interface and 802.3 frames to/from an Ethernet interface. An 802.3 infrastructure that interconnects the Ethernet interfaces of different WTPs together provides the distribution system. It can also provide portals for integrated 802.3 LAN segments. +---------------+ +---------------+ +---------------+ | 802.11 BSS 1 | | 802.11 BSS 2 | | 802.11 BSS 3 | | ... | | ... | | ... | | +-----+ | | +-----+ | | +-----+ | +----| WTP |----+ +----| WTP |----+ +----| WTP |----+ +--+--+ +--+--+ +--+--+ |Ethernet | | +------------------+ | +------------------+ | | | +---+--+--+---+ | Ethernet | 802.3 LAN --------------+ Switch +-------------- 802.3 LAN segment 1 | | segment 2 +------+------+ Figure 1: Example of Autonomous WLAN Architecture A single physical WTP can optionally be provisioned as multiple virtual WTPs by supporting multiple SSIDs to which 802.11 clients may associate. In some cases, this will also involve putting a corresponding 802.1Q tag on each packet forwarded to the Ethernet infrastructure and removal of 802.1Q tags prior to forwarding the packets to the wireless medium. The scope of the ESS(s) created by interconnecting the WTPs will be confined by the constraints imposed by the Ethernet infrastructure. Authentication of 802.11 clients may be performed locally by the WTP or by using a centralized authentication server. 3.2 Security Since both the 802.11 and CAPWAP functionality is tightly integrated into a single physical device, the security issues with this Yang (Editor), et al. Expires December 28, 2004 [Page 15] Internet-Draft CAPWAP Arch. Taxonomy June 2004 architecture are confined to the WTP. There are no extra implications from the client authentication and encryption/decryption perspective as the AAA interface is integrated into the WTP, as is the key generation mechanisms required for 802.11i encryption/ decryption. As per problem #4 in [2], the only security issue in this architecture is mutual authentication between the WTP and the Ethernet infrastructure to ensure that WTPs cannot be easily stolen and deployed in unprotected networks. This can be ensured by existing mechanisms such as, for instance, 802.1x between the WTP and the Ethernet switch it plugs into. Yang (Editor), et al. Expires December 28, 2004 [Page 16] Internet-Draft CAPWAP Arch. Taxonomy June 2004 4. Centralized WLAN Architecture Centralized WLAN Architecture is a newly emerging architecture family in the WLAN market. Contrary to the Autonomous WLAN Architecture where the 802.11 functions and network control functions are all implemented within each Wireless Termination Point, the Centralized WLAN Architecture employs one or multiple centralized controller called Access Controller(s) in the network to provide the network wide visibility and improve management scalability and dynamic configurability. A Network Management Station can be considered part of the Access Controller, but typically Access Controller contains more than a Network Management Station. The following diagram shows schematically the Centralized WLAN Architecture network diagram where the Access Controller (AC) connects to multiple Wireless Termination Points (WTPs) via a certain interconnection topology, which can be either a direct connection, a L2-switched, or L3-routed network as described in Section 4.1. The AC exchanges configuration, and control information with the AP devices, allowing the management of the network from a centralized point. Also, designs of the Centralized WLAN Architecture family do not presume (as the diagram might suggest to some readers) that the AC necessarily intercedes in the data plane to/from the WTP(s). More details are provided later in this section. +---------------+ +---------------+ +---------------+ | 802.11 BSS 1 | | 802.11 BSS 2 | | 802.11 BSS 3 | | ... | | ... | | ... | | +-------+ | | +-------+ | | +-------+ | +----| WTP |--+ +----| WTP |--+ +----| WTP |--+ +---+---+ +---+---+ +---+---+ | | | +------------------+ | +-----------------+ | |...| +----+--+---+--------+ | Interconnection | | Topology | +-------+------------+ | | +-----+----+ | AC | +----------+ Figure 2: Centralized WLAN Architecture Diagram In the diagram above, the AC is shown as a single physical entity that provides all of the CAPWAP functions listed in section 2.2. Yang (Editor), et al. Expires December 28, 2004 [Page 17] Internet-Draft CAPWAP Arch. Taxonomy June 2004 Closer scrutiny of the functions reveals that their differing resource requirements (e.g. CPU, memory, storage) may lend themselves to being distributed across different devices. For instance, complex radio control algorithms can be CPU intensive. Storing and downloading images and configurations can be storage intensive. Data plane services like mobility and load balancing may be better supported in network devices that may be lacking in one or more of these resources. The box marked 'AC' in the diagram above should accordingly be thought of as a multiplicity of logical functions and not necessarily as a single physical device. 4.1 Interconnection Topology between WTPs and ACs There are several possible topologies which can be considered between the AC(s) and the WTPs, including direct connection, L2 switched connection, or L3 routed connection, as shown in Figure 3, Figure 4, and Figure 5. -------+------ LAN | +-------+-------+ | AC | +----+-----+----+ | | +---+ +---+ | | +--+--+ +--+--+ | WTP | | WTP | +--+--+ +--+--+ Figure 3: Directly Connected Yang (Editor), et al. Expires December 28, 2004 [Page 18] Internet-Draft CAPWAP Arch. Taxonomy June 2004 -------+------ LAN | +-------+-------+ | AC | +----+-----+----+ | | +---+ +---+ | | +--+--+ +-----+-----+ | WTP | | Switch | +--+--+ +---+-----+-+ | | +-----+ +-----+ | WTP | | WTP | +-----+ +-----+ Figure 4: Switched Connections +-------+-------+ | AC | +-------+-------+ | --------+------ LAN | +-------+-------+ | router | +-------+-------+ | -----+--+--+--- LAN | | +---+ +---+ | | +--+--+ +--+--+ | WTP | | WTP| +--+--+ +--+--+ Figure 5: Routed Connections 4.2 Overview of Three Centralized WLAN Architectures While dynamic and consistent network manageability is one of the primary motivations for the Centralized Architecture, the survey data from vendors also show that different varieties of this architecture family have emerged as a result of the inherent flexibility in the 802.11 standard [1] regarding the implementation of the logical functions that are broadly described under the term "Access Point". Yang (Editor), et al. Expires December 28, 2004 [Page 19] Internet-Draft CAPWAP Arch. Taxonomy June 2004 As there is no standard mapping of these functions to physical network entities, several design choices have been made by vendors that offer related products. Moreover, the increased demand for monitoring and consistent configuration of large wireless, enterprise networks has resulted into a set of 'value-added' services provided by the various vendors, most of which share common design properties and service goals. In the following, we describe the three main approaches vendors have taken, namely, the Local MAC, Split MAC, and Remote MAC approaches within this family of architectures, and provide the mapping characteristics of the various functions into the network entities, for each approach. The naming of Local MAC, Split MAC and Remote MAC reflects how the functions, esp. the 802.11 MAC functions, are mapped onto the network entities. Local MAC indicates that the MAC functions stay intact and local to WTPs, while Split MAC shows the MAC being split between the WTPs and ACs, and remote MAC signifies the MAC is moved away from WTP to the remote AC in the network. 802.11 does not clearly specify what constitute real-time functions versus non-real-time functions, and so there does not exist such a clear definitive line among the MAC functions. As shown in Section 4.4, each vendor has its own interpretation on this and so there exists some discrepancy in where to draw the line. However, vendors also manage to agree on most of the functions, for example, every vendor agree that DCF function is a real-time MAC function. The differences among Local MAC, Split MAC and Remote MAC architectures can be shown roughly in the following figure: +--------------+--- +---------------+--- +--------------+--- | CAPWAP | | CAPWAP | | CAPWAP | | functions |AC | functions |AC | functions | |==============|=== |---------------| |--------------| | | | non RT MAC | | |AC | 802.11 MAC | |===============|=== | 802.11 MAC | | |WTP | Real Time MAC | | | |--------------| |---------------|WTP |==============|=== | 802.11 PHY | | 802.11 PHY | | 802.11 PHY |WTP +--------------+--- +---------------+--- +--------------+--- (a) "Local MAC" (b) "Split MAC" (c) "Remote MAC" Figure 6: The Three Different Architectures within Centralized WLAN Architecture Family Yang (Editor), et al. Expires December 28, 2004 [Page 20] Internet-Draft CAPWAP Arch. Taxonomy June 2004 4.3 Local MAC The main motivation of Local MAC architecture model, as shown in Figure 6.(a), is to offload network access policies and management functions (CAPWAP functions described in Section 2.2) to the AC, without splitting the 802.11 MAC functionality between WTP(s) and AC(s). The whole 802.11 MAC resides on the WTP locally, including all the 802.11 management and control frame processing for the STAs; however information related to management and configuration of the WTP devices is communicated with a centralized AC, to facilitate management of the network, and maintain a consistent network-wide configuration for the WTP devices. Figure 7 offers a tabular representation of the design choices made by the six vendors in the survey that follow the Local MAC approach with respect to the architecture considerations. "WTP-AC topology" shows the kind of topology between WTPs and AC each vendor's architecture can support. It is clear that all the vendors can support L3 routed network topology between WTPs and AC, which implies that direct connections and L2 switched networks are also supported by all vendors. By '802.11 mgmt termination', and '802.11 control termination' we denote the physical network device on which processing of the 802.11 management, and control frames is done respectively. All the vendors here choose to terminate 802.11 management and control frames at WTPs. The last row of the table '802.11 data aggregation', refers to the device on which aggregation and delivery of 802.11 data frames from one STA to another (possibly through a DS) is performed. As we can see from the table, vendors make different choices as whether or not all the 802.11 data traffic are aggregated and routed through the AC. The survey data shows that some vendors choose to tunnel or encapsulate all the station traffic to or from the ACs, implying the AC also acts as the access router for this WLAN access network; while other vendors choose to separate the control plane and data plane by letting the station traffic being bridged or routed locally while keeping the control at the AC. Yang (Editor), et al. Expires December 28, 2004 [Page 21] Internet-Draft CAPWAP Arch. Taxonomy June 2004 Arch7 Arch8 Arch9 Arch10 Arch11 ----- ----- ----- ------ ------ WTP-AC topology L3 L3 L3 L3 L3 802.11 mgmt termination WTP WTP WTP WTP WTP 802.11 control termination WTP WTP WTP WTP WTP 802.11 data aggregation AC AC WTP AC WTP Figure 7: Architecture Considerations for Local MAC Architecture Below Figure 8 shows that most of the CAPWAP functions as described in Section 2.2 are implemented at the AC, with help from WTPs to monitor RF channels, and collect statistics and state information from the STAs. Most vendors choose to do the similar mapping here as the AC offers the advantages of network-wide visibility, which is essential for many of the control, configuration and value-added services. Yang (Editor), et al. Expires December 28, 2004 [Page 22] Internet-Draft CAPWAP Arch. Taxonomy June 2004 Arch7 Arch8 Arch9 Arch10 Arch11 ----- ----- ----- ------ ------ RF Monitoring WTP WTP AC/WTP WTP WTP RF Config. AC AC AC AC AC WTP config. AC AC AC AC AC WTP Firmware AC AC AC AC AC STA state info database AC AC/WTP AC/WTP AC/WTP AC AC/WTP mutual authent. AC/WTP AC/WTP AC/WTP AC/WTP AC/WTP Figure 8: Mapping of CAPWAP Functions for Local MAC Architecture The matrix shown in Figure 9 shows that most of the 802.11 functions are implemented at the WTPs for Local MAC Architecture, with some minor differences among the vendors with regard to distribution service, 802.11e scheduling and 802.1x/EAP authentication. The difference in distribution service is consistent with the difference described earlier with regard to "802.11 data aggregation" in the Figure 7. Arch7 Arch8 Arch9 Arch10 Arch11 ----- ----- ----- ------ ------ Distribution Service AC AC WTP AC WTP Integration Service WTP WTP WTP WTP WTP Beacon Generation WTP WTP WTP WTP WTP Probe Response WTP WTP WTP WTP WTP Yang (Editor), et al. Expires December 28, 2004 [Page 23] Internet-Draft CAPWAP Arch. Taxonomy June 2004 Power mgmt Packet Buffering WTP WTP WTP WTP WTP Fragmentation/ Defragment. WTP WTP WTP WTP WTP Association Disassoc. Reassociation AC WTP WTP WTP WTP WME/11e -------------- classifying AC WTP scheduling WTP AC/WTP WTP WTP WTP queuing WTP WTP WTP WTP Authentication and Privacy -------------- 802.1x/EAP AC AC AC/WTP AC AC/WTP Keys Management AC AC WTP AC AC 802.11 Encryption/ Decryption WTP WTP WTP WTP WTP Figure 9: Mapping of 802.11 Functions for Local MAC Architecture From Figure 7, Figure 8 and Figure 9, it is clear that differences between vendors in the Local MAC Architecture is relatively minor while the most of the functional mapping appears to be common across the vendors. 4.4 Split MAC As shown in Figure 6.(b), the main idea behind the Split MAC architecture is to implement part of the 802.11 MAC functionality on a centralized AC instead of the WTPs, in addition to the services required for managing and monitoring the WTP devices. Usually, the decision of which functions of the 802.11 MAC need to be provided by the AC is based on the time-criticality of the services required. In Split MAC architecture, the WTP terminates the infrastructure side Yang (Editor), et al. Expires December 28, 2004 [Page 24] Internet-Draft CAPWAP Arch. Taxonomy June 2004 of the wireless physical link, provides radio-related management, and also implements all time-critical functionality of the 802.11 MAC. In addition, the non real-time management functions are handled by a centralized AC, along with higher-level services, such as configuration, QoS, policies for load-balancing, access control lists, etc. The subtle but key distinction between Local MAC and Split MAC relates to the non real-time functions: in Split MAC architecture, the AC terminates 802.11 non real-time functions, whereas in Local MAC architecture the WTP terminates the 802.11 non real-time functions and consequently sends appropriate messages to the AC. There are several motivations for taking the Split MAC approach. One of the motivations is to offload to the WTP(s) functionality that is specific and relevant only to the locality of each BSS in order to allow the AC to scale to a large number of 'light weight' WTP devices. Moreover, real-time functionality is subject to latency constraints and cannot tolerate delays due to transmission of 802.11 Control frames (or other real-time information) over multiple-hops. The latter would limit the available choices for the interconnection topology between the AC and the WTP(s), so the real-time criterion is usually employed to separate MAC services between the devices. Another consideration is cost reduction in the WTP to make it as cheap and simple as possible. Last but not least, moving functions like encryption and decryption to the AC instead of WTPs reduce vulnerabilities from a compromised WTP since user encryption keys no longer reside on the WTP. A side effect of this architecture is that progress in security protocols and algorithm does not obsolete the WTPs; the ACs implement the new security schemes instead and the management problem is therefore simplified. It can also protect from LAN-side eavesdropping. Since there is no clear definition in 802.11 spec as to which 802.11 MAC functions are considered "real time", each vendor has taken the liberty to interprete that in his own way. Most vendors agree that the following services of 802.11 MAC are examples of real time services and so are chosen to be implemented on the WTPs for most of the split MAC Architectures. o Beacon Generation o Probe Response/Transmission o Processing of Control Frames: RTS/CTS/ACK/PS-Poll/CF-End/CF-ACK o Synchronization o Retransmissions o Transmission Rate Adaptation The following list are examples of non-real-time MAC functions as interpreted by most vendors: Yang (Editor), et al. Expires December 28, 2004 [Page 25] Internet-Draft CAPWAP Arch. Taxonomy June 2004 o Station Services: Authentication/Deauthentication o Distribution System Services: Association/Disassociation/ Reassociation/Distribution o Integration Services: bridging between 802.11 and 802.3 o Privacy: 802.11 Encryption/Decryption o Fragmentation/Defragmentation However, some vendors may choose to classify some of the above "non-real time" functions as real-time functions, in order to support specific applications with strict QoS requirements. For example Reassociation is sometimes implemented as "real-time" in order to support VoIP application. The non-real-time aspects of the 802.11 MAC are handled by the AC, either directly through the processing of raw 802.11 management frames (Split MAC), or after conversion to some other message format (Local MAC). The following matrix in Figure 10 offers a tabular representation of the design choices made by the six vendors that follow the Split MAC design with respect to the architecture considerations. While most vendors support L3 topology between WTPs and ACs, some vendors can only support L2 switched connections, due to the tighter delay constraint resulting from splitting MAC between two physical entities across a network. Comparing to Figure 7, it is clear that the commonality between Split MAC and Local MAC is that the 802.11 control frames are all processed by WTP, while the difference lies in the termination point for 802.11 management frames. Local MAC terminates 802.11 management frames at WTP, while at least some of the 802.11 management frames are being terminated at the AC for Split MAC Architecture. In most cases, since WTP devices are IP-addressable, any of the direct connection, L2-switched, or L3-routed topologies of Section 2.2 can be used. In the case where only Ethernet-encapsulation is performed (ex. as in Architecture 4) then only direct connection and L2-switched topologies are supported. Yang (Editor), et al. Expires December 28, 2004 [Page 26] Internet-Draft CAPWAP Arch. Taxonomy June 2004 Arch1 Arch2 Arch3 Arch4 Arch5 Arch6 ----- ----- ----- ----- ----- ----- WTP-AC topology L3 L3 L3 L2 L3 L3 802.11 mgmt termination AC AC AC AC AC/WTP AC 802.11 control termination WTP WTP WTP WTP WTP WTP 802.11 data aggregation AC AC AC AC AC AC Figure 10: Architecture Considerations for Split MAC Architecture Similar to the Local MAC Architecture, the following matrix in Figure 11 shows that the CAPWAP control functions are implemented at the AC. Arch1 Arch2 Arch3 Arch4 Arch5 Arch6 ----- ----- ----- ----- ----- ----- RF Monitoring WTP WTP WTP WTP WTP WTP RF Config. AC/WTP AC/WTP AC AC AC WTP config. AC AC AC AC AC WTP Firmware AC AC AC AC AC STA state info database AC AC AC AC AC AC/WTP mutual authent. AC/WTP AC/WTP AC/WTP AC/WTP Figure 11: Mapping of CAPWAP Functions for Split MAC Architecture The most interesting matrix for Split MAC Architecture is the Yang (Editor), et al. Expires December 28, 2004 [Page 27] Internet-Draft CAPWAP Arch. Taxonomy June 2004 Functional Distribution Matrix for 802.11 functions, as shown below in Figure 12. It is clear that even within the Split MAC Architecture, vendors choose to map many of the functions differently. All vendors choose to implement Distribution, Integration Service at the AC, along with 802.1x/EAP authentication and keys management. All vendors also choose to implement beacon generation at WTPs. But there are widespread difference among the vendors for most other functions. Therefore, Split MAC Architectures are not consistent in the way the MAC is split. Arch1 Arch2 Arch3 Arch4 Arch5 Arch6 ----- ----- ----- ------ ----- ----- Distribution Service AC AC AC AC AC AC Integration Service AC AC AC AC AC AC Beacon Generation WTP WTP WTP WTP WTP WTP Probe Response WTP AC/WTP WTP WTP WTP WTP Power mgmt Packet Buffering WTP WTP WTP AC AC/WTP WTP Fragmentation Defragment. WTP WTP AC AC AC Association Disassoc. Reassociation AC AC AC AC WTP AC WME/11e -------------- classifying AC AC AC AC scheduling WTP/AC AC WTP AC AC WTP/AC queuing WTP/AC WTP WTP AC WTP WTP Authentication and Privacy -------------- Yang (Editor), et al. Expires December 28, 2004 [Page 28] Internet-Draft CAPWAP Arch. Taxonomy June 2004 802.1x/EAP AC AC AC AC AC AC Keys Management AC AC AC AC AC AC 802.11 Encryption/ Decryption WTP AC WTP AC AC AC Figure 12: Mapping of 802.11 Functions for Split MAC Architecture 4.5 Remote MAC One of the main motivations for Remote MAC Architecture is to keep the WTPs as light weight as possible by having only the radio interface on the WTPs and offloading the entire set of 802.11 MAC functions (including delay-sensitive functions) to the Access Controller. This leaves all the complexities of the MAC and other CAPWAP control functions to the centralized controller and improves WTP manageability. The WTP acts only as a pass-through between the Wireless LAN clients (STA) and the AC, though they may have an additional feature to convert the frames from one format (802.11) to the other (Ethernet, TR, Fiber etc.). The centralized controller provides for network monitoring, management and control, entire set of the 802.11 AP services, the WLAN PHY concepts, security features, resource management, channel adoption features, guarantying Quality of Service to the users etc. Because the MAC is separated from the PHY, we call this the "Remote MAC Architecture". Typically such architecture is deployed with special attention to the topology between WTP and AC so that the delay is minimized. The RoF (Radio over Fiber) from Architecture 5 Appendix F is such an example of Remote MAC Architecture. 4.6 Comparisons of Local MAC, Split MAC and Remote MAC Two commonalities across all the three Centralized Architectures (Local MAC, Split MAC and Remote MAC) are: o All the CAPWAP functions related to network control and configuration reside on the AC. o IEEE 802.11 PHY resides on the WTP. The difference between Remote MAC and the other two Centralized Architectures (i.e., Local MAC and Split MAC) is pretty clear, as the 802.11 MAC is completely separated from the PHY in the former, while the other two at least keep some portion of the MAC functions with Yang (Editor), et al. Expires December 28, 2004 [Page 29] Internet-Draft CAPWAP Arch. Taxonomy June 2004 PHY at the WTPs. So the implication of PHY and MAC separation is that it severely limits the interconnection topology between WTPs and ACs so that the 802.11 timing constraints are satisfied. As pointed out earlier, this usually results in tighter control over the interconnection between WTP and AC for the Remote MAC Architecture. The advantage of Remote MAC Architecture is that it offers the lightest possible WTPs for certain deployment scenarios. The commonalities and differences between Local MAC and Split MAC are most clearly seen by comparing Figure 7 and Figure 10. The commonality between the two is that 802.11 control frames are terminated at WTPs in both cases. The main difference between Local MAC and Split MAC is that in the latter WTP terminates only the 802.11 Control frames, while in the former WTP may terminate all 802.11 frames. An interesting consequence of this difference is that Integration Service, which essentially refers to bridging between 802.11 and 802.3 frames, is implemented by the AC in the Split MAC, but can be part of either the AC or WTP in the Local MAC. As a second note, the Distribution Service, although usually provided by the AC, can also be implemented at the WTP in some Local MAC architecture. The rationale behind this approach is to increase performance in delivering STAs data traffic by avoiding tunnelling it to the AC, and also relax the dependency of the WTP from the AC. Therefore, it is possible that data plane and control plane are separated in the Local MAC Architecture. Even though all the 802.11 traffic are aggregated at ACs in the case of Split MAC Architecture, the data plane and control plane can still be separated by employing multiple ACs. For example, one AC can implement most of the CAPWAP functions (control plane), while other ACs can be employed for 802.11 frames bridging (data plane). 4.7 Communication Interface between WTPs and ACs Before any messages can be exchanged between the AC and WTP(s) typically the following operations are first performed that lead to the registration of an WTP with an AC: 1. Discovery : WTP(s) discover the AC with which they will be bound to and controlled by. The discovery procedure can employ either static configuration, or dynamic. In the latter case, a protocol is used in order for the WTP to discover candidate AC(s). 2. Authentication: after discovery, the WTP device authenticates itself with the AC. However, mutual authentication, in which the WTP authenticates the AC, is not always supported since some vendors strive for zero-configuration on the WTP side. This is not necessarily secure as it leaves the possible vulnerability of the WTP being attached to a rogue AC. Yang (Editor), et al. Expires December 28, 2004 [Page 30] Internet-Draft CAPWAP Arch. Taxonomy June 2004 3. WTP Association: after successful authentication, an WTP registers with the AC, in order to start receiving management and configuration messages. 4. Firmware Download: after successful association, the WTP may pull, or the AC may push the WTPs firmware, which may be protected by some manner, such as digital signatures. 5. Control Channel Establishment: the WTP establishes either an IP-tunnel (ex. Architecture 2 (Appendix C), Architecture 1 (Appendix B)) or performs Ethernet encapsulation (ex. Architecture 4 (Appendix E)) with the AC, in order to transfer data traffic and management frames. 6. Configuration Download: following the control channel establishment process, the AC may push configuration parameters to the WTP. 4.8 Security Given the varied distribution of functionalities for the Centralized Architecture as surveyed in Section 4.3, it is obvious that an extra network binding is created between the WTP and the AC. This brings along new and unique security issues and subsequent requirements. 4.8.1 Client Data Security The survey shows clearly that the termination point for "over the air" 802.11 encryption (802.11i) can be implemented either in the WTP or in the AC. Furthermore, the 802.1x/EAP functionality is also distributed between the WTP and the AC where, in almost all cases, the AC performs the necessary functions as the authenticator in the 802.1x exchange. If the encryption is done at the WTPs, the resultant cryptographic keys for the session are required to be securely pushed from the AC to the WTP. Since this keying material is part of the control and provisioning of the WTPs, a secure encrypted tunnel for control frames is employed to transport the keying material. In the case where the 802.11i encryption/decryption is performed in the AC, the authentication and key management is also fully performed in the AC. Regardless of 802.11i termination point, the Centralized WLAN Architecture assumes two possibilities for "over the wire" client data security. In some cases there is an encrypted tunnel (IPsec or SSL ) between the WTP and AC which assumes the security boundary to be in the AC. In other cases an end-to-end mutually authenticated secure VPN tunnel is assumed between the client and AC, other security gateway or end host entity. Yang (Editor), et al. Expires December 28, 2004 [Page 31] Internet-Draft CAPWAP Arch. Taxonomy June 2004 4.8.2 Security of control channel between WTP and AC In order for the CAPWAP functions to be implemented in the Centralized WLAN Architecture it is necessary for a control channel to exist between WTP and AC. In order to address potential security threats against the control channel, existing implementations feature one or more of the following security mechanisms: 1. Secure discovery of WTP and AC 2. Authentication of the WTPs to the ACs (and possibly mutual authentication 3. Confidentiality and integrity of control channel frames 4. Secure management of WTPs and ACs, including mechanisms for securely setting and resetting secrets. Discovery and authentication of WTPs are addressed in the submissions by implementing authentication mechanisms that range from X.509 certificates, AAA authentication and pre-shared credential authentication. In all cases, the issues of confidentiality, integrity and of protection against man-in-the-middle attacks of the control frames are addressed by a secure encrypted tunnel between WTP and AC(s) utilizing keys derived from the varied authentication methods mentioned previously. Finally, one of the motivations for the Centralized WLAN Architecture is to minimize the storage of cryptographic and security sensitive information in addition to operational configuration parameters within the WTPs. It is for that reason that majority of the submissions under the Centralized Architecture category have employed a post WTP authenticated discovery phase of configuration provisioning which, in turn protects against the theft of WTPs. Yang (Editor), et al. Expires December 28, 2004 [Page 32] Internet-Draft CAPWAP Arch. Taxonomy June 2004 5. Distributed Mesh Architecture Out of the 16 architecture survey submissions, 3 belong to the Distributed Mesh Architecture family. An example of the Distributed Mesh Architecture is shown in Figure 13, which reflects some of the common characteristics found in these 3 submissions. One of the key characteristics in these mesh architectures is that the mesh nodes in the network may act as APs to the client stations in their respective BSS, while as traffic relay to neighboring mesh nodes via 802.11 wireless links to provide wider wireless coverage. It is also possible that some of the mesh nodes in the network only serve as wireless traffic relay for other mesh nodes, while not acting as APs for any client stations. Instead of pulling Ethernet cable connection to each AP, the wireless mesh network provides an attractive alternative to backhaul traffic. Another key characteristics of these mesh architectures is that the mesh nodes can keep track of the state of its neighboring nodes or even nodes beyond its immediate neighborhood, by information exchange between the neighboring mesh nodes; therefore, the mesh nodes can be fully aware of the dynamic network topology and RF conditions. Such peer-to-peer communication models allows the mesh nodes to actively coordinate among themselves to achieve self-configuration and self-healing. This is the major distinction between this Distributed Architecture family and the Centralized Architecture -- much of the CAPWAP functions can be implemented across the mesh nodes in the distributed fashion, without a centralized entity making all the control decisions. On the other hand, it is worthwhile to point out that mesh networks do not necessarily preclude the use of centralized control. It is possible that a combination of centralized and distributed control co-exist in the mesh networks. Any global configuration or policy change can be better served in a coordinated fashion if an AC exists. For example, a centralized management entity can be used to update every mesh node‚ĮÖs default configuration; it may also be more desirable to leave certain functions (such as user authentication) to a centralized AC (Access Controller) while others distributed across the mesh nodes. The backhaul transport network of the mesh network can be based on either L2 or L3. Currently proprietary solutions are used to achieve the peer-to-peer communication between the mesh nodes, and hence no interoperability exists between the mesh nodes from different vendors. If a centralized AC is used in such mesh networks, a protocol similar to the one used by Centralized Architectures is also needed between the AC and all the mesh nodes that are also WTPs (serving as AP to their BSS clients). Yang (Editor), et al. Expires December 28, 2004 [Page 33] Internet-Draft CAPWAP Arch. Taxonomy June 2004 +-----------------+ +-----------------+ | 802.11 BSS 1 | | 802.11 BSS 2 | | ... | | ... | | +---------+ | | +---------+ | +----|mesh node|--+ +----|mesh node|--+ +-+---+---+ +-+-+-----+ | | | | | | | | +----------+ | +-----------------------+ | Ethernet | Ethernet | | 802.11 wireless links | +--------+ Switch | | +-----------------------+ | | | | | | | | | +----------+ +-+---+---+ +-+--+----+ +----|mesh node|--+ +----|mesh node|--+ | +---------+ | | +---------+ | | ... | | ... | | 802.11 BSS 4 | | 802.11 BSS 3 | +-----------------+ +-----------------+ Figure 13: Example of Distributed Mesh Architecture 5.1 Security Similar security concerns for client data security as described in Section 4.8.1 also apply in the Distributed Mesh Architecture. In addition to that, one important security consideration for the mesh networks is that the mesh nodes must authenticate each other within the same administrative domain and the data transmission among neighboring nodes must be secured to form a secure network. It is recommended that all mesh links be encrypted since they may or may not be carrying encrypted user traffic. The operator of the Mesh network cannot know whether the data should be encrypted or not. So the operator should always encrypt. Yang (Editor), et al. Expires December 28, 2004 [Page 34] Internet-Draft CAPWAP Arch. Taxonomy June 2004 6. Summary and Conclusions We requested existing WLAN vendors and other interested parties to submit a short description of existing or desired WLAN access network architectures to define a taxonomy of possible WLAN access network architectures. The information from the 16 submissions was condensed and summarized in this document. New terminology has been defined wherever existing terminology was found to be either insufficient or ambiguous in describing the WLAN architectures and supporting functions listed in the document. For example, the broad set of Access Point functions has been divided into two categories - 802.11 functions which include those that are required by the IEEE 802.11 standards, and CAPWAP functions which include those that are not required by the IEEE 802.11, but are deemed essential for control, configuration, and management of 802.11 WLAN access networks. Another term that has caused considerable ambiguity is "Access Point" which was usually tied to reflect a physical box that has the antennas, but did not have a uniform set of externally verifiable behavior across all the submissions. To remove this ambiguity, we have re-defined the AP to be the set of 802.11 and CAPWAP functions, while the physical box that terminates the 802.11 PHY is called the Wireless Termination Point. Based on the submissions during the architectural survey phase, we have classified the existing WLAN architectures into three broad classes: 1. Autonomous WLAN architecture indicates a family of architectures where all the 802.11 functions and, where applicable, CAPWAP functions are implemented in the WTP. 2. Centralized WLAN architecture indicates a family of architectures where the AP functions are split between the WTP and the AC with the AC, typically, acting as a centralization control point for multiple WTPs. 3. Distributed WLAN architecture indicates a family of architectures where the AP functions are implemented across a distributed network of peer entities. Within the centralized WLAN architecture, there are a few subgroups that are visible depending on how one splits the MAC functions, at a high-level, between the WTP and the AC. Three prominent ones emerged from the information present in the submissions: 1. Split MAC architecture, where the 802.11 MAC functions are split between the WTP and the AC. This subgroup includes all architectures that split the 802.11 MAC functions even though individual submissions differed on the specifics of the split. 2. Local MAC architecture, where the entire set of 802.11 MAC functions is implemented on the WTP. Yang (Editor), et al. Expires December 28, 2004 [Page 35] Internet-Draft CAPWAP Arch. Taxonomy June 2004 3. Remote MAC architecture, where the entire set of 802.11 MAC functions is implemented on the AC. The following tree diagram summarizes the architectures documented in this taxonomy. +----------------+ |Autonomous | +---------->|Architecture | | |Family | | +----------------+ | +--------------+ | |Local | | +---->|MAC | | | |Architecture | | | +--------------+ | | | +----------------+ | +--------------+ | |Centralized | | |Split | +---------->|Architecture |--+---->|MAC | | |Family | | |Architecture | | +----------------+ | +--------------+ | | | | +--------------+ | | |Remote | | +---->|MAC | | |Architecture | | +--------------+ | +----------------+ | |Distributed Mesh| +---------->|Architecture | |Family | +----------------+ A majority of the submitted WLAN access network architectures followed the centralized WLAN architecture. All but one of the centralized WLAN architecture submissions were grouped into either a Split MAC architecture or a Local MAC architecture. There was one submission that followed the Remote AP architecture. There were three submission under the Distributed WLAN architecture. The WLAN access network architectures in the submissions indicated that the topological assumptions were: o Direct connection between the WTP and the AC. o L2 switched connectivity between the WTP and the AC. o L3 routed connectivity between the WTP and the AC. Yang (Editor), et al. Expires December 28, 2004 [Page 36] Internet-Draft CAPWAP Arch. Taxonomy June 2004 o Wireless links in the distributed WLAN architecture. Interoperability between equipment from different vendors is one of the fundamental problems in the WLAN market today. In order to achieve interoperability via open standard development, the followings are suggested next steps. Using the above taxonomy/terminology, a functional model of an Access Point should be defined, possibly, by a group within the IEEE 802.11. The functional model will consist of defining functional elements of an 802.11 access point that are considered atomic, i.e. not subject to further splitting across multiple network elements. Such a functional model should serve as a common foundation to support the existing WLAN architectures as outlined in this taxonomy, and any further architecture development either within or outside of IEEE 802.11 group. It is possible, or even recommended, that the work on the functional model definition may also include impact analysis of implementing each functional element on either the WTP or the AC. As part of the functional model definition, interfaces must be defined in the form of primitives between these functional elements. If a pair of functional elements that have an interface defined between them is subject to a split, i.e., subject to being implemented on two different network entities, then a protocol specification between such pairs of functional elements is required to be defined. Yang (Editor), et al. Expires December 28, 2004 [Page 37] Internet-Draft CAPWAP Arch. Taxonomy June 2004 7. Security Considerations A comprehensive threat analysis of all of the security issues with the different WLAN architectures is not a goal of this document. Nevertheless, in addition to documenting the architectures employed in the existing IEEE 802.11 products in the market, this taxonomy document also catalogs, in a non-exhaustive manner, the security issues that arise and the manner in which vendors address these security threats. The WLAN architectures are broadly categorized into three families: Autonomous Architecture, Centralized Architecture, and Distributed Architecture. While Section 3, Section 4 and Section 5 are devoted to each of these three architecture families, respectively, each section also contains a subsection to address the security issues within each architecture family. In summary, the main security concern in the Autonomous Architecture is the mutual authentication between WTP and the wired (Ethernet) infrastructure equipment. The WTP physical entity contains all of the 802.11 and CAPWAP functions which isolates it from over the wire security issues between WTP and AC. In the Centralized Architecture there are a few new security concerns because of the introduction of a network binding between WTP and AC. The following security concerns are raised for this architecture family: keying material for mobile client traffic may need to be securely transported from AC to WTP; secure discovery of WTP and AC is required, mutual authentication of WTPs and AC is needed, man- in-the-middle attacks to the control channel between WTP and AC, confidentiality and integrity of control channel frames, and theft of WTPs for extraction of embedded secrets within. Each of the survey results for this broad architecture category have presented a variety of mechanisms to address these security issues. [Editor's note] Summary of the security issues and concerns pertaining to the Distributed architecture needs to be written when the description of that architecture is complete. Yang (Editor), et al. Expires December 28, 2004 [Page 38] Internet-Draft CAPWAP Arch. Taxonomy June 2004 8. Acknowledgements This taxonomy is truly a collaborative effort with contributions from a large group of people. First of all, we want to thank all the CAPWAP Architecture Design Team members who have spent many hours in the teleconference calls, over emails and in writing and reviewing the draft. The full Design Team is listed here: o Peyush Agarwal STMicroelectronics Plot# 18, Sector 16A Noida, U.P 201301 India Phone: +91-120-2512021 EMail: peyush.agarwal@st.com o Dave Hetherington Roving Planet 4750 Walnut St., Suite 106 Boulder, CO 80027 United States Phone: +1-303-996-7560 EMail: Dave.Hetherington@RovingPlanet.com o Matt Holdrege Strix Systems 26610 Agoura Road Calabasas, CA 91302 Phone: +1 818-251-1058 EMail: matt@strixsystems.com o Victor Lin Extreme Networks 3585 Monroe Street Santa Clara, CA 95051 Phone: +1 408-579-3383 EMail: vlin@extremenetworks.com o James M. Murphy Trapeze Networks 5753 W. Las Positas Blvd. Pleasanton, CA 94588 Phone: +1 925-474-2233 EMail: jmurphy@trapezenetworks.com o Partha Narasimhan Aruba Wireless Networks 180 Great Oaks Blvd San Jose, CA 95119 Phone: +1 408-754-3018 EMail: partha@arubanetworks.com o Bob O'Hara Airespace Yang (Editor), et al. Expires December 28, 2004 [Page 39] Internet-Draft CAPWAP Arch. Taxonomy June 2004 110 Nortech Parkway San Jose, CA 95134 Phone: +1 408-635-2025 EMail: bob@airespace.com o Emek Sadot (see Authors' Addresses) o Ajit Sanzgiri Cisco Systems 170 W Tasman Drive San Jose, CA 95134 Phone: +1 408-527-4252 EMail: sanzgiri@cisco.com o Inderpreet Singh Chantry Networks 1900 Minnesota Court Mississauga, Ontario L5N 3C9 Canada Phone: +1 905-567-6900 EMail: isingh@chantrynetworks.com o L. Lily Yang (Editor, see Authors' Addresses) o Petros Zerfos (see Authors' Addresses) In addition, we would also like to acknowledge the contributions from the following individuals who participated in the architecture survey and provided detailed input data in preparation of the taxonomy: Parviz Yegani, Cheng Hong, Saravanan Govindan, Bob Beach, Dennis Volpano, Shankar Narayanaswamy, Simon Barber, Srinivasa Rao Addepalli, Subhashini A. Venkataramanan, Kue Wong, Kevin Dick, Ted Kuo and Tyan-shu Jou. It is simply impossible to write a taxonomy without a large representative data points that they provided us. We would also like to thank our CAPWAP WG co-chairs, Mahalingam Mani and Dorothy Gellert, and our Area Director, Bert Wijnen, for their unfailing support. 9 References [1] "IEEE WLAN MAC and PHY Layer Specifications", August 1999, . [2] "CAPWAP Problem Statement", February 2004, . [3] "The Internet Standards Process Revision 3", October 1996, . [4] "Key words for use in RFCs to Indicate Requirement Levels", March 1997, . Yang (Editor), et al. Expires December 28, 2004 [Page 40] Internet-Draft CAPWAP Arch. Taxonomy June 2004 [5] "IEEE Std 802.11i/6.0: Specification for Enhanced Security", September 2003. [6] "IEEE Std 802.11h: Spectrum and Transmit Power Management Extensions in the 5 GHz Band in Europe", October 2003. [7] "IEEE Std 802.1X: Port-based Network Access Control", June 2001. Authors' Addresses L. Lily Yang Intel Corp. MS JF3 206, 2111 NE 25th Avenue Hillsboro, OR 97124 Phone: +1 503-264-8813 EMail: lily.l.yang@intel.com Petros Zerfos UCLA - Computer Science Department 4403 Boelter Hall Los Angeles, CA 90095 Phone: +1 310-206-3091 EMail: pzerfos@cs.ucla.edu Emek Sadot Avaya Atidim Technology Park, Building #3 Tel-Aviv 61131 Israel Phone: +972-3-645-7591 EMail: esadot@avaya.com Yang (Editor), et al. Expires December 28, 2004 [Page 41] Internet-Draft CAPWAP Arch. Taxonomy June 2004 Appendix A. WLAN Architecture Survey Template 1. Design considerations and requirements: please briefly describe your design principles for this architecture. 2. WLAN functions supported: Please list the functions supported in this WLAN briefly, but please do not send us the entire data sheet. Examples of WLAN functions includes the STA services, Distributed System Services (as defined by 802.11), radio resource management and control, AP load balancing, mobility support, WLAN network wide security functions (including authentication, encryption for privacy and integrity, etc.) and any others not listed here but deemed important in your design. 3. The functional architecture to implement the functions described above: whether it is by Autonomous WLAN Architecture, or Centralized Architecture. For Centralized Architecture, please provide the functional mapping of WLAN functions onto the AP and AC -- with just enough details that help us understand the kinds of functional interface necessary between the two. 4. The protocol used in between AP and AC. 5. The topological assumptions between AP and AC (is it directly connected, L2 switched, or L3 routed?) -- this also helps us to understand the deployment scenarios. 6. Security threat analysis: what kinds of threat introduced by the split architecture, and how that are addressed. 7. Pros and Cons of this architecture, esp. in relation to the four problems described in the CAPWAP problem statement. Please keep the analysis at technical instead of marketing level. Yang (Editor), et al. Expires December 28, 2004 [Page 42] Internet-Draft CAPWAP Arch. Taxonomy June 2004 Appendix B. Survey Contribution For Architecture 1 (1) Design considerations and requirements: please briefly describe your design principles for this architecture. Ease of deployment, flexibility to deploy in any network architecture, simple, centralized management, secure deployments, and automation of WLAN configuration, monitoring, and management functions are the design goals of this architecture. The system consists of three components, the access point (AP), the switch or appliance (AC), and the Control System. For the purposes of the CAPWAP work, the Control System can be ignored. The AP is "lightweight" in its functionality, compared to traditional APs. The AP implements the "real-time" portions of the 802.11 over the air protocol, including RTS/CTS and ACK processing, Beacon transmission, Probe Response construction and transmission. All 802.11 frames are transferred between the AP and AC in a tunnel. No frames are bridged locally by the AP. The AP is capable of presenting multiple WLANs simultaneously, appearing to be an independent AP for each WLAN. The AC performs the 802.11 MAC Management functions of authentication and association. In addition, the AC provides the information to each AP to configure the operation of each WLAN and to provision the AP to operate as a cooperating component of a larger WLAN system. The AC performs the bridging function for all data frames entering and leaving the WLAN. (2) WLAN functions supported: Please list the functions supported in this WLAN briefly, but please do not send us the entire data sheet. Examples of WLAN functions includes all the STA services, Distributed System Services (as defined by 802.11), radio resource management and control, load balancing, mobility support, WLAN network wide security functions (including authentication, encryption for privacy and integrity, etc.) and any others not listed here but deemed important in your design. All 802.11 WLAN functions are provided by this vendor's WLAN system. Station services are provided in part by the AP and in part by the AC. Distribution services are provided by the AC. Integration services are also provided by the AC. a. Beyond those services currently in the 802.11 standard, this WLAN Yang (Editor), et al. Expires December 28, 2004 [Page 43] Internet-Draft CAPWAP Arch. Taxonomy June 2004 system provides WLAN-wide coordinated radio resource management, providing both dynamic channel assignment and transmit power control in response to local noise and interference measurements at each AP, as well as incorporating topology information of the APs in the WLAN system. b. Rogue detection and containment services are provided, detecting both rogue APs (those not part of the WLAN system) and ad hoc networks. Containment (prevention of use) is provided through several manual and automated methods. c. Location services are provided, allowing WLAN devices, both rogue APs or ad hoc clients and authorized mobile devices in the WLAN to be located to within 3m. d. Local IPsec VPN termination in the AC is provided in the AC, including forwarding of mobile device security context to other ACs as the mobile device roams to APs serviced by those other ACs. e. Cross-subnet mobility without any software on the mobile device (such as mobile IP or other special client software) is provided by the AC. f. Access control lists are applied to all traffic from each mobile device by the AC. Access control lists may be configured manually on the AC or provided dynamically by AAA attributes for individual users. g. Dynamic QoS provided via configuration on the AC or from AAA attributes for individual users. (3) The functional architecture to implement the functions described above: whether it is by autonomous AP architecture, or "split" architecture. For split architecture, please provide the functional mapping of WLAN functions onto the AP and AC -- with just enough details that help us understand the kinds of functional interface necessary between the two. This architecture uses a "split MAC" architecture. The mapping of WLAN functions to the AP and AC are as follows: On the AP: a. real-time frame exchange over the air (RTS/CTS, Data/ACK), including retransmission and rate adaptation b. time critical MAC Management (Beacon, Probe Response) Yang (Editor), et al. Expires December 28, 2004 [Page 44] Internet-Draft CAPWAP Arch. Taxonomy June 2004 c. Virtual AP (multiple SSID) d. power management packet buffering e. RF monitoring (radar detection, noise measurement, interference measurement) f. LWAPP encapsulation/decapsulation of all frames to/from AC g. L2 encryption h. L2 QoS On the AC: a. LWAPP encapsulation/decapsulation of all frames to/from APs b. MAC Management processing (authentication, association) c. 802.1X/EAP processing d. Bridging between 802.11 and 802.3 (integration services) e. Configuration of RF parameters for all APs f. Provisioning of multiple WLANs g. Load balancing between APs h. Mobility management between APs and between multiple ACs. i. L3 encryption (IPsec VPN) j. Access control lists for mobile devices k. Location services l. Proxy ARP m. DoS detection and prevention (4) The protocol used in between AP and AC. LWAPP (draft-calhoun-seamoby-lwapp-03.txt), operating at either L2 or L3. (5) The topological assumptions between AP and AC (is it directly connected, L2 switched, or L3 routed?) -- this also helps us to Yang (Editor), et al. Expires December 28, 2004 [Page 45] Internet-Draft CAPWAP Arch. Taxonomy June 2004 understand the deployment scenarios. There are no assumptions of network topology between AP and AC. a. APs may be directly connected to an AC, b. There may be an arbitrary L2 switching infrastructure between the AP and AC, c. There may be an arbitrary L3 network between the AP and AC. (6) Security threat analysis: what kinds of threat introduced by the split architecture, and how that are addressed. Security threats considered: a. Interception of control traffic between AP and AC b. Insertion of control traffic to AP or AC c. Insertion of unauthorized AP d. Theft of embedded secrets in APs e. Access by unauthorized user f. Masquerade as authorized user g. DoS threats h. ARP spoofing Methods used to address security threats (letter of method corresponds to same letter of threat, above) a. All control traffic between AP and AC is encrypted using dynamic session key negotiated using authenticated DH exchange b. All control traffic is authenticated in encrypted LWAPP tunnel c. APs include individual X.509 certificates to validate identity. AAA authentication may also be used to validate individual APs. d. There are no secrets in the AP that are in non-volatile memory. e. Several user authentication methods are supported, including a local authentication via web login, IPsec VPN, 802.1X, WPA, WPA2. Yang (Editor), et al. Expires December 28, 2004 [Page 46] Internet-Draft CAPWAP Arch. Taxonomy June 2004 f. AC maintains address equivalence mappings to prevent masquerade g. AC detects DoS attacks and provides system-wide black listing of attacking device. h. AC provides proxy ARP functions and black lists any device spoofing ARP replies. (7) Pros and Cons of this architecture, esp. in relation to the four problems described in the CAPWAP problem statement. Please keep the analysis at technical instead of marketing level. All problems described in the problem statement are addressed with this solution. In addition, significant additional functionality is provided by the centralization of information in the ACs. Yang (Editor), et al. Expires December 28, 2004 [Page 47] Internet-Draft CAPWAP Arch. Taxonomy June 2004 Appendix C. Survey Contribution For Architecture 2 There is considerable ambiguity in the use of the term AP within and outside this group. I would like to propose a change in terminology that the CAPWAP design team should use in the taxonomy draft. I had sent an earlier email to this group on re-defining the term AP to mean the set of functions that an access point is expected to provide as defined in the 802.11 spec. The physical box that terminates the infrastructure side of the wireless link is referred to as the wireless termination point (WTP). For implementation purposes, the set of AP functions MAY be split between the WTP and the AC. This document uses the terms "AP" and "WTP" according to the above definitions. (1) Design considerations and requirements: please briefly describe your design principles for this architecture. Secure, scalable, large-scale WLAN deployments. The AC was designed to be much more than a manager of physical Wireless Termination Points (WTPs). All 802.11 data traffic passes through a stateful, per-user firewall at the AC before it is allowed to enter the network beyond the AC. The AC offers termination of both 802.11 L2 security and L3 VPNs including configurations that support simultaneous operation of both L2 and L3 encryption. The WTPs are meant to terminate the infrastructure side of the wireless physical link. They are meant to be very intelligent devices from an RF perspective (monitor the RF environment around them to aid radio resource management), but are very simple devices with user state limited to rate adaptation, retransmissions, and power-save buffering, no security state and no persistent configuration information. The connectivity between a WTP and an AC should be very flexible with support for three modes - directly connected, connected across an L2 cloud, and connected across an L3 cloud. All configuration is centralized at the AC. The WTPs discover one or more ACs to home to and, after mutual authentication, setup multiple tunnels that are routable over an L3 cloud to carry control/ configuration information and 802.11 mgmt/data frames. The control tunnels are encrypted while the encryption on the tunnels carrying 802.11 traffic can be configured to be encrypted. Yang (Editor), et al. Expires December 28, 2004 [Page 48] Internet-Draft CAPWAP Arch. Taxonomy June 2004 All user and security state is maintained at the AC, with the user state at the WTP limited to rate adaptation, retransmissions, and power-save management. The access control is based on a model of assigning roles to users. The mapping of a user into a role is based on a very flexible set of configuration options. A set of firewall rules associated to each role, including bandwidth contracts and QoS, control the traffic flow between a user the network behind the AC. The ACs provide dynamic radio resource management aided by measurements at the WTPs. (2) WLAN functions supported : Please list the functions supported in this WLAN briefly, but please do not send us the entire data sheet. Examples of WLAN functions includes the STA services, Distributed System Services (as defined by 802.11), radio resource management and control, AP load balancing, mobility support, WLAN network wide security functions (including authentication, encryption for privacy and integrity, etc.) and any others not listed here but deemed important in your design. All of the AP functions as defined in the 802.11 spec Load-balancing across WTPs is achieved by exploiting the wider view of the RF network that an AC has than what is available at the WTP. Intra-AC handoffs, where a station roams between two WTPs homed to the same AC, are very quick with a simple table update at the AC. Inter-AC handoffs requiring inter-VLAN mobility are supported with proxy mobile IP. Multiple authentication methods and multiple encryption ciphers (both L2 and L3). Flow classification and bandwidth contracts for QoS. Virtual APs (multiple SSIDs per AP). Radio resource management functions are handled by the AC based on measurements at the WTPs. (3) The functional architecture to implement the functions described above: whether it is by autonomous AP architecture, or "split" architecture. For split architecture, please provide the functional mapping of WLAN functions onto the AP and AC -- with just enough details that help us understand the kinds of functional interface necessary between the two. The set of AP functions is split between the WTP and the AC. All Yang (Editor), et al. Expires December 28, 2004 [Page 49] Internet-Draft CAPWAP Arch. Taxonomy June 2004 real-time (RT) functions stay at the WTP, while all non-RT functions are handled at the AC. All 802.11 basic media access functions are performed at the WTP. All 802.11 control frames are generated and processed at the WTP. A majority of 802.11 management frames are processed at the AC. Beacon frames are generated at the WTP. Power-save management, retransmissions, and rate adaptation are implemented at the WTP. 802.11 authentication and association frame processing is implemented at the AC. Translation of 802.11 data frames to 802.3 frames is implemented at the AC. All 802.11 data frames are tunneled over to the AC in the uplink direction while the AC tunnels 802.11 data frames to the WTP in the downlink direction. Other 802.11 data frame processing functions like encryption and fragmentation and reassembly are performed at the AC. (4) The protocol used in between WTP and AC. Discovery: An WTP is able to discover one or more ACs to authenticate with and home to using either static configuration or dynamic, run-time discovery methods that work across L2/L3 boundaries. Configuration: Configuration is transported through an encrypted tunnel back to the AC. This uses a secure and proven architecture while also allowing for each individual WTP to be accounted for and monitored at a back-end Radius server. Each WTP can have its own set of access information to differentiate itself from other WTPs. This allows the AC to control access on a per WTP basis. Transport: Tunnels (optionally encrypted) that are capable of spanning L3 boundaries between an WTP and an AC carry all 802.11 frames. The 802.11 frames are terminated at the AC - so encryption, fragmentation/reassembly, and 802.11-802.3 translation are moved to the AC. This also means that if the 802.11 data frames are encrypted on the air interface, they are encrypted on the tunnel even if the encryption on the tunnel is not turned on. (5) The topological assumptions between WTP and AC (is it directly connected, L2 switched, or L3 routed?) -- this also helps us to understand the deployment scenarios. Supports all three of - directly connected Yang (Editor), et al. Expires December 28, 2004 [Page 50] Internet-Draft CAPWAP Arch. Taxonomy June 2004 - L2 connected - L3 connected (6) Security threat analysis: what kinds of threat introduced by the split architecture, and how that are addressed. Full control of the WTP may be gained through the proprietary messaging for configuring the WTP. Addressed by encrypting the tunnel carrying the configuration to protect this information. If the WTP is stolen, a hacker may be able to extract the security information required to setup the encrypted tunnel. Addressed by protecting this security information with additional encryption. If the WTP is stolen, it would still appear to be possible to connect to the WTP from another wireless client and gain access to the network. This is addressed by the stateful user firewall in the same central location at the AC. The stolen WTP may connect to the AC, but it will still be unable to pass meaningful traffic through the AC until the client authenticates itself. Possible to masquerade as a different user once a particular authentication has passed through due to having several devices being involved. Addressed by keeping all encryption and firewalling at the AC to prevent any type of masquerading. (7) Pros and Cons of this architecture, esp. in relation to the four problems described in the CAPWAP problem statement. Please keep the analysis at technical instead of marketing level. Problem #1, #2, and #3 are addressed by keeping all configuration and dynamic information in one central location. Problem #4 is protected by an encrypted tunnel created between the WTP and AC. Security threats discussed in question #6. Yang (Editor), et al. Expires December 28, 2004 [Page 51] Internet-Draft CAPWAP Arch. Taxonomy June 2004 Appendix D. Survey Contribution For Architecture 3 (1) Design considerations and requirements: - Secure mobility that scales. - User based subnet membership independent of AP association. - No client specific code. - AP requires no configuration. - AP is not capable of autonomous function. - Split MAC (ARCH2). (2) WLAN functions supported: - WPA. - WME. - AP Load Balancing. - Inter-subnet Mobility support. - Multiple Authentication Types: MAC-AUTH, WEB-AUTH, DOT1X. AC speaks EAP or forwards to RADIUS server. - Subnet Membership determined through AAA. - Multiple subnets per SSID. - Multiple SSIDs/BSSIDs per radio. - Multiple Encryption types per radio WEP, TKIP, AES(CCMP). - Rouge AP detection, location and countermeasures. - Auto or Static RF configuration. (3) The functional architecture to implement the functions described above: - Split MAC (ARCH2). - AP: Yang (Editor), et al. Expires December 28, 2004 [Page 52] Internet-Draft CAPWAP Arch. Taxonomy June 2004 + Per packet QoS. + Encryption. + 802.11 Control Frames. - AC: + 802.11 Management. + QoS Classification. + 802.1x. + All Configuration/Management and Image Control. + L2 forwarding (could be moved to AP). (4) The protocol used in between AP and AC. - IP tunnels. (5) The topological assumptions between AP and AC (is it directly connected, L2 switched, or L3 routed?) - All of the above. (6) Security threat analysis: what kinds of threat introduced by the split architecture, and how that are addressed. - PTK/GTK transmitted between the AC and AP and must be encrypted. - 802.11 station data is transmitted between the AC and AP and may be encrypted. - AP authentication. AP is authenticated by the AC. It is not required that the AC is authenticated by the AP as it would violate the zero configuration requirement. An unauthenticated AC reduces to a rogue AP and there are other techniques to deal with that. (7) Pros and Cons of this architecture, esp. in relation to the four problems described in the CAPWAP problem statement. - Cons: + Assumes the AC is in a trusted network. - Pros: + Scaling configuration and management. + Fast roaming. + Encryption processing is distributed to APs but centrally controlled. + Zero configuration AP - a lost or stolen AP has no sensitive information. Yang (Editor), et al. Expires December 28, 2004 [Page 53] Internet-Draft CAPWAP Arch. Taxonomy June 2004 + Extends wired subnet partitioning to wireless network based on user not location. Yang (Editor), et al. Expires December 28, 2004 [Page 54] Internet-Draft CAPWAP Arch. Taxonomy June 2004 Appendix E. Survey Contribution For Architecture 4 (1) Design Considerations and Requirements The following is a short list of our major technical requirements that were used to drive the design of products in this architecture: Full functionality and compatibility for current and future 802.11 standards Keep the set of functions in the AR to the absolute minimum while pushing as much functionality up to the AC. Allow existing, installed Access Points (APs) to be converted into an AR with a simple firmware change. This allows many new functions to be added to legacy infrastructures since most of the new functionality is in the AC. Ensure the system provides as much security as the Access Point Model Provide a platform for "mobility" and other added value functions (2) WLAN Functions Supported All current 802.11 standards (a,b,e,i,g,....) Multiple BSS/ESS operation on both the AC and AR 802.1p/q support Enhanced QoS services Support for enhanced WLAN functions to support Fast Roaming / Fast Handoff Voice over IP support Enhanced Power Management for Clients Load Balancing and other Mobility Features (3) Functional Architecture The basic operation is as follows: System operation begins with the boot and adoption process. The AR contains only a small boot loader that does not include any RF code and must downloaded with runtime code from the AC. Once the code is downloaded from the AC into the AR, the AR is configured with the runtime parameters by the AC. This involves some initial packets that contain channel, power, addressing, number of supported BSSs, beacon times, etc.. It also involves an ongoing process that updates the AR with beacon information, such as the content of the TIM field as well as load information. Hence configuration is both a one-time event and a continuing event. Once the AR is configured it is ready to begin beaconing and respond to packets from MUs. Fully formatted 802.11 packets are encapsulated and sent over the L2 network from the AC to the AR for transmission. Each packet sent by the AC to the AR generates a status result back to the AC from the AR. Sequence numbers are used to ensure delivery. Packets received by the AR from the radio(s) are encapsulated and forwarded over the L2 network to Yang (Editor), et al. Expires December 28, 2004 [Page 55] Internet-Draft CAPWAP Arch. Taxonomy June 2004 the AC. A key concept is that the ARs are stateless insofar as Mobile Units (MUs) are concerned. The AR really does not know about Mobile Units. If a packet is addressed to the AR, it will accept it, generate an acknowledgement packet, and then forward the packet to the AC in an encapsulated Ethernet frame of an EtherType allocated to this vendor. The functions performed by the AR once it is loaded, configured, and running consist of: Basic RF packet transmit tasks such as: Preamble selection, PHY interface, Packet CRC, and Sequence number generation RF Packet reliability mechanisms such as: Retransmission timers, retries, ACK packets and reception RF Channel Access and exchange timings (SIFS, etc.). This includes RF QoS queuing RF Packet reception including: checking PLCP headers, address filtering, basic address checking, and packet CRC checking Generation of Beacons and DTIM broadcast packet transmission Handling of Probe/probe response and RTS/CTS sequences Interface to the wired network. Status reporting to the AC including per packet results and as well as global counters Packet Buffering for immediate RF transmit scheduling purposes The functions performed by the AC include: Association and authentication Key management, key mixing, etc. Packet format conversion between 802.11 and 802.3 Encryption/MIC using multiple algorithms WEP, WPA, AES, etc.. Packet/user level buffering and QoS scheduling Address filtering (collecting packets off the wired/wireless network for Mobile Units) 802.1 p/q mapping to 802.11 priority classes Support for QoS mechanisms Communication between different ACs Management and configuration utilities like Telnet, HTML, SNMP, etc. (4/5) Topological Assumptions/encapsulation protocol This implementation currently uses an L2 protocol in an EtherType frame allocated to this vendor. This allows the AR and the AC to either be directly connected or connected via one or more L2 switches. Since this AC supports multiple VLANs, the ARs may be on one or more different VLANs and these VLANs may be different than those upon which the Mobile Units logically reside. We chose the L2 operation as the best model for AC and AR Yang (Editor), et al. Expires December 28, 2004 [Page 56] Internet-Draft CAPWAP Arch. Taxonomy June 2004 connectivity for several reasons. The first is that it is consistent with the goal of keeping the AR as simple as possible. The AR does not require an IP address, subnet mask, or default gateway nor does it need DHCP, SNMP, ICMP, UDP, etc.. In addition, there is no need to pre-configure the AR prior to installation. The AR is truly a zero configuration device. The configuration of the AR takes place entirely at load time. If the AR had to support additional networking protocols the AR would have to become much like a regular "fat" Access Point and most of the management advantages of the AR/AC model are seriously diluted. The second reason is that current Access Points are L2 devices. Since the AC/AR model represents a different partitioning of access point functionality, it seemed reasonable that the combined AC/AR should also be L2 device. The third reason is that L2 operation is more secure than L3 operation. More discussion of this issue follows in section 6. (6) Security Threat Analysis The security concerns with a split architecture can be divided into two general areas: User data security and system management security. User data security is concerned with both unauthorized access to the wired network as well as privacy of the user data. Both are automatically taken care of in our model since the user data from MUs remains encrypted using the "over the air" security mechanisms used by 802.11. The AR-AC is essentially treated as another RF "hop" and hence is as secure as the AR-MU link. In addition all 802.11 packets are encapsulated in Ethernet frames and are addressed only to either the AR or the AC. Such packets cannot "escape" onto or from the wired network since they are always inside properly addressed Ethernet packets. Given these two mechanisms, nothing else is required to ensure both secure network access and user privacy. System management security is essentially concerned with "hijacking" of the AR by "a rogue AC." The worry here is that another station on the network may pretend to be the AC and take control of the AR. If this happens the AR may be mis-configured or taken control of entirely to become part of a virtual "rogue" AP. In this architecture system management attacks are unlikely to take place and can be easily detected. Given the communication between the AR and AC takes place at L2, any attacker would need to be on the same subnet (or VLAN) as the AR and AC. This implies the user already has physical access to the network and so the network is Yang (Editor), et al. Expires December 28, 2004 [Page 57] Internet-Draft CAPWAP Arch. Taxonomy June 2004 already compromised. Attacking an AR when one already has physical access to the network is pointless. Should an attacker still try to mis-configure a working AR by pretending to be the actual AC, it must send a packet with the same source address as the actual AC since the AR verifies the source address of all frames it receives. If this occurred the L2 switch would reconfigure itself to direct all traffic for the actual AC to the rogue AC and essentially isolate the actual AC. That AC would quickly detect this and notify an administrator as well as shut down the WLAN. Boot time attacks will also be detected by the actual AC since it will see the boot request and also respond to the AR. It should be noted that a rogue AR and rogue AC do not present any threat to Mobile Units provided the Mobile Units follow the proper standards for mutual authentication. From a Mobile Unit perspective a rogue AP/AC combination is equivalent to a rogue Access Point. Hence our split network model introduces no new security issues over a conventional Access Point model and in fact offers greater security. (7) Pros and Cons of Architecture Overall we are quite satisfied with our current architecture. The basic model has been implemented on a number of AR and AC devices without any problems. We have also successfully upgraded old 802.11 Access Points to support the latest encryption protocols like WPA and AES. There are of course areas of enhancement. One is the location of the transmit side of the encryption process. Some of our current ARs are built with chips that did not support all desired encryption algorithms but going forward the chips we use to build future ARs will likely include such functionality. It would be nice to be able to take advantage of this capability on new ARs while also supporting the older ARs. Yang (Editor), et al. Expires December 28, 2004 [Page 58] Internet-Draft CAPWAP Arch. Taxonomy June 2004 Appendix F. Survey Contribution For Architecture 5 Abstract This document describes an architecture for residential WLAN deployments. It presents simple equipment for consumers while complexity and overall network management are left to service providers. Additionally, it also integrates radio-over-fiber (RoF) technology to provide network services to common areas outside individual residences. 1. Introduction This architecture includes a set-top box (STB) at the consumer's residence, a radio-over-fiber (RoF) antenna in common areas around a number of residences and a controller at the service provider's premises. The STB wirelessly streams data and media content to other products like TVs and display consoles. It is also capable of PHY layer and partial MAC layer processing for wireless transmissions to other client devices. An antenna structure outside individual residences provides network access to common areas. This is in conjunction with the service provider's controller by means of radio-over-fiber transmissions. This document describes the Broadnow+ WLAN architecture with respect to the needs of the CAPWAP Architecture Taxonomy document. 2. Design Considerations and Requirements Broadnow+ is based on a high-speed, dedicated backbone between STBs, RoF antennas and the central controller. This allows for flexibility in the physical location of various processing requirements. The central controller realizes complete IEEE802.11 functionality including PHY layer aspects. It then performs selective degrees of processing for different destinations, i.e., for STBs, RoF antennas, and other devices. The controller is also responsible for overall network management including client authentication and channel adaption. STBs process IEEE802.11 PHY layer functionality and IEEE802.11 MAC layer association services for all transmissions. In addition, they implement proprietary MAC functionality for transmissions to other devices of this vendor like TVs. These functions are designed primarily for transmitting media to high-resolution displays. For transmissions to other client devices however, the STBs only perform IEEE802.11 PHY and IEEE802.11 MAC association services. The remaining IEEE802.11 MAC services are left to the central controller. Yang (Editor), et al. Expires December 28, 2004 [Page 59] Internet-Draft CAPWAP Arch. Taxonomy June 2004 . The antenna used for radio-over-fiber transmission is a very simple device. It merely performs optical to electrical conversions and transmits the resulting radio signals. This places the need for high-speed, fiber connectivity between the antenna and controller. As such, this requirement is being increasingly met in the residential market place.. Mobility concerns in the residential environment are present albeit slightly. It is highly unlikely that clients will roam to neighboring residences for network access. As such, this is not dealt with in great detail in the Broadnow+ architecture. However, it is necessary to ensure that rogue clients do not take advantage of legitimate customers by exploiting their subscriptions. Appropriate authentication mechanisms between client devices and the controller are used to avoid this. 3. WLAN Functions Supported The controller is a powerful device capable of processing complete IEEE802.11 functionality which are then selectively performed for STBs and radio-over-fiber transmissions. It includes support for QoS, security and control. The various functionalities are realized as a combination of individual components of fine granularity. Such an implementation ensures that the controller can accurately provide complementary functions to the end-devices. Algorithms and procedures for transmit power control, channel selection and interference management are performed at the controller and the resulting control signals are forwarded to the STBs and antennas. In terms of security, the controller terminates MAC layer encryption for both proprietary and other end-devices of the STBs. Authentication requirements in the residential environment are as stringent as those in enterprises. It is important that rogue clients do not take advantage of legitimate consumers, i.e., no free riders. As such, authentication is performed at the controller for all clients accessing the STBs and RoF antennas. The STBs include full fledged capabilities (MAC + PHY) for transferring content to products such as TVs and display consoles. However, they feature only light weight wireless capabilities for transmissions to other client devices, leaving the bulk of operations to the controller. Overall the STBs are capable of channel measurements, feedback to the controller, transmit power adjustments etc. In general the STBs are able to process IEEE802.11 PHY and IEEE802.11 MAC association services. They also include proprietary MAC aspects for transmissions to other devices from this vendor. Yang (Editor), et al. Expires December 28, 2004 [Page 60] Internet-Draft CAPWAP Arch. Taxonomy June 2004 4. Functional Architecture The STBs combine two different WLAN functional architectures for the transmissions to proprietary and other clients, respectively. For proprietary clients, the architecture consists of IEEE802.11 PHY and IEEE802.11 MAC association services. The remaining MAC functionalities are proprietary. For other clients, STBs only process IEEE802.11 PHY IEEE802.11 MAC association services, leaving the remaining IEEE802.11 MAC operations to the controller. For both types of transmissions, control aspects are handled by the controller based on feedback sent by the STBs. In addition to these two functional architectures, Broadnow+ also includes radio-over-fiber capabilities. As such, the end-device is a simple antenna capable of making optical to electrical conversions and broadcasting the resulting radio signals. The RoF antenna also includes logic to sense channel conditions and to send this back to the controller for analysis and further action. The controller, at a central location, accommodates these three functional architectures. It includes the complete WLAN functionality based on IEEE802.11 standards. For transmissions to proprietary clients, it merely acts as authenticator and channel manager. For other clients, it processes the remaining IEEE802.11 MAC functionality after having the STBs process IEEE802.11 MAC association and IEEE802.11 PHY services. And for RoF transmissions, the controller performs complete IEEE802.11 MAC and PHY processing before making the electrical to optical conversions. In all three cases, the controller is responsible for overall control and management. Based on these descriptions, the degree of wireless functional implementation in this architecture is different for the type of end- devices. In terms of CAPWAP, these constitute three different types of functional architectures/splits. 5. AP-AC Protocol This is a proprietary protocol. 6. Topological Assumptions The connection between the controller and STBs is high-speed and dedicated. This includes coax, ADSL and fiber. As such, the topology is that of direct connection. 7. Security Threat Analysis Yang (Editor), et al. Expires December 28, 2004 [Page 61] Internet-Draft CAPWAP Arch. Taxonomy June 2004 When fiber is used for the dedicated connections, it allows for strong physical security. In addition to this, Broadnow+ incorporates cryptographic security for exchanges between the controller and STBs. The STBs are hard-coded with a seed with which session keys are generated. These keys are then used to encrypt transmissions between the controller and STBs. The cryptography mechanism also uses SD card based seeds for session key generation. So in addition to strong physical security, the architecture also includes another level of cryptographic security. 8. Architectural Analysis The primary advantage of implementing WLAN functionality in fine-grained components is to allow flexibility in the functional architecture. For now, this allows for the distinction of transmissions to proprietary and other clients. Additionally, it provides for integral management from the Broadnow+ controller. Broadnow+'s relatively light implementation for transmissions to other devices leads to lower costs for STBs. For the service provider, this architecture allows a management premium to be levied. As such, this architecture for wireless media content and data delivery offers increased benefits for both consumers and service providers. 9. Conclusion This document has presented an architecture for residential WLANs. It combines wireless transmission functionality to proprietary and other client devices. For proprietary devices, STBs use standard IEEE802.11 PHY and IEEE802.11 MAC association services in addition to a proprietary MAC, optimized primarily for transmissions to proprietary TVs and display consoles. For other devices, the STBs adopt a split where IEEE802.11 PHY and IEEE802.11 MAC association services are handled locally while the remaining IEEE802.11 MAC services are left to the controller. And for radio-over-fiber transmissions, Broadnow+ consolidates all IEEE802.11 processing at the controller without using any split. The secure, low-latency connection between the controller, STBs and RoF antennas blur any distinction in WLAN functionality based on real-time requirements. Yang (Editor), et al. Expires December 28, 2004 [Page 62] Internet-Draft CAPWAP Arch. Taxonomy June 2004 Appendix G. Survey Contribution For Architecture 6 (1) Design considerations and requirements: This Wireless Switch Architecture consists of Thin APs and Controllers. It has been designed with the following considerations: - Thin APs should be cheap. This leads to a requirement that the thin AP be as simple as possible, with very low flash and ram requirements. - There will be many Thin APs in the network, so to reduce installation and maintenance cost they should require zero configuration. This leads to a requirement that configuration be served from the Controller or some other entity, and that some method for auto-discovery must exist where possible. In addition configuration of the RF parameters should be automatic. - The widely physically distributed nature of Thin APs leads to a frequent requirement that thin APs may be used in physically insecure environments. This leads to a requirement that user data not be encrypted/unencrypted on the thin AP but rather at the Controller. This allows the network's trust boundary to be placed at a physically secure location. In addition this allows novel new deployment scenarios - such as placing an AP in tele-commuters home without any VPN setup. - Thin APs and controllers should be deployable as simply as possible on top of the current legacy network infrastructure. This leads to a requirement that all communications be at Layer 3 rather than Layer 2 or direct. In addition the use of a VLAN aware infrastructure is precluded, and some method of cross-subnet discovery must be specified. - Rogue APs should not pose a security problem. This leads to a requirement that rogue APs be remotely detectable by Thin APs, and that Rogue APs may be remotely investigated and secured by Thin APs. - Wireless clients should be able to roam seamlessly between thin APs. This leads to a requirement that wireless clients retain their IP addresses, which in turn leads to a requirement that something equivalent to Mobile IP be used in large scale deployments. - Redundancy and load sharing. Both Thin APs and Controllers should be configured in redundant and load balanced configurations to provide maximum uptime and throughput. - Theft of thin APs should not pose a security problem. This leads Yang (Editor), et al. Expires December 28, 2004 [Page 63] Internet-Draft CAPWAP Arch. Taxonomy June 2004 to a requirement that thin APs should have no encryption keys in non-volatile memory. In addition since thin APs cannot work as standalone APs they are less likely to be stolen individually. (2) WLAN functions supported: ****All functions are supported: - Wireless client association and authentication - Radio Resource Management and Control - Load balancing of wireless clients between thin APs - Load balancing of thin APs across Controllers - EAP user authentication - WEP, WPA and IEEE 802.11i encryption, including TKIP and AES- CCM for wireless frames - Seamless wireless client roaming between thin APs - DS services via the thin AP Controllers - Detection of authorized APs - Authentication and encryption of all control traffic between APs and Controllers (3) Functional Architecture ****The architecture uses a split MAC, with the thin APs and Controllers communicating over a Layer 3 cloud. Only the most timing sensitive functions are performed at the Thin APs - All PHY layer functions, and these parts of the MAC - transmission and reception of MPDUs, CRC generation and checking, ACK generation, NAV, retries and the EDCA, priority queuing. TSF (Beacon and Probe response timestamp insertion). Multicast Power-save frame delivery. Raw MPDUs as seen on the wireless medium are exchanged with the controller encapsulated within UDP. Note - these MPDUs are not decrypted at the Thin AP and so any user data remains protected by whatever encryption mechanism is in use over the wireless network. The Controller can also act as a Mobile IP proxy on behalf of the wireless client (according to configuration). This allows seamless Yang (Editor), et al. Expires December 28, 2004 [Page 64] Internet-Draft CAPWAP Arch. Taxonomy June 2004 roaming across thin APs connected to different controllers. (4) The protocol used in between AP and AC. ****Each thin AP has one master controller and may have many backup Controllers. These are discovered during Boot and Discovery. On boot, the thin AP uses DHCP or static configuration to get its IP address and DNS server addresses. We specify 4 methods for discovering the IP address of the master Controller: DHCP, DNS, local subnet discovery and manual configuration. Once the master Controller is detected, the thin AP downloads a signed firmware image by TFTP. From then on Control messages are exchanged using SSL. A set of control messages has been defined using an ASCII format. User data is covered in (3) above. (5) The topological assumptions between AP and AC (is it directly connected, L2 switched, or L3 routed?) -- this also helps us to understand the deployment scenarios. ****L3 routed. This allows us to deploy one or more controllers anywhere on the user's LAN and the thin APs to be on distant subnets. The only limitation is the capabilities of the user's LAN and LAN switches: if the APs are too far from the controllers then traffic will be crossing multiple switches which is inefficient. In addition any broadcast traffic destined to the wireless network may have to be multicast across many subnets. (6) Security threat analysis: what kinds of threat introduced by the split architecture, and how that are addressed. Our security architecture significantly reduces security threats - by moving the trust boundary to the Controller - which may be placed in a physically secure location, and protected by firewalls. In traditional 'fat AP' architectures anyone with access to the network behind the 'fat APs' may inspect or tamper with traffic. In our architecture since the raw 802.11 frames that are seen over the air are transported to the controller this threat is significantly reduced. These frames are protected by whatever wireless security policy and mechanism has been selected. Our controllers implement WPA and 802.11e to provide a high level of security. (7) Pros and Cons of this architecture, esp. in relation to the four problems described in the CAPWAP problem statement. Please keep the analysis at technical instead of marketing level. Yang (Editor), et al. Expires December 28, 2004 [Page 65] Internet-Draft CAPWAP Arch. Taxonomy June 2004 **** We address all 4 problems: - Management and Control: The Controllers serve firmware and configuration to the thin APs and the thin APs require zero manual configuration, so the only entities that need to be managed are the Controllers themselves. - Configuration Consistency: Since the Controllers automatically control configuration across all thin APs, configuration consistency is maintained across the entire WLAN deployment - RRM to optimize WLAN efficiency: Again, since the Controllers see all 802.11 MAC traffic they know the instantaneous load on each thin AP, and can perform load balancing. - Unauthorized APs: Controllers are aware of any Unauthorized APs and can detect and prevent their use. Yang (Editor), et al. Expires December 28, 2004 [Page 66] Internet-Draft CAPWAP Arch. Taxonomy June 2004 Appendix H. Survey Contribution For Architecture 7 (1) Design considerations and requirements: Goal: Offer an easy-to-use solution for large installations of APs in terms of provisioning, controlling, scalability, plug&play, and mobility across subnets/vlans. In a nutshell, the 802.11 protocol suite terminate at the AP, which translates 802.11 data frames to 802.3 frames and send them to the AC. All STA traffic hit the AC. AC provision and control AP. WLAN "control" capabilities are embedded at the AC. (2) WLAN functions supported: All 802.11 services are supported: AP responsibilities: - 802.11 MAC - WEP/WPA Encryption/Decryption AC responsibilities: - STA services (authentication, association, etc.) - Integration - Distribution - Load Balancing - Rogue AP detection - Managing and controlling APs - Mobility - ACL/QoS policies. (4) The protocol used in between AP and AC. The AC and the APs communicate using a proprietary UDP transport, which is encrypted. (5) The topological assumptions between AP and AC Yang (Editor), et al. Expires December 28, 2004 [Page 67] Internet-Draft CAPWAP Arch. Taxonomy June 2004 At present only direct connection is supported. The next step would be to support connections across layer 2 and 3. (6) Security threat analysis: what kinds of threat introduced by the split architecture,and how that are addressed. Several aspects of security threats were addressed: STA traffic Over the Air - AP responsibility (WEP, WPA, etc') AC to AP control/provision - communication is authenticated and encrypted over a private UDP communication channel. AC to AC - Authentication and encryption over private UDP communication channel. AC to AAA - Standard. AC to Management station - Security over standard management tool such as SSH. (7) Pros and Cons of this architecture Problem 1: Each AP is an IP-addressable device requiring management, monitoring, and control - AC serves as a proxy for managing large scale APs. Problem 2: Maintaining a consistent configuration throughout the entire set of access points in the WLAN - Central management application to configure all AC in a wireless domain. Problem 3: Parameters controlling the wireless medium on each AP must be monitored frequently ... - partially supported, ACs monitoring connected APs to provide information to central management station. Problem 4: Securing access to the network and preventing installation of unauthorized access points & Mutual authentication of AC and AP. Supplementary functionality in the shape of Rogue AP detection. Yang (Editor), et al. Expires December 28, 2004 [Page 68] Internet-Draft CAPWAP Arch. Taxonomy June 2004 Appendix I. Survey Contribution For Architecture 8 (1) Design considerations and requirements: The operational and network management challenges for large scale (thousands of APs) wireless LANs encompass both the 802.11 layer as well as the wired side topological interactions. The considerations and requirements for the architecture presented below are: - true layer 3 mobility for wireless mobile clients as they move from one AP to another - WLAN system scalability - A single AC should be able to control and manage a large number of APs (100's of APs) - near real time RF management - centralized traffic policy management and enforcement - centralized control and management of the APs - centralized user management - architecture must be extensible to other radio technologies - architecture must be able to facilitate mobility between different MAC architectures (e.g.,. work being done in IEEE 802.21 and IRTF MOBOPTS) Also, because of the requirement for the deployment of very large scale WLANs and the fact that these WLANs must integrate into existing wired infrastructures, there should be no consideration (or full flexibility) on the topological deployment of ACs and APs. (2) WLAN functions supported: Access Point: - All 802.11 services including - association/disassociation/reassociation - authentication - integration - distribution - Robust Security (802.11i) - QOS (802.11e) - radio resource management including load balancing and RF management - bridging (802.11 to 802.3) Yang (Editor), et al. Expires December 28, 2004 [Page 69] Internet-Draft CAPWAP Arch. Taxonomy June 2004 - link state transition notification to the AC(s) Access Controller: - centralized forwarding (routing), authentication, encryption and policy enforcement of mobile client traffic - control and configuration of AP - QOS policy enforcement and management - user access control (3) Functional architecture: - AC manages and controls APs - L3 state and user sessions are maintained and managed at the AC - L2 state and user sessions maintained at the AP and all state information is mirrored at the AC - The 802.11 MAC is "not" split. However, it is controlled centrally at the AC (4) The protocol used in between AP and AC: A UDP based tunnelling protocol that has a control channel and a data channel. The control channel carries AP configuration and state commands from the AC. Also, it carries information regarding AP state transitions and statistics from the AP to the AC. The data path is simply the encapsulation of 802.3 bridged data. The data-path channel is optional. IE., if configured, the data path can be bridged locally from the AP and the data does not necessarily have to go through the AC. (5) The topological assumptions between AP and AC: The AC and AP can be directly connected to each other, could be connected through L2 switches or any arbitrary L3 cloud. The architecture is tolerant to higher latency between AP and AC. (6) Security threat analysis: what kinds of threat introduced by the split architecture, and how those are addressed. Since the AP and AC can be separated over any arbitrary L3 cloud, first and foremost there is a need for a secure binding between the AC and AP. A control channel security association is required between the AC and AP. The AC and AP must go through a mutual authentication phase during a discovery and registration process and form a security association. The traffic is confined to control, configuration and management traffic between the AC and AP. There is an optional data path security association that can also be created. It is believed that for security sensitive applications and deployments there will always be an end to end encrypted tunnel. Yang (Editor), et al. Expires December 28, 2004 [Page 70] Internet-Draft CAPWAP Arch. Taxonomy June 2004 Therefore, a data path encryption mechanism is considered optional and configurable based on security policy. STA authentication and security policy enforcement is done centrally in the AC. Over the air privacy and authentication between the STAs and APs is accomplished by standard 802.11 privacy methods. The RSN service is the recommended method for over the air privacy and authentication. (7) Pros and Cons of this architecture, esp. in relation to the four problems described in the CAPWAP problem statement. Please keep the analysis at technical instead of marketing level. Pros: - In this centralized architecture, the AC and AP can be separated by an arbitrary L3 cloud which in turn enables large geographic distribution of APs within the cloud. - This architecture is agnostic to the underlying wired medium connecting the AP and AC. - This architecture is agnostic to the AP MAC and radio technology. - Since the MAC is not split, this architecture supports a deployment where the data path is not required to travel through the AC. This may be useful in the "branch office" scenario where the AC may reside in a data center and the AP connects to it over a slow WAN link. However, the operational control and management of the AP is done by the AC. - The problems defined in draft-ietf-capwap-problem-statement-00.txt are also addressed by this architecture. Yang (Editor), et al. Expires December 28, 2004 [Page 71] Internet-Draft CAPWAP Arch. Taxonomy June 2004 Appendix J. Survey Contribution For Architecture 9 (1) Design considerations and requirements: please briefly describe your design principles for this architecture. The goals are 1. Simplify WLAN life-cycle management - including design, deployment, and management. 2. Similar user experience on WLAN and Ethernet - WLAN should provide same level of networking services as Ethernet. User should feel no difference when running application on wired V.S. wireless network. Also, network administrators should be able to manage WLAN the same way as managing wired network. In this architecture, AC performs WLAN configuration, monitoring, and policy management function. It controls and manages APs. AC also collects information from APs and, based on configuration, push down policies into individual APs. It also serves as proxy for interacting with all external networking components(e.g. RADIUS server). AP implement all the 802.11 access point function, including all the PLME, MLME, STA services, DS, and bridging functions. (2) WLAN functions supported: Please list the functions supported in this WLAN briefly, but please do not send us the entire data sheet. Examples of WLAN functions includes all the STA services, Distributed System Services (as defined by 802.11), radio resource management and control, load balancing, mobility support, WLAN network wide security functions (including authentication, encryption for privacy and integrity, etc.) and any others not listed here but deemed important in your design. All 802.11 AP functions are provided. That includes 1. Distribution System Services. 2. Radio resources management - channel selection, interference detection and avoidance, cell-size control. 3. Load balancing. 4. Security. Yang (Editor), et al. Expires December 28, 2004 [Page 72] Internet-Draft CAPWAP Arch. Taxonomy June 2004 5. Power save mode. 6. QoS. 7. Station services. 8. Bridging. Besides the list above, this WLAN system provides the following functions: 1. Rogue AP/Ad-hoc network detection and containment. 2. Location based authentication control. 3. Dynamic VLAN assignment based on authentication ID. 4. QoS 5. ACL 6. L2/L3. 7. Multiple VLAN per radio. 8. Multiple SSID per AP. 9. Dynamic 802.1p/q tag assignment based on user/location/ application. (3) The functional architecture to implement the functions described above: whether it is by autonomous AP architecture, or "split" architecture. For split architecture, please provide the functional mapping of WLAN functions onto the AP and AC -- with just enough details that help us understand the kinds of functional interface necessary between the two. This WLAN system is a split architecture system. AC includes the following functions: 1. Configuration interface. 2. Management. 3. Policy control. 4. L2/L3. Yang (Editor), et al. Expires December 28, 2004 [Page 73] Internet-Draft CAPWAP Arch. Taxonomy June 2004 5. Proxy RADIUS. 6. ACL. 7. AP/AC image and configuration management. 8. RF monitoring - correlation between APs. AP includes the following functions: 1. 802.11 MAC. 2. Multiple SSID 3. Power management. 4. RF monitoring - data collection. 5. 802.11 security - including WEP and 802.11i draft. 6. Integration service. 7. Location service. (4) The protocol used in between AP and AC. The following standard protocols are used: 1. Agent-X : control and management. 2. LLDP/EDP(Proprietary discovery protocol) : AP/AC discovery. 3. TFTP : image transfer from AC to AP. (5) The topological assumptions between AP and AC (is it directly connected, L2 switched, or L3 routed?) -- this also helps us to understand the deployment scenarios. The system supports L1(direct connect), L2, and L3 connection between AP and AC. (6) Security threat analysis: what kinds of threat introduced by the split architecture, and how that are addressed. 1. AP does not store runtime image and configuration. Both are pushed down from AC. AC takes full control over AP. 2. Control traffic between AP and AC can be encrypted using SSL. Yang (Editor), et al. Expires December 28, 2004 [Page 74] Internet-Draft CAPWAP Arch. Taxonomy June 2004 3. AP can be authenticated based on identity, that includes MAC, IP, serial number, or digital certificate. AC can be authenticated via X509 certificate. (7) Pros and Cons of this architecture, esp. in relation to the four problems described in the CAPWAP problem statement. Please keep the analysis at technical instead of marketing level. Instead of managing APs, this architecture allows user to deploy, control, and manage wireless networks. With distributed data forwarding, it maintains the scalability of the autonomous AP architecture. It also provides same networking services between Ethernet and Wireless network in Layer 2, Layer 3, and beyond. Yang (Editor), et al. Expires December 28, 2004 [Page 75] Internet-Draft CAPWAP Arch. Taxonomy June 2004 Appendix K. Survey Contribution For Architecture 10 (1) Design considerations and requirements: - Access Controller manages one or more Access Points. Access Controllers control and provision the various access points. - Access Controller and Access Points can reside in physically separated regions (across buildings/oceans). - Access Controller and Access Points communicate over a Secure Channel and provide facility for mutual authentication. - Roaming among Access Points within the domain of one Access Controller is possible without any new protocol support. All state information is maintained in Access Controller. - Bridging within a given SSID. Routing among different SSIDs. - If 802.1x/WEP security is employed, it is between wireless stations and AP. But AC maintains the keys. - AC supports L2TPoIPSEC, if one wants security between end station to the Corporate network. - Two sessions are maintained between AP and AC, which can be secured using IPsec. TCP based session is used to transfer control information such as provisioning of APs, events from APs. UDP session is used to transfer the data. (2) WLAN functions supported: - Radio Resource Management: Access Controllers can configure Access Points using the Control Channel. A Request-Response Protocol is used on the control channel. - DSS: The Access Point shall handle traffic between all stations associated with it. For traffic that is targeted to another AP, the traffic shall be sent to the Access Controller. The Access Controller shall bridge the traffic appropriately, across the appropriate bridge/bridge port. - 802.1x Functionality: Access Points shall encapsulate 802.1x frames to EAPOL frames and transmit to Access Controller. Access Controller is responsible for initiating Radius Authentication. - WEP Encryption/Decryption of data: Access Points shall handle encryption/decryption of data. The Access Controller will maintain Yang (Editor), et al. Expires December 28, 2004 [Page 76] Internet-Draft CAPWAP Arch. Taxonomy June 2004 and program the keys in AP. - Handle Roaming Clients: Access Point shall send events of Association/Dis-association/Re-association to Access Controller through Control Channel. Access Controller maintains session key information for every wireless access point association (802.1x), Hence when a roaming client moves from one AP to another AP, the Access Controller can push the session key information to the Access Point through the Control Channel. (3) The functional architecture to implement the functions described above: - Handled in AP: All Radio Functionality/WEP Encryption and Decryption; Traffic between Wireless Stations in the same BSS. - Handled in AC: Routing/Bridging to another BSS; Maintaining Session Keys for each wireless station (to support roaming), initiating Radius Authentication. - The Control Channel can be used to configure any parameter or read any MIB from the Access Point. (4) The protocol used in between AP and AC. - Control Channel: TCP Transport can be used for Control Frames. The Access Point establishes a TCP session with the Access Controller when it comes up. When the TCP connection is established the AC and AP authenticate each other. Upon successful authentication the Access Controller assigns a Unique ID for the AP. The control channel shall be used to exchange control information between AC and AP. Control Information is inclusive of image update, provisioning, reset, radio management and any MIBs that may be sent by Access Point to Access Controller. The AP shall send all 802.1x packets from End Wireless Station as EAPOL Packets through the Control Channel. The AC shall send the 802.1x responses as EAPOL Packets to the AP through the Control Channel. In addition AC can use the control channel to push session keys. The Access Point shall establish as many control channels as the number of radios it supports. For each control channel it establishes, the Access Controller shall assign a unique ID. This ID will be used in data channel communication between AC and AP. The communication between AP and AC shall be in the form of command and Response. The AC or AP shall send a command and the recipient of the command shall issue a response. This approach can be extended to Yang (Editor), et al. Expires December 28, 2004 [Page 77] Internet-Draft CAPWAP Arch. Taxonomy June 2004 any kind of deployment. (Dumb AP or fully functional AP). - Data Channel: The Data Frames can be transmitted using Mac Over UDP Encapsulation Mechanism. The MAC frames are encapsulated with UDP/IP headers at the transmitting end and de-capsulated at the receiving end. (5) The topological assumptions between AP and AC: L3 Routed (6) Security threat analysis: The AC and AP can mutually authenticate themselves through the control channel. Both Control and Data Channels are over Transport Layer. This enables the possible usage of IPsec, hence provides a secure channel for communication. Wireless Stations to AP communication can be secure through existing mechanisms such as 802.1x (7) Pros and Cons of this architecture, esp. in relation to the four problems described in the CAPWAP problem statement. Please keep the analysis at technical instead of marketing level. - The Control Channel provides a flexible/extensible method to support any type of Access Point; i.e. doing management at the Access Point itself and/or controlling the management from the Access Controller. Hence it can address different market segments. - The control channel on TCP allows for easy adoption of IPsec and hence addresses the security issues over an otherwise insecure channel. Yang (Editor), et al. Expires December 28, 2004 [Page 78] Internet-Draft CAPWAP Arch. Taxonomy June 2004 Appendix L. Survey Contribution For Architecture 11 (1) Design considerations and requirements: please briefly describe your design principles for this architecture. DIRAC is designed to enable efficient implementation of many emerging wireless services implemented on the access router. These services will be highly adaptive along the following three dimensions: a) adaptation to wireless channel dynamics: several services (e.g., schedulers) require knowledge on the channel dynamics (current rate, error pattern) and link quality perceived by each mobile host. b) adaptation to host mobility: information on host mobility from one cell to a neighboring one is required by micro-mobility management protocols (e.g., Fast Handovers) c) coordinated adaptation across multiple cells: applications such as VoIP, admission control, fast handoffs require coordination among multiple cells and resource management. DIRAC also enables coordination spanning multiple layers in the protocol stack, and across multiple geographically adjacent cells. In the PHY layer, RF management and collaborative power control over multiple neighboring cells can minimize interferences, load balancing and MAC filtering in the link-layer can increase performance and security, while fast handover at the network-layer can minimize transient packet loss. Instead of designing fully distributed coordination protocols, a centralized router assisted by router agents can serve this purpose, while simplifying the design approach and minimizing management overhead at the same time. Another design consideration for DIRAC is the separation of protocols among the physical entities of the network. DIRAC adopts a generic design at the access router, while leaving technology-specific functions to the router agent at the AP. This decision leads to a lean design, non-intrusive to the IP protocol, and readily extensible to other wireless network access technologies such as Bluetooth, 3G/ 4G, 802.11n. Specifically, the access router remains unaware of the specifics of the wireless Link-layer/MAC currently used (802.11b) and does not directly handle/process link layer-specific frames. Instead, the latter is taken care of by the AP. Finally, another requirement for the architecture was to be economically cost effective along the following dimensions: a) complexity of implementation, b) cost of deployment, and c) cost of management/operational expenses (OpEx). These requirements lead to a centralized design for the access router, supported by a number of Yang (Editor), et al. Expires December 28, 2004 [Page 79] Internet-Draft CAPWAP Arch. Taxonomy June 2004 lightweight, software agents that run at each access point, monitor the wireless cell, and expose link-layer mechanisms to higher layers, in order to enforce system-wide policies. (2) WLAN functions supported: Please list the functions supported in this WLAN briefly, but please do not send us the entire data sheet. Examples of WLAN functions includes all the STA services, Distributed System Services (as defined by 802.11), radio resource management and control, load balancing, mobility support, WLAN network wide security functions (including authentication, encryption for privacy and integrity, etc.) and any others not listed here but deemed important in your design. DIRAC aims to provide the necessary hooks and systems framework for easily enabling as many new wireless services as possible on the access router. To this end, the following WLAN functions are implemented by the system: a) STA services: Authentication, De-authentication, MSDU delivery b) Distribution System Services: Association, Disassociation, Distribution, Integration, Reassociation c) L2 Mobility Support (link-layer handoff) d) L3 Mobility Support (network-layer fast Handoff integrated with Mobile IPv6) e) IP-layer, packet-level, Forward Error Correction and Deficit Round Robin scheduling that addresses the Head-of-Line blocking problem f) Policing of aggressive flows through MAC-layer (802.11b) filtering g) Multi-layer firewalls h) Channel statistics for STAs centrally collected i) Registration of APs to AR (3) The functional architecture to implement the functions described above: whether it is by autonomous AP architecture, or "split" architecture. For split architecture, please provide the functional mapping of WLAN functions onto the AP and AC -- with just enough details that help us understand the kinds of functional interface necessary between the two. The architecture followed by DIRAC can be described as "split", Yang (Editor), et al. Expires December 28, 2004 [Page 80] Internet-Draft CAPWAP Arch. Taxonomy June 2004 although this description is irrelevant to the 802.11 MAC; the latter is implemented fully at the AP, while its management and monitoring functionality is _exposed_ to (and controlled by) the access router. The Access Router runs a link-layer specific software agent on the AP, instead of having part of the MAC implemented at the AR. In that sense, the mapping between the WLAN functions described above is as follows: AP : (a), (b), (c) AC : (d), (e), (f), (g), (h) The interface exposed (and further implemented by the AR-AP communication protocol) revolves around three types of information: a) Events: occurrence of asynchronous link-layer activity in the cell, detected by the access point and reported back to the access router control engine. Examples are: new host (association), host leaves (disassociation), security binding (authentication), roaming host (reassociation), dead cell detection (heartbeat). b) Statistics: latest information on channel quality that each host perceives, which is location-dependent. Examples of channel statistics are: signal-noise ration (dB), frame retransmits (frame loss %), CommTallies (detailed statistics), channel quality variation (transmission rates), etc. c) Actions: mechanisms that are exposed and made available by the APs and can be used by the access router, in order to enforce its policies. Examples include tuning of the 802.11b MAC protocol parameters (e.g., deauthenticate a client for security reasons), configuration settings of the driver (e.g., enter power saving mode, set number of retransmissions), PHY setting (e.g., adjustment of the transmission power), configuring the AP device itself (e.g., re-flash the image of the driver/device). In essence, an "action" is whatever aspect that can be thought of as a mechanism provided by the AP and can be controlled through some policy specified by the access router. (4) The protocol used in between AP and AC. The protocol used between the Access Router and the Access Points in DIRAC follows a basic TLV (Type-Length-Value with an addition of a Subtype) format, and its purpose is to deliver messages carrying information about events/statistics/actions as described in the previous section (3). This protocol runs over UDP. (5) The topological assumptions between AP and AC (is it directly Yang (Editor), et al. Expires December 28, 2004 [Page 81] Internet-Draft CAPWAP Arch. Taxonomy June 2004 connected, L2 switched, or L3 routed?) -- this also helps us to understand the deployment scenarios. The access point is IP-addressable therefore it is in principle accessible over any L2-switched, or L3-routed "cloud". However, for the purpose of delivering meaningful per-host statistics over fine-time scales to capture long-term fading, and channel coherence time of the wireless medium, the "cloud" that connects the Access Points with the Access Router should have latency that is small enough to deliver statistics reports in a timely fashion. Therefore, either a direct connection, or a L2-switched "cloud" between the access point and the access router is recommended. (6) Security threat analysis: what kinds of threat introduced by the split architecture, and how that are addressed. Possible threats: a) Threats TO the DIRAC architecture: i) protect the messages that deliver events/actions/statistics ii) authentication of APs to the AR (rogue APs) iii) Man-in-the-middle attack between APs --AR regarding control-traffic b) Threats TO the wireless traffic i) Mismatching levels of security strengths between STA--AP and AP--ARs ii) Denial-of-Service attacks (layer-2 and layer-3) in the wireless cell (protecting STAs from misbehaving wireless hosts) iii) Well-documented deficiencies of the 802.11 WEP (over the air protection) iv) Access control Threats (a).(i) and (a).(iii) can be addressed through encryption/ tunneling of management messages. Threat (a).(ii) requires mutual authentication between AR and APs Threat (b).(ii) is addressed by the policing service implemented at the AR and enforced through L2 mechanisms at the AP. (b).(iii) requires additional authentication (ex. RADIUS) and end-to-end encryption, on top of WEP. (b).(iv) can be implemented both by Yang (Editor), et al. Expires December 28, 2004 [Page 82] Internet-Draft CAPWAP Arch. Taxonomy June 2004 access lists at the AR and MAC filtering at the AP. (7) Pros and Cons of this architecture, esp. in relation to the four problems described in the CAPWAP problem statement. Please keep the analysis at technical instead of marketing level. Management, Monitoring and Control (1st problem), Consistent (network-wide) configuration (2nd problem), and RF Management (3rd problem) are addressed by the fact that policies are centralized on the AR, while mechanisms for enforcing them are distributed among all APs. Security, and in particular rogue APs, can be addressed (although not currently implemented on DIRAC) through mutual authentication of the APs to the AR and vice-versa. Yang (Editor), et al. Expires December 28, 2004 [Page 83] Internet-Draft CAPWAP Arch. Taxonomy June 2004 Appendix M. Survey Contribution For Architecture 12 (1) Design considerations and requirements: The access controller (AC) is a bridge. Multiple access points are aggregated by a bridge that supports a MAC-layer security protocol between itself and an 802.11 end station. The same MAC-layer security protocol is used between bridges on a wired LAN and between a bridge and an 802.11 end station. The security protocol is a service that sits above the MAC and makes 802.11i MAC security encapsulation unnecessary. Contrast this with the situation in the near future where 802.11i will secure the link between an end station and an AP, and 802.1ae might secure the link between the AP and a bridge. To the extent that an AP can be architected as a bridge, AP management falls within the scope of bridge management and is handled within the 802.1 control layer along with existing bridge management protocols such as 802.1AB link-layer connectivity and 802.1af discovery of bridges that support MAC-layer security. These 802.1 protocols are broad enough in scope to meet the requirements of the 802.11 mesh networking PAR. No 802.11 frames of any type are recognized by an AC. (2) WLAN functions supported: An AC never routes packets. It only bridges them except when reverse tunneling is required. An AC supports layer-3 mobility for a station that is associated with an AP attached to it, by reverse tunneling Ethernet from the station to an AC on that station's home subnet. The roaming station retains the same IP address and the limited broadcast domain of its home subnet regardless of AP association as long as the AP is within the same ESS. Therefore, no AC operations are required for a BSS transition unless that transition is to another subnet or ESS. Every handoff between access controllers is authenticated using state derived from an initial mutual authentication. No AC ever bridges, or reverse tunnels, any traffic from a station unless the user of that station can be authenticated. Re-authentication does not require user involvement. The MAC-layer security protocol provides privacy, integrity and replay protection of Ethernet frames between a bridge and an end station, or between two bridges. (3) Functional architecture: autonomous AP. Yang (Editor), et al. Expires December 28, 2004 [Page 84] Internet-Draft CAPWAP Arch. Taxonomy June 2004 (4) The protocol used in between AP and AC. none. (5) The topological assumptions between AP and AC. L2 switched. (6) Security threat analysis: what kinds of threat introduced by the split architecture, and how that (sic) are addressed. The architecture is NOT split, nor is it advantageous to do so. (7) Pros and Cons of this architecture, esp. in relation to the four problems described in the CAPWAP problem statement. Please keep the analysis at technical instead of marketing level. It is difficult to keep the "analysis" technical when the first and third "problems" of the four stated in draft-ietf-capwap-problem-statement-00.txt are expressed in subjective terms, specifically, "burden" and "difficulty in dealing effectively". These are indeed at a marketing level. Therefore, one cannot objectively comment or provide "analysis". Further, the second and fourth "problems" presume a particular AP architecture that stores dynamic attributes, namely "embedded secrets" and "security parameters". So the "problems", except for dynamic provisioning of RF, are actually threats that arise due to a particular choice of architecture, one that stores sensitive information in an AP. With the architecture above, an AP does not store secrets and therefore AP theft is not a security threat. Installation of unauthorized access points is a threat if they cannot be aggregated by an AC, otherwise it doesn't matter because the AC ultimately controls access to the LAN. Further, a station will not connect to an AC that it cannot authenticate. Therefore an intruder is prevented from masquerading as an authorized AP and creating a MAC-layer security association with an end station. An unauthorized AP that is not attached directly or indirectly to an AC is a threat to LAN access but not to an end station. Yang (Editor), et al. Expires December 28, 2004 [Page 85] Internet-Draft CAPWAP Arch. Taxonomy June 2004 Appendix N. Survey Contribution For Architecture 13 (1) Design considerations and requirements: The Mesh architecture allows each AP to autonomously keep status of the pertinent information of the other APs, especially as it relates to back-hauling traffic between APs. Each AP may assume the role of providing access both to stations or to other APs for back-hauling traffic. This way we have an OSPF-like system of weighing paths through the network for load-balancing and fault-tolerance. The only requirement is IP connectivity between APs. (2) WLAN functions supported: Please list the functions supported in this WLAN briefly, but please do not send us the entire data sheet. Examples of WLAN functions includes the STA services, Distributed System Services (as defined by 802.11), radio resource management and control, AP load balancing, mobility support, WLAN network wide security functions (including authentication, encryption for privacy and integrity, etc.) and any others not listed here but deemed important in your design. Yes to all of the above through much the same functions as the others. 802.1x, AES, WPA, TKIP, EAP-blah, blah, blah. Other than load balancing and dynamic radio resource management, I don't think much else matters in terms of our work. (3) The functional architecture to implement the functions described above: whether it is by autonomous AP architecture, or "split" architecture. For split architecture, please provide the functional mapping of WLAN functions onto the AP and AC -- with just enough details that help us understand the kinds of functional interface necessary between the two. See my answer to 4. The functional relationship between Mesh nodes is that they keep each other synced up with their resources and capabilities. They also keep each other in sync with the state of the whole network which allows each AP to make intelligent choices of where to back-haul traffic to. (4) The protocol used in between AP and AC. (What is an AP and AC? I don't think we've defined those in the terms that we will ultimately use. So I'll leave that one for now. (5) The topological assumptions between AP and AC (is it directly connected, L2 switched, or L3 routed?) -- this also helps us to understand the deployment scenarios. Yang (Editor), et al. Expires December 28, 2004 [Page 86] Internet-Draft CAPWAP Arch. Taxonomy June 2004 APs are connected Wired or wireless using L2 802.11 (6) Security threat analysis: what kinds of threat introduced by the split architecture, and how that are addressed. We encrypt automatically each link using AES and 152-bit key with KM. (7) Pros and Cons of this architecture, esp. in relation to the four problems described in the CAPWAP problem statement. Please keep the analysis at technical instead of marketing level. Problem 1. Since each node is fully aware of the network, you don't need to manage each node. Just one will do and it can update the entire network. That's one of the main values of Mesh. Problem 2. Kind of the same answer as above. By using multicast IP protocols to keep everything in sync, we don't run into the problems mentioned in 2. Problem 3. Mesh really solves this one quite well, again by keeping everyone in sync and using multicast IP. Problem 4. By declaring a Cloud entity consisting of multiple wired or wirelessly connected APs, complete with full security, only legitimate APs are admitted to the network. Rogues cannot participate and may be hunted down using radio techniques. Yang (Editor), et al. Expires December 28, 2004 [Page 87] Internet-Draft CAPWAP Arch. Taxonomy June 2004 Appendix O. Survey Contribution For Architecture 14 This architecture requires a control channel between wireless access points and a logical wireless switch device to exchange configuration, radio control, status and certain 802.11 specific messages. As explained below the logical wireless switch functionality may optionally be distributed between more than one physical device by separating certain logical functions. Topological requirements 1. The AP and the AC are IP hosts that may be separated by L2 and/or L3 devices. They are not required to either be directly attached or in the same Layer-2 broadcast domain. 2. There must be IP-connectivity between the AP and the AC. Transport attributes: 1. The control channel is an IP connection that may use UDP or TCP transport mechanisms. 2. Some control channel attributes may be statically configured. In particular, encryption and/or authentication may be enabled on the channel. 3. The channel carries messages that may be categorized by various functions such as provisioning, monitoring, radio management and mobile node registration. These may be multiplexed over the same channel by the use of TLVs/opcodes or distributed over multiple IP connections. The first option allows co-locating all wireless switch functionality in the same device while the latter allows for switch entity be hosted on different devices each performing a different set of functions. 4. APs initiate connection to the AC on a well-known UDP or TCP port. Discovery of the AC may be via manual configuration on the AP or through initial DHCP signaling exchange between the AP and a DHCP server. Contents of Protocol: 1) APs discover the AC and initiate a UDP or TCP connection. 2) The AP and the AC perform mutual authentication using EAP. 3) The AP and the AC optionally negotiate security association for securing the channel. Yang (Editor), et al. Expires December 28, 2004 [Page 88] Internet-Draft CAPWAP Arch. Taxonomy June 2004 4) The AP is initially provisioned by the AC via a central configuration database. 4) The AC does .11/.1X authentication mediation when the AP authenticates mobile nodes. Inserting the AC between the AP and the authentication server can be used for maintaining a central database of mobile nodes. 4) Radio reports are sent from the AP to the AC as necessary. 5) Radio control messages are sent from the AC to the AP asynchronously. Yang (Editor), et al. Expires December 28, 2004 [Page 89] Internet-Draft CAPWAP Arch. Taxonomy June 2004 Appendix P. Survey Contribution For Architecture 15 (1) Design considerations and requirements: please briefly describe your design principles for this architecture. Ans: The architecture is to offer a WLAN mesh infrastructure-based ESS with a self-configurable network and adaptive topology. The access service can be easily set up and flexibly adjusted to reflect the need. It can also be used to extend wireless service at places that Ethernet wiring is difficult due to either cost or physical limitation. (2) WLAN functions supported: Please list the functions supported in this WLAN briefly, but please do not send us the entire data sheet. Examples of WLAN functions includes the STA services, Distributed System Services (as defined by 802.11), radio resource management and control, AP load balancing, mobility support, WLAN network wide security functions (including authentication, encryption for privacy and integrity, etc.) and any others not listed here but deemed important in your design. Ans: The STA access service to a WLAN mesh node is fully compliant with IEEE 802.11. Its transit services will be compliant with those specified in the emerging IEEE 802.11 Task Group S. (3) The functional architecture to implement the functions described above: whether it is by autonomous AP architecture, or "split" architecture. For split architecture, please provide the functional mapping of WLAN functions onto the AP and AC -- with just enough details that help us understand the kinds of functional interface necessary between the two. For distributed architectures, describe how the functionality is distributed across the nodes in the network. Ans: A mesh node within an ESS mesh network can be an autonomous device that acts as an AP to its local stations and as a traffic relay to neighboring mesh nodes. In this distributed architecture, each mesh node is expected to fully aware of the network topology of the ESS mesh network through topology information exchanged with its neighboring nodes. Alternatively, the split architecture can be applied to a WLAN mesh network. The mesh nodes can leave certain functions (such as user authentication) to a centralized AC in the wired network. Or, set of passive nodes (APs) can satellite around an active/intelligent node (AC). Network topology information is exchanged only among the active nodes. User access management can be decided either at the associated Yang (Editor), et al. Expires December 28, 2004 [Page 90] Internet-Draft CAPWAP Arch. Taxonomy June 2004 (autonomous or active) mesh node or at a centralized entity. (4) The protocol used in between AP and AC, for split architecture; or the protocol used between mesh nodes, for distributed architecture. Ans: A proprietary protocol between AP and AC. Another proprietary protocol between Mesh APs. (5) The topological assumptions between the network entities (is it directly connected, L2 switched, or L3 routed?) -- this also helps us to understand the deployment scenarios. Ans: The ESS mesh is a L2 access network. The management communication can be either L2 or L3 based. (6) Security threat analysis: what kinds of threat introduced by the architecture, and how that are addressed. Ans: Mesh nodes must authenticate each other and to secure the data transmission among neighboring nodes. Other than this consideration, the wireless mesh network has the similar security concern as other wireless access network. (7) Pros and Cons of this architecture, esp. in relation to the four problems described in the CAPWAP problem statement. Please keep the analysis at technical instead of marketing level. Ans: Management requirement: Mesh APs are self-configurable. They can form neighboring links and the forwarding Topology dynamically and automatically. The optional centralized control can be used to monitor the network at real time. Consistent configuration: Each Mesh AP node can learn the configuration from two sourcs: either from the network (via neighboring nodes) or from the centralized control. Dynamic media: A mesh network is designed to reflect the dynamic nature of a wireless access network. Its topology can be dynamically formed to reflect the radio situation. A centralized coordination is also possible in the described architecture. Securing Access: See the answer for (6). Yang (Editor), et al. Expires December 28, 2004 [Page 91] Internet-Draft CAPWAP Arch. Taxonomy June 2004 Appendix Q. Survey Contribution For Architecture 16 (1) Design considerations and requirements: please briefly describe your design principles for this architecture. Response: The design principles for Nortel's Wireless Mesh Network product are as follows: - enables WLAN deployment and simplified coverage for open areas both indoor and outdoor, - brings "hotspots" together into a Community Area Network (CAN) providing larger coverage area and mobility, -eliminates the need for extensive Ethernet cabling or leased lines through use of wireless links between access points in a mesh configuration, - provides auto-configuration and centralized management capabilities to simplify network operations, - avoids service outages by providing efficient routing using auto-discovery and self-healing algorithms, - provides a highly secure environment for both end users and the network, - scaleable architecture from small enterprise to a large community network, - compliant to existing 802.11 standard protocols and interfaces to ensure universal 802.11 client access, -conformance to FCC requirements on 802.11 indoor and outdoor deployment. (2) WLAN functions supported: Please list the functions supported in this WLAN briefly, but please do not send us the entire data sheet. Examples of WLAN functions includes the STA services, Distributed System Services (as defined by 802.11), radio resource management and control, AP load balancing, mobility support, WLAN network wide security functions (including authentication, encryption for privacy and integrity, etc.) and any others not listed here but deemed important in your design. Response: Supported WLAN functions are: - the STA services open system authentication WPA with TTLS and PEAP support web portal redirect deauthentication Yang (Editor), et al. Expires December 28, 2004 [Page 92] Internet-Draft CAPWAP Arch. Taxonomy June 2004 - the Distribution System Services (as defined by 802.11) association disassociation distribution and integration services reassociation - mobility support Session persistent Corporate VPN access - WLAN network wide security functions (authentication, encryption for privacy and integrity etc.) fully WPA compliant (3) The functional architecture to implement the functions described above: whether it is by autonomous AP architecture, or "split" architecture. For split architecture, please provide the functional mapping of WLAN functions onto the AP and AC -- with just enough details that help us understand the kinds of functional interface necessary between the two. For distributed architectures, describe how the functionality is distributed across the nodes in the network. Response: - fully autonomous AP architecture (4) The protocol used in between AP and AC, for split architecture; or the protocol used between mesh nodes, for distributed architecture. Response: - does not apply (5) The topological assumptions between AP and AC (is it directly connected, L2 switched, or L3 routed?) -- this also helps us to understand the deployment scenarios. Response: - does not apply (6) Security threat analysis: what kinds of threat introduced by the split architecture, and how that are addressed. Response: - does not apply (7) Pros and Cons of this architecture, esp. in relation to the four problems described in the CAPWAP problem statement. Please keep the analysis at technical instead of marketing level. When referring to the four problems described in CAPWAP, the pros and cons design considerations are as follows: CAPWAP Problem Statement#1: The first problem introduced by large WLAN deployments is that each AP is an IP-addressable device requiring management, monitoring, and control. Response: The advantage of Nortel's architecture over legacy IP network infrastructure deployment is avoiding global IP addressing. Yang (Editor), et al. Expires December 28, 2004 [Page 93] Internet-Draft CAPWAP Arch. Taxonomy June 2004 This is supported by Intranet and Extranet private IP addressing across system components and users access through the DHCP server. This eliminates the need for global IP addressing for system administration. CAPWAP Problem Statement#2: A second problem introduced by large WLAN deployments is distributing and maintaining a consistent configuration throughout the entire set of access points in the WLAN. Access point configuration consists of both long-term static information, such as addressing and hardware settings, and more dynamic provisioning information, such as individual WLAN settings and security parameters. Large WLAN installations that need to update dyanmic provisioning information in all the APs in the WLAN require a prolonged phase-over time, while each AP is updated and the WLAN does not have a single, consistent, configuration. Response: The basic design requirement is to support in-service upgrade with downloadable configuration capabilities. CAPWAP Problem Statement#3: A third problem introduced by large WLAN deployments is the difficulty in dealing effectively with the dynamic nature of the WLAN medium, itself. Due to the shared nature of the wireless medium, shared with APs in the same WLAN, with APs in other WLANs, and with devices that are not APs at all, parameters controlling the wireless medium on each AP must be monitored frequently and modified in a coordinated fashion to maximize performance for the WLAN to utilize the wireless medium efficiently. This must be coordinated among all the access points, to minimize the interference of one access point with its neighbors. Manually monitoring these metrics and determining a new, optimum configuration for the parameters related to the wireless medium is a task that takes a significant amount of time and effort. Response: Nortel's implementation includes automated configuration and centralized management capabilities to simplify network operations. In addition auto-discovery and self-healing algorithms are used. CAPWAP Problem Statement#4: A fourth problem introduced by large WLAN deployments is securing access to the network and preventing installation of unauthorized access points. Access points are often difficult to physically secure, since their location must often be outside of a locked network closet or server room. Theft of an access point, with its embedded secrets, allows the thief to obtain access to the resources secured by those secrets. Recently, multiple vendors have begun offering proprietary solutions Calhoun, et al. Response: Nortel's solution provides a highly secure environment for Yang (Editor), et al. Expires December 28, 2004 [Page 94] Internet-Draft CAPWAP Arch. Taxonomy June 2004 both end users and the network including safe-guards against access and misuse of embedded information. Mechanisms include WPA-equivalent authorization, key management, automatic key refresh and encryption to protect user, control and management data. Techniques are embedded in the auto-discovery algorithm to prevent rogue AP intrusions to the NW. Yang (Editor), et al. Expires December 28, 2004 [Page 95] Internet-Draft CAPWAP Arch. Taxonomy June 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Yang (Editor), et al. Expires December 28, 2004 [Page 96]