RFC 4118
Architecture Taxonomy for Control and Provisioning of Wireless Access Points (CAPWAP)
RFC 4118 💖 (Part 1 of 9)
RFC 4118 is titled "Architecture Taxonomy for Control and Provisioning of Wireless Access Points (CAPWAP)" 🎀 It was written by L. Yang (Intel Corp.), P. Zerfos (UCLA), and E. Sadot (Avaya), and it came out of the Network Working Group in June 2005. It's an Informational doc, not a standard. It also has no Obsoletes or Updates line in its header, so it doesn't replace or update any other RFC ✨
Status of This Memo 📜
okay so this memo is info for the Internet community. it does not specify an Internet standard of any kind, so don't go treating it like one 🙈 distribution of this memo is totally unlimited, so share away 🦋
Copyright Notice ©️
Copyright (C) The Internet Society (2005).
Abstract 🌸
this doc gives a taxonomy (basically a sorted map of the different designs) of the architectures that show up in existing IEEE 802.11 products on the market. it does this by looking at Wireless LAN (WLAN) functions and services, then describing the different ways vendors split those functions and services across the architectural entities. it's giving organized chaos, and we love to see it 💅
Table of Contents 🗂️
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. IEEE 802.11 WLAN Functions . . . . . . . . . . . . . . 3
1.2. CAPWAP Functions . . . . . . . . . . . . . . . . . . . 5
1.3. WLAN Architecture Proliferation . . . . . . . . . . . 6
1.4. Taxonomy Methodology and Document Organization . . . . 8
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 9
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. IEEE 802.11 Definitions . . . . . . . . . . . . . . . 9
3.2. Terminology Used in This Document . . . . . . . . . . 11
3.3. Terminology Used Historically but Not Recommended . . 13
4. Autonomous Architecture . . . . . . . . . . . . . . . . . . 13
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 13
4.2. Security . . . . . . . . . . . . . . . . . . . . . . . 14
5. Centralized WLAN Architecture . . . . . . . . . . . . . . . 15
5.1. Interconnection between WTPs and ACs . . . . . . . . . 16
5.2. Overview of Three Centralized WLAN Architecture
Variants . . . . . . . . . . . . . . . . . . . . . . . 17
5.3. Local MAC . . . . . . . . . . . . . . . . . . . . . . 19
5.4. Split MAC . . . . . . . . . . . . . . . . . . . . . . 22
5.5. Remote MAC . . . . . . . . . . . . . . . . . . . . . . 27
5.6. Comparisons of Local MAC, Split MAC, and Remote MAC. . 27
5.7. Communication Interface between WTPs and ACs . . . . . 29
5.8. Security . . . . . . . . . . . . . . . . . . . . . . . 29
5.8.1. Client Data Security . . . . . . . . . . . . . 30
5.8.2. Security of Control Channel between
the WTP and AC . . . . . . . . . . . . . . . . 30
5.8.3. Physical Security of WTPs and ACs . . . . . . 31
6. Distributed Mesh Architecture . . . . . . . . . . . . . . . 32
6.1. Common Characteristics . . . . . . . . . . . . . . . . 32
6.2. Security . . . . . . . . . . . . . . . . . . . . . . . 33
7. Summary and Conclusions . . . . . . . . . . . . . . . . . . 33
8. Security Considerations . . . . . . . . . . . . . . . . . . 36
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37
10. Normative References . . . . . . . . . . . . . . . . . . . . 391. Introduction 🚀
okay so IEEE 802.11 Wireless LAN (WLAN) tech is maturing, and rolling it out at large scale is starting to expose some real challenges 😭 as [2] lays out, managing, monitoring, and controlling a huge number of Access Points (APs) can be a seriously heavy load for network admins. keeping one consistent config across every single AP in the WLAN is also a lot. and the wireless medium is shared and dynamic, so the APs need solid coordination to cut down on radio interference and keep performance up. network security has always been a worry in WLANs, and it gets even more intense in big deployments and new architectures 💀
lowkey the vendors have already started offering partly proprietary solutions for some or all of these problems. but interoperable systems give people a wider choice of solutions, so a standardized, interoperable answer to these problems is super desirable 🫶 as a first step toward interoperability in the marketplace, this document gives a taxonomy of the architectures used in existing WLAN products. the goal is a cohesive understanding of market practice for the standards bodies involved (including the IETF and IEEE 802.11) ✨ the IEEE 802.11 Working Group may review and use this doc as input when defining the functional architecture of an AP 👑
1.1. IEEE 802.11 WLAN Functions 📡
the IEEE 802.11 specs are wireless standards that define an "over-the-air" interface between a wireless client Station (STA) and an Access Point (AP), and also between wireless clients themselves. 802.11 also describes how mobile devices can associate into a basic service set (BSS). a BSS is identified by a basic service set identifier (BSSID) or name 🦋 the WLAN architecture can be thought of as a kind of "cell" architecture, where each cell is a Basic Service Set (BSS) and each BSS is controlled by an AP. when two or more APs connect over a broadcast layer 2 network and they're all using the same SSID, you get an extended service set (ESS) 🌈
the architectural piece used to interconnect BSSs is the distribution system (DS). an AP is an STA that gives access to the DS by providing DS services, and it still acts as an STA too, so it's doing double duty 💅 another logical piece, the portal, shows up to fuse the IEEE 802.11 architecture with a traditional wired LAN. one device can offer the functions of both an AP and a portal, and that's totally a thing 🧚
IEEE 802.11 doesn't spell out the details of DS implementations explicitly 🙈 instead, the 802.11 standard defines services that provide the functions the LLC layer needs for sending MAC Service Data Units (MSDUs) between two entities on the network. these services fall into two categories: the station service (SS) and the distribution system service (DSS). both categories are used by the IEEE 802.11 MAC sublayer. the station services are these four:
- Authentication: Establishes the identity of one station as a member of the set of stations that are authorized to associate with one another.
- De-authentication: Voids an existing authentication relationship.
- Confidentiality: Prevents the content of messages from being read by others than the intended recipients.
- MSDU Delivery: Delivers the MAC service data unit (MSDU) for the stations.
the distribution system services come next, and there are five of them 🍓
- Association: Establishes Access Point/Station (AP/STA) mapping and enables STA invocation of the distribution system services.
- Disassociation: Removes an existing association.
- Reassociation: Enables an established association (between AP and STA) to be transferred from one AP to another or the same AP.
- Distribution: 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.
- Integration: Translates the MSDU received from the Distribution System to a 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'.
⚠️ the Integration bit is important: any MSDU coming in from the DS hits the 'Integration' services of the DSS before the 'Distribution' services get invoked. order matters, bestie 🙈
besides these services, IEEE 802.11 also defines extra MAC services that the APs in the WLAN must implement. for example:
- Beacon Generation
- Probe Response/Transmission
- Processing of Control Frames: RTS/CTS/ACK/PS-Poll/CF-End/CF-ACK
- Synchronization
- Retransmissions
- Transmission Rate Adaptation
- Privacy: 802.11 Encryption/Decryption
on top of what 802.11 already offers, the IEEE 802.11 WG is also working on a bunch of other stuff: Quality of Service (802.11e), Security Algorithms (802.11i), the Inter-AP Protocol (IAPP, or 802.11F -- recommended practice) to update APs when a STA roams from one BSS to another, Radio Resource Measurement Enhancements (802.11k), and more 🔥
IEEE 802.11 doesn't say exactly how these functions get implemented, and it doesn't require them to live in one physical device either 🦋 it only requires that the APs and the rest of the DS together implement all these services. vendors usually build not just the services in the 802.11 standard but also a pile of value-added features, like load balancing, QoS, station mobility support, and rogue AP detection 💖 what becomes clear from this doc is that vendors really take advantage of the flexibility in the 802.11 architecture, and they've come up with lots of different flavors of architectures and WLAN service implementations. it's giving main character energy 👑
because a lot of vendors spread these WLAN services across multiple network elements, we want to make a clear split between the logical WLAN access network functions and the individual physical devices, so we're using different terminology for each. we use "AP" for the logical entity that provides access to the distribution services, and "WTP" (Wireless Termination Point) for the physical device that lets the RF antenna and 802.11 PHY transmit and receive station traffic in the BSS network 🌸 in the Centralized Architecture (see section 5), a WTP combined with an Access Controller (AC) implements all the logical functions. each of those physical devices (WTP or AC) might only implement part of the logical functions. but the DS, counting all the physical devices together, implements all or most of the functions 🫶
okay bestie, part 1 is wrapped 🌈 more parts are coming, so stay tuned 💜
1.2. CAPWAP Functions ✨
okay so the survey folks spotted four big problems in [2] (management, consistent configuration, RF control, and security) 😭 to fix them, vendors usually add extra functions, especially in the control and management plane, to help coordinate everything across the whole ESS network 🎀 these matter SO much when the IEEE 802.11 WLAN functions are spread across multiple entities in a big network instead of living inside one box 💅 the main ones are:
- RF monitoring, like Radar detection, noise and interference detection, and measurement 📡
- RF configuration, e.g., for retransmission, channel selection, transmission power adjustment ⚡
- WTP configuration, e.g., for SSID 🏷️
- WTP firmware loading, e.g., automatic loading and upgrading of WTP firmware for network wide consistency 🔄
- Network-wide STA state information database, including the information needed to support value-added services, such as mobility and load balancing 🗂️
- Mutual authentication between network entities, e.g., for AC and WTP authentication in a Centralized WLAN Architecture 🔐
these services are basically about three things. first, controlling the radio resource ('RF Monitoring' and 'RF Configuration') 📻. second, managing and configuring the WTP device ('WTP Configuration', 'WTP Firmware upgrade') 🛠️. third, security when a WTP registers with an AC ('AC/WTP mutual authentication') 🛡️. and then there's the device that other services, like mobility management across subnets and load balancing, can check to get state info about the STA(s) connected to the wireless network ('STA state info database') 👀 it's giving organized, honestly 🫶
the list above is NOT a complete list of every extra service vendors offer 🙈 we only included the ones that show up a lot in the survey data and that actually matter for understanding the big problem, which is interoperability 🦋
most of these functions aren't explicitly specified by IEEE 802.11, but a few are 🌸 for example, the control and management of the AP's radio-related functions are described implicitly in the MIB, like:
- Channel Assignment
- Transmit Power Control
- Radio Resource Measurement (work is currently under way in IEEE 802.11k) 🧚
the 802.11h [5] amendment to the base 802.11 standard specifies how a MAC management protocol works to meet some regulatory requirements (mostly in Europe, but spreading to other places) in these areas:
- RADAR detection 📡
- Transmit Power Control ⚡
- Dynamic Channel Selection 🌈
1.3. WLAN Architecture Proliferation 🌍
this document gives a taxonomy (basically a sorted-into-categories guide 🍓) of the WLAN network architectures that vendors came up with to try to solve some or all of the problems from [2]. the IEEE 802.11 standard purposely doesn't get into the details of DS implementations, so different architectures popped up all over the market 💅 even though they all conform to the IEEE 802.11 standard as a whole, their individual functional components aren't standardized, so no drama there but also… lowkey messy 😭
the interfaces between the network architecture components are mostly proprietary. there's NO guarantee that products work together across vendors, even inside the same architecture family 💀
so the IETF CAPWAP working group is first documenting both the functions and the network architectures that existing WLAN vendors currently offer, to get interoperability going in the market 👑 the end result is this taxonomy document ✨
after analyzing more than a dozen different vendors' architectures, we think the existing 802.11 WLAN access network architectures can be broadly sorted into three distinct families. the sorting is based on the characteristics of the Distribution Systems used to provide the 802.11 functions 🎀
- Autonomous WLAN Architecture: The first architecture family is the traditional autonomous WLAN architecture, in which each WTP is a single 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 no explicit 802.11 support is needed from devices other than the WTP. In such architecture, the WTP is typically configured and controlled individually, and can be monitored and managed via typical network management protocols like SNMP. The WTPs are the traditional APs with which most people are familiar. Such WTPs are sometimes referred to as "Fat APs" or "Standalone APs". 🦋
- Centralized WLAN Architecture: The second WLAN architecture family is an emerging hierarchical architecture utilizing one or more centralized controllers for managing a large number of WTP devices. The centralized controller is commonly referred to as an Access Controller (AC), whose main function is to manage, control, and configure the WTP devices that are present in the network. In addition to being a centralized entity for the control and management plane, it may also become a natural aggregation point for the data plane since it is typically situated in a centralized location in the wireless access network. The AC is often co-located with an L2 bridge, a switch, or an L3 router, and may be referred to as Access Bridge or Access Router in those particular cases. Therefore, an Access Controller could be either an L3 or L2 device, and is the generic term we use throughout this document. It is also possible that multiple ACs are present in a network for purposes of redundancy, load balancing, etc. This architecture family has several distinct characteristics that are worth noting. First, the hierarchical architecture and the centralized AC affords much better manageability for large scale networks. Second, 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 no longer fully implement the 802.11 functions as defined in the standards. Therefore, it can be said that the full 802.11 functions are implemented across multiple 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. 🧚
- Distributed WLAN Architecture: The third emerging WLAN architecture family is the distributed architecture in which the participating wireless nodes are capable of forming a distributed network among themselves, via wired or wireless media. A wireless mesh network is one example within the distributed architecture family, where the nodes themselves form a mesh network and connect with neighboring mesh nodes via 802.11 wireless links. Some of these nodes also have wired Ethernet connections acting as gateways to the external network. 🌸
1.4. Taxonomy Methodology and Document Organization 📋
before the IETF CAPWAP working group started documenting the various WLAN architectures, we ran an open survey asking for WLAN architecture descriptions on the IETF CAPWAP mailing list 💌 we gave interested parties a common template with a bunch of questions about their WLAN architectures. we got 16 contributions in the form of short text descriptions answering those questions. 15 of them came from WLAN vendors (AireSpace, Aruba, Avaya, Chantry Networks, Cisco, Cranite Systems, Extreme Networks, Intoto, Janusys Networks, Nortel, Panasonic, Trapeze, Instant802, Strix Systems, Symbol) and one came from the academic research community (UCLA). Out of the 16 contributions, one describes an Autonomous WLAN Architecture, three are Distributed Mesh Architectures, and the remaining twelve entries represent architectures in the family of the Centralized WLAN Architecture. 👑
the main goal of the survey was to find the general categories and trends in WLAN architecture evolution, spot their common characteristics, and figure out what's done differently among them and why 🔍 to squish the survey data into a compact format, this document uses a "Functional Distribution Matrix" (mostly in the Centralized WLAN architecture section) to tabulate the various services and functions in the vendors' offerings 📊 these services and functions are sorted into three main categories:
- Architecture Considerations: The choice of the connectivity between the AC and the WTP. The design choices regarding the physical device on which processing of management, control, and data frames of the 802.11 takes place. 🏗️
- 802.11 Functions: As described in Section 1.1. 📶
- CAPWAP Functions: As described in Section 1.2. 🛰️
for each of these categories, the mapping of each individual function to the network entities each vendor implements is shown in tabular form. the rows in the Functional Distribution Matrix are the individual functions, organized into those three categories. each column of the Matrix is one vendor's architecture offering in the survey data. see Figure 7 as an example of the Matrix 🦋
this Functional Distribution Matrix is ONLY for organizing the architecture taxonomy data 💅 it represents the contributors' views of their architectures from an engineering perspective. it does NOT necessarily mean a product exists or will ship, and it doesn't mean the vendor intends to build one 🙈
the next section gives a list of definitions used in this document 📖 the rest of the document is organized around the three broad WLAN architecture families introduced in Section 1.3, with each family getting its own section. the Centralized Architecture section goes deeper than the other two, mostly because twelve out of the sixteen survey entries fall into the Centralized Architecture category 🤩 summary and conclusions come at the end to highlight the basic findings from this taxonomy exercise ✨
2. Conventions 🎀
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 [3]. 💜
3. Definitions 📖
3.1. IEEE 802.11 Definitions 💖
okay so this is the glossary bestie, the official vocab list for the 802.11 WLAN world 🎀 let's go!
- Station (STA) 📱: a device with an IEEE 802.11 conformant medium access control (MAC) and physical layer (PHY) interface to the wireless medium (WM). basically the thing that talks over the air 📡
- Access Point (AP) 🗼: an entity that has station functionality and provides access to distribution services via the wireless medium (WM) for associated stations. it's giving "the gateway that lets the stations reach the rest of the network" 🚪✨
- Basic Service Set (BSS) 🧺: a set of stations controlled by a single coordination function. one little friend group, one boss 👑
- 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). so, delivering MSDUs between stations inside the same 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). the bridge that ties the whole squad together 🌈
- 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), which appears as a single BSS to the logical link control layer at any station associated with one of those BSSs. so yes, the whole thing looks like ONE BSS to the stations, no cap 🙈💅
- 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). this is where the outside-the-802.11-world traffic gets let into the party 🥳
- Distribution System Service (DSS) 🎀: the set of services provided by the distribution system (DS) that enable the medium access control (MAC) layer 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 include transporting MSDUs between the access points (APs) of basic service sets (BSSs) within an extended service set (ESS), transporting MSDUs between portals and BSSs within an ESS, and transporting MSDUs between stations in the same BSS when the MSDU has a multicast or broadcast destination address, or when the destination is an individual address but the sending station chooses to involve DSS. DSSs are provided between pairs of IEEE 802.11 MACs. the DSS is literally the glue for stations that can't hear each other directly 🫠💖
- 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). it's the plug-in that connects the wifi world to your wired LAN 🔌✨
- Distribution 📬: the service that, by using association information, delivers medium access control (MAC) service data units (MSDUs) within the distribution system (DS). it's the mail carrier, using the association info to know where each letter goes 💌
3.2. Terminology Used in This Document 🧠
okay so this section is literally about clearing up confusion 🙏 the big one is "Access Point (AP)". when people say "AP", they usually mean the physical box with an antenna that implements 802.11 PHY and sends and receives station traffic over the air. but the 802.11 Standard [1] describes the AP mostly as a logical entity that implements a set of logical services so station traffic can be received and transmitted effectively over the air. when people say "AP functions", they usually mean the logical functions the whole WLAN access network supports, not just the subset handled by the physical box the STAs talk to directly. this gets especially messy when logical functions are spread across a network instead of living in one physical entity 😵💫 so to avoid more confusion, we define the following terminology:
- CAPWAP: Control and Provisioning of Wireless Access Points 🎟️
- IEEE 802.11 WLAN Functions 📚: a set of logical functions defined by the 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 the IEEE 802.11 Standard [1]. the standard is the boss here 👑
- CAPWAP Functions 🛠️: a set of WLAN control functions that are not directly defined by IEEE 802.11 Standards, but are deemed essential for effective control, configuration, and management of 802.11 WLAN access networks. the extra helpers that keep everything running smoothly 💅
- Wireless Termination Point (WTP) 📡: the physical or network entity that contains an RF antenna and 802.11 PHY to transmit and receive station traffic for the IEEE 802.11 WLAN access networks. these physical entities were often called "Access Points" (AP), but "AP" can also refer to the logical entity that implements 802.11 services. we recommend "WTP" as the generic term that explicitly refers to the physical entity with the above property (e.g., featuring an RF antenna and 802.11 PHY), applicable to network entities of both Autonomous and Centralized WLAN Architecture (see below). so WTP is the clean name for the box 🫶
- Autonomous WLAN Architecture 🏝️: the WLAN access network architecture family in which all the logical functions, including both IEEE 802.11 and CAPWAP functions (wherever applicable), are implemented within each Wireless Termination Point (WTP) in the network. the WTPs here are also called standalone APs, or fat APs, because they implement the full set of functions that let them operate without any other support from the network. independent queens 👸
- Centralized WLAN Architecture 🏰: the WLAN access network architecture family in which the logical functions, including both IEEE 802.11 and CAPWAP functions (wherever applicable), are implemented across a hierarchy of network entities. at the lower level are the WTPs, and at the higher level are the Access Controllers (ACs), which are responsible for controlling, configuring, and managing the entire WLAN access network. the ACs are the bosses of the castle 👑🏰
- 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 an example of such an architecture. everyone's a little bit in charge 🧚
- Access Controller (AC) 🎛️: the network entity in the Centralized WLAN Architecture that provides WTPs access to the centralized hierarchical network infrastructure in the data plane, control plane, management plane, or a combination therein. the AC is the gatekeeper to the big network 🚪💜
- Standalone WTP 🧍: refers to the WTP in Autonomous WLAN Architecture. solo mode activated 🫡
- Controlled WTP 🎮: refers to the WTP in Centralized WLAN Architecture. this one gets orders from the AC 🫡
- Split MAC Architecture ✂️: a subgroup of the Centralized WLAN Architecture whereby WTPs in such WLAN access networks only implement the delay sensitive MAC services (including all control frames and some management frames) for IEEE 802.11, while all the remaining management and data frames are tunnelled to the 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. the MAC gets divided up like a pizza 🍕
- Remote MAC Architecture 🛰️: a subgroup of the Centralized WLAN Architecture, where the entire set of 802.11 MAC functions (including delay-sensitive functions) is implemented at the AC. the WTP terminates the 802.11 PHY functions. the AC does all the MAC work from far away 🌙
- Local MAC Architecture 🏠: a subgroup 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. the WTP keeps it all at home 🏡💖
3.3. Terminology Used Historically but Not Recommended 🙅♀️
okay so some vendors used older names for these things, and we'd really rather everyone stop using them to avoid more confusion 🫠 here's the list, with what to use instead:
- Split WLAN Architecture: use Centralized WLAN Architecture. 💅
- Hierarchical WLAN Architecture: use Centralized WLAN Architecture. 💅
- Standalone Access Point: use Standalone WTP. 💅
- Fat Access Point: use Standalone WTP. 💅
- Thin Access Point: use Controlled WTP. 💅
- Light weight Access Point: use Controlled WTP. 💅
- Split AP Architecture: use Local MAC Architecture. 💅
- Antenna AP Architecture: use Remote MAC Architecture. 💅
- Autonomous Architecture 🏝️✨
4.1. Overview 🌊
okay so Figure 1 shows an example network of the Autonomous WLAN Architecture 🗺️ this architecture puts ALL the 802.11 functionality into one physical device, the Wireless Termination Point (WTP). one embodiment 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 connects the Ethernet interfaces of different WTPs provides the distribution system, and 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 Architecturea single physical WTP can optionally be provisioned as multiple virtual WTPs by supporting multiple SSIDs that 802.11 clients may associate with. sometimes this means putting a matching 802.1Q VLAN tag on each packet forwarded to the Ethernet infrastructure, and removing 802.1Q tags before forwarding the packets to the wireless medium 🏷️✨
the scope of the ESS(s) created by interconnecting the WTPs is 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 🔐
4.2. Security 🔒🚨
okay bestie, this part is SERIOUS 😭🔥 since both the 802.11 and CAPWAP functions are tightly integrated into a single physical device, security issues with this architecture are confined to the WTP. there are no extra implications from the client authentication and encryption/decryption perspective, because the AAA interface and the key generation mechanisms required for 802.11i encryption/decryption are integrated into the WTP 🧠💜
one of the security needs in this architecture is mutual authentication between the WTP and the Ethernet infrastructure. this can be ensured by existing mechanisms such as 802.1X between the WTP and the Ethernet switch it connects to 🛡️. another critical security issue is that the WTP is most likely NOT under lock and key, but contains secret information to communicate with back-end systems, such as AAA and SNMP 😱💀. because IT personnel uses the common management method of pushing a "template" to all devices, theft of such a device could potentially compromise the wired network 🚨🙈
5. Centralized WLAN Architecture 🌸
Okay so the Centralized WLAN Architecture is an emerging architecture family in the WLAN market, and it's giving main character energy 🦋. Compare it to the Autonomous WLAN Architecture, where the 802.11 functions and network control functions are all implemented inside each Wireless Termination Point (WTP). Here, the vibe is different: you get one or more centralized controllers, called Access Controller(s), which let you monitor the whole network at once, scale your management way better, and change configurations dynamically ✨.
The figure below shows the Centralized WLAN Architecture network diagram. The Access Controller (AC) connects to multiple Wireless Termination Points (WTPs) through an interconnection medium. That medium can be a direct connection, an L2-switched network, or an L3-routed network, which we'll get into in Section 5.1 🎀. The AC swaps configuration and control information with the WTP devices, so you can manage the whole network from one central spot 💅. Also, tiny but important: the designs in this family do not presume (even though the diagram might make it look that way) that the AC necessarily steps into the data plane to and from the WTP(s). We'll dig into that more later in this section 🫶.
+---------------+ +---------------+ +---------------+
| 802.11 BSS 1 | | 802.11 BSS 2 | | 802.11 BSS 3 |
| ... | | ... | | ... |
| +-------+ | | +-------+ | | +-------+ |
+----| WTP |--+ +----| WTP |--+ +----| WTP |--+
+---+---+ +---+---+ +---+---+
| | |
+------------------+ | +-----------------+
| |...|
+----+--+---+--------+
| Interconnection |
+-------+------------+
|
|
+-----+----+
| AC |
+----------+
Figure 2: Centralized WLAN Architecture DiagramIn the diagram above, the AC is drawn as a single physical box that provides all of the CAPWAP functions listed in Section 1.2. But ngl, that's not always how it goes 🙈. If you look closer, these functions have different resource needs (for example CPU, memory, and storage), and those needs can be spread across different devices. Complex radio control algorithms can be CPU intensive, and storing and downloading images and configurations can be storage intensive. So different CAPWAP functions might end up on different physical devices because their resource needs are so different 🍓. The network entity marked 'AC' in the diagram should be thought of as a bunch of logical functions, not necessarily as one single physical device 💜. The ACs may also choose to handle some control functions locally, and then provide interfaces to reach other global network management functions. Those are usually on separate boxes, like an SNMP Network Management Station or an AAA back-end server (for example a Radius Authentication Server) 🌈.
5.1. Interconnection between WTPs and ACs 🔥
Okay so there are a few connectivity options between the AC(s) and the WTPs. You've got direct connection, L2 switched connection, and L3 routed connection, and they're shown in Figures 3, 4, and 5 below 🧚.
-------+------ LAN
|
+-------+-------+
| AC |
+----+-----+----+
| |
+---+ +---+
| |
+--+--+ +--+--+
| WTP | | WTP |
+--+--+ +--+--+
Figure 3: Directly Connected
-------+------ LAN
|
+-------+-------+
| AC |
+----+-----+----+
| |
+---+ +---+
| |
+--+--+ +-----+-----+
| WTP | | Switch |
+--+--+ +---+-----+-+
| |
+-----+ +-----+
| WTP | | WTP |
+-----+ +-----+
Figure 4: Switched Connections
+-------+-------+
| AC |
+-------+-------+
|
--------+------ LAN
|
+-------+-------+
| Router |
+-------+-------+
|
-----+--+--+--- LAN
| |
+---+ +---+
| |
+--+--+ +--+--+
| WTP | | WTP|
+--+--+ +--+--+
Figure 5: Routed Connections5.2. Overview of Three Centralized WLAN Architecture Variants 💖
Dynamic and consistent network management is one of the big reasons people go for the Centralized Architecture, so this is a major moment 👑. The survey data from vendors also shows that different varieties of this architecture family have popped up to handle a complex set of requirements across different deployment scenarios 🌸. This is partly because the 802.11 standard [1] is super flexible about how the logical functions described under the term "Access Point (AP)" get implemented. Since there's no standard mapping of these AP functions to physical network entities, vendors have made several different design choices. On top of that, the growing demand for monitoring and consistent configuration of large wireless networks has led to a set of 'value-added' services from various vendors, and most of them share common design properties and service goals ✨.
Below, we're going to walk through the three main variants that showed up in the survey data within the Centralized WLAN Architecture family: Local MAC, Split MAC, and Remote MAC 🦋. For each approach, we map the characteristics of the various functions into the network entities from each vendor. The names Local MAC, Split MAC, and Remote MAC describe how the functions (especially the 802.11 MAC functions) get mapped onto network entities. Local MAC means the MAC functions stay intact and local to the WTPs. Remote MAC means the MAC has moved away from the WTP and into a remote AC in the network. Split MAC means the MAC is split between the WTPs and ACs, mostly along the line of realtime sensitivity. Usually, Split MAC vendors put realtime functions on the WTPs and leave non-realtime functions to the ACs 🎀.
Here's the tea, though: 802.11 doesn't clearly say what counts as a realtime function versus a non-realtime function, so there's no clear and definitive line 😭. As Section 5.4 shows, each vendor has its own take on this, and there are some discrepancies about where the line between realtime and non-realtime functions gets drawn. Still, vendors agree on how most MAC functions should be characterized. For example, every vendor classifies the DCF as a realtime function 💅.
The differences among the Local MAC, Split MAC, and Remote MAC architectures are shown graphically in the figure below 🌈.
+--------------+--- +---------------+--- +--------------+---
| CAPWAP | | CAPWAP | | CAPWAP |
| functions |AC | functions |AC | functions |
|==============|=== |---------------| |--------------|
| | | non RT MAC | | |AC
| 802.11 MAC | |===============|=== | 802.11 MAC |
| |WTP | Realtime MAC | | |
|--------------| |---------------|WTP |==============|===
| 802.11 PHY | | 802.11 PHY | | 802.11 PHY |WTP
+--------------+--- +---------------+--- +--------------+---
(a) "Local MAC" (b) "Split MAC" (c) "Remote MAC"
Figure 6: Three Architectural Variants within the Centralized
WLAN Architecture Family5.3. Local MAC ✨
okay so bestie, the whole point of the Local MAC model (see Figure 6 (a) 🦋) is to hand network access policies and management functions (the CAPWAP functions from Section 1.2) over to the AC 🫶 without splitting the 802.11 MAC between the WTPs and the AC. The entire 802.11 MAC lives locally on the WTPs, and they handle all the 802.11 management and control frame processing for the STAs 💅. Meanwhile, anything about managing and configuring the WTP devices still gets passed to a centralized AC, so the network stays easy to run and the config stays consistent across the whole network 🌸.
Figure 7 is the tea ☕ on how the six vendors in the survey who went with Local MAC designed things, based on the architecture considerations above. The "WTP-AC connectivity" row is the kind of connection each vendor can support between the WTPs and the AC. Every single vendor supports L3 routed connectivity, which means direct connections and L2 switched networks are supported by everyone too 🙌. When you see "802.11 mgmt termination" and "802.11 control termination", that's the physical network device doing the processing of 802.11 management and control frames. All of these vendors terminate those frames at the WTPs 🍓. The last row, "802.11 data aggregation", is about which device aggregates and delivers 802.11 data frames from one STA to another (maybe through a DS) 👀. And this is where the vendors split up: some send all the 802.11 data traffic through the AC, while others don't.
Arch7 Arch8 Arch9 Arch10 Arch11
----- ----- ----- ------ ------
WTP-AC
connectivity 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 ArchitectureThe survey shows some vendors tunnel or encapsulate all station traffic to or from the ACs, which means the AC is also acting as the access router for this WLAN access network 🧚. Other vendors separate the control plane from the data plane: station traffic gets bridged or routed locally, but the centralized control stays at the AC 💜.
Figure 8 shows that most CAPWAP functions (the ones from Section 1.2) are implemented at the AC 👑, with help from the WTPs to monitor RF channels and collect statistics and state information from the STAs. Why the AC? Because it gets network-wide visibility, and that's essential for a lot of control, configuration, and value-added services ✨.
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 ArchitectureThe matrix in Figure 9 shows that most 802.11 functions are done at the WTPs for Local MAC 🔥. The small differences between vendors are in distribution service, 802.11e scheduling, and 802.1X/EAP authentication 🎀. The distribution service difference matches what we already saw in Figure 7 for "802.11 data aggregation", so it's giving consistency 💖.
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
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 ArchitectureSo if you look at Figures 7, 8, and 9 together, the differences between vendors in the Local MAC Architecture are pretty minor 🥹, and most of the functional mapping is the same across vendors 🌈.
5.4. Split MAC ✨
okay bestie, so the Split MAC architecture is giving "share the workload" 💅. The main idea is that some of the 802.11 MAC functionality moves off the WTPs and onto a centralized AC, and the AC also handles the stuff needed for managing and monitoring the WTP devices 🎀. (See Figure 6 (b) if you want the picture.) Usually, the choice of which 802.11 MAC functions go to the AC comes down to how time-critical each service is ⏰.
In Split MAC, the WTP still terminates the infrastructure side of the wireless physical link, handles radio-related management, and runs the time-critical parts of the 802.11 MAC 📡. Meanwhile, the non-realtime management functions go to the centralized AC, along with the higher-level stuff like configuration, QoS, load-balancing policies, and access control lists 🧚. The big difference between Local MAC and Split MAC is all about the non-realtime functions 👑. In Split MAC, the AC terminates the 802.11 non-realtime functions. In Local MAC, the WTP terminates them and then sends the appropriate messages to the AC 💜.
So why would anyone pick Split MAC? 🤔 First, it offloads the stuff that's only relevant to each BSS's locality onto the WTP, which lets the AC scale to a big pile of 'light weight' WTP devices 🦋. Second, realtime functions have strict latency limits, and they can't handle delays from sending 802.11 control frames (or other realtime info) over multiple hops 😭. That would limit how you can connect the AC and the WTP, so the realtime criterion is usually what separates MAC services between the devices 💖. Third, it helps cut the cost of the WTP so it can be as cheap and simple as possible 💸. Last but not least, moving encryption and decryption to the AC means user encryption keys never sit on the WTP, which cuts down on vulnerabilities from a compromised WTP 🔐. Because of that, new security protocol and algorithm designs don't necessarily make the WTPs obsolete. The ACs just implement the new security schemes, which makes management and updates way simpler ✨. The network is also protected against LAN-side eavesdropping 🙈.
Here's the tea 🍵: the 802.11 specification doesn't clearly define which MAC functions count as "realtime", so every vendor kind of interprets it their own way 🤷♀️. Most vendors agree that these 802.11 MAC services are realtime, and they're the ones picked to run on the WTPs:
- Beacon Generation
- Probe Response/Transmission
- Processing of Control Frames: RTS/CTS/ACK/PS-Poll/CF-End/CF-ACK
- Synchronization
- Retransmissions
- Transmission Rate Adaptation
And these are the non-realtime MAC functions, according to most vendors:
- Authentication/De-authentication
- Association/Disassociation/Reassociation/Distribution
- Integration Services: Bridging between 802.11 and 802.3
- Privacy: 802.11 Encryption/Decryption
- Fragmentation/Defragmentation
Plot twist 🌀: some vendors flip a few of those "non-realtime" functions into the realtime bucket to support apps with strict QoS needs. For example, Reassociation is sometimes treated as "realtime" to support VoIP apps 📞.
The non-realtime side of the 802.11 MAC is handled by the AC by processing raw 802.11 management frames (that's the Split MAC part) 🎀. Figure 10 is a matrix showing how the six vendors that follow the Split MAC design handle the architecture considerations. Most vendors support L3 connectivity between WTPs and ACs, but some can only do L2 switched connections, because splitting the MAC across two physical entities over a network makes the delay constraint much tighter 🥺. Figure 7 makes it clear that the WTP processes the 802.11 control frames in both Split MAC and Local MAC. The real difference is where 802.11 management frames get terminated. Local MAC terminates them at the WTP, while in Split MAC at least some of them are terminated at the AC 💅. Since WTP devices are usually IP-addressable in most cases, any of the direct connection, L2-switched, or L3-routed connections from Section 1.2 can be used 🌸. But if only Ethernet-encapsulation is done (like in Architecture 4), then only direct connection and L2-switched connections are supported 🫶.
Arch1 Arch2 Arch3 Arch4 Arch5 Arch6
----- ----- ----- ----- ----- -----
WTP-AC
connectivity 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 ArchitectureFigure 11 looks similar to the Local MAC one 👀. Most of the CAPWAP control functions are implemented at the AC. The exceptions are RF monitoring, and in some cases RF configuration, which happen locally at the WTPs 📻.
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 ArchitectureThe most fascinating matrix for Split MAC is the Functional Distribution Matrix for 802.11 functions, shown in Figure 12 🔥. Vendors map functions onto the WTPs and the AC with a certain regularity. For example, every vendor puts Distribution and Integration Service at the AC, along with 802.1X/EAP authentication and keys management 🔑. Every vendor also puts beacon generation on the WTPs 📶. Other functions? Vendors sometimes map them differently, so Split MAC architectures aren't consistent about exactly how the MAC gets 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
--------------
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 Architecture5.5. Remote MAC 🛸
okay so the main reason for Remote MAC is to keep the WTPs as light weight as humanly possible 🪶. The WTPs only have the radio interfaces, and the whole set of 802.11 MAC functions (including the delay-sensitive ones) gets offloaded to the Access Controller 🧠. That means all the MAC complexity and the other CAPWAP control functions live with the centralized controller 🎛️.
The WTP is basically just a pass-through between the Wireless LAN clients (STA) and the AC 🚪. It may have an extra feature to convert frames from one format (802.11) to another (i.e., Ethernet, TR, Fiber) 🔄. The centralized controller handles network monitoring, management and control, a whole set of 802.11 AP services, security features, resource management, channel selection, and it guarantees Quality of Service to users 👑. Because the MAC is separated from the PHY, this one gets called the "Remote MAC Architecture" 💅. It's usually deployed with special attention to the connectivity between the WTPs and the AC so the delay is minimized ⚡. And the Radio over Fiber (RoF) from Architecture 5 is an example of Remote MAC Architecture 🌈.
5.6. Comparisons of Local MAC, Split MAC, and Remote MAC ✨
okay so all three Centralized Architectures (Local MAC, Split MAC, and Remote MAC) have two things in common 🫶
- Most of the CAPWAP functions related to network control and configuration live on the AC.
- The IEEE 802.11 PHY lives on the WTP.
Remote MAC is the one that's giving main character 💅 because it's the odd one out. In Remote MAC, the 802.11 MAC is completely separated from the PHY. The other two (Local MAC and Split MAC) keep some of the MAC functions together with the PHY at the WTPs. PHY and MAC separation severely limits the kind of interconnection allowed between WTPs and ACs, so the 802.11 timing constraints still get met. As pointed out earlier, this usually means a tighter constraint on the interconnection between WTP and AC for the Remote MAC Architecture. The upside? Remote MAC gives you the lightest possible WTPs for certain deployment scenarios 🪶
Now for Local MAC vs. Split MAC. Compare Figure 7 to Figure 10 and you'll see it 👀 The commonality is that 802.11 control frames get terminated at the WTPs in both cases. The big difference is that in Split MAC the WTP terminates only the 802.11 control frames, while in Local MAC the WTP may terminate all 802.11 frames. Here's the consequence that's lowkey wild 😭 The Integration Service (basically bridging between 802.11 and 802.3 frames) is handled by the AC in Split MAC, and by the WTP in Local MAC, as shown in Figures 9 and 12 respectively.
Quick side note 🍓 The Distribution Service is usually provided by the AC, but in some Local MAC architectures it can also be implemented at the WTP. The point is performance. Delivering STAs' data traffic without tunneling it to the AC means less overhead, and the WTP depends less on the AC. So in the Local MAC Architecture, the data and control planes can be separated. Iconic 🔥
Even though all the 802.11 traffic gets aggregated at the ACs in the Split MAC Architecture, the data and control planes can still be separated by using multiple ACs. For example, one AC can run most of the CAPWAP functions (control plane), while other ACs handle 802.11 frame bridging (data plane). Separation really is possible, bestie 🧚
Each of the three architectural variants can be advantageous in certain deployment scenarios, so none of them is the "winner" 💖 Local MAC keeps most of the STA's state information at the local WTPs. Remote MAC centralizes most of the state into the back-end AC. Split MAC sits somewhere in the middle of this spectrum, keeping some state locally at the WTPs and the rest centrally at the AC. Lots of factors should be taken into account to find the exact balance you want between centralized and decentralized state. How this balance affects network manageability is currently a matter of dispute within the technical community 🤷♀️ so yeah, it's still being debated.
5.7. Communication Interface between WTPs and ACs 🎀
Before any messages can be exchanged between an AC and a WTP, the WTP needs to discover, authenticate, and register with the AC first. Then it downloads the firmware and establishes a control channel with the AC. Message exchanges between the WTP and AC for control and configuration can happen after that. Here's the basic list of operations that usually happen between the WTP and the AC, in their typical order:
- Discovery: The WTPs discover the AC they will be bound to and controlled by. The discovery procedure can use either static or dynamic configuration. In the dynamic case, a protocol is used so the WTP can discover candidate AC(s).
- Authentication: After discovery, the WTP device authenticates itself with the AC. However, mutual authentication, where the WTP also authenticates the AC, isn't always supported, since some vendors strive for zero-configuration on the WTP side. This isn't necessarily secure, because it leaves open the possible vulnerability of the WTP being attached to a rogue AC 😬
- WTP Association: After successful authentication, a WTP registers with the AC so it can start receiving management and configuration messages.
- Firmware Download: After successful association, the WTP may pull, or the AC may push, the WTP's firmware. That firmware may be protected in some manner, such as with digital signatures.
- Control Channel Establishment: The WTP establishes either an IP-tunnel or performs Ethernet encapsulation with the AC, so it can transfer data traffic and management frames.
- Configuration Download: Following control channel establishment, the AC may push configuration parameters to the WTPs.
5.8. Security 🔐
Given the varied distribution of functionalities in the Centralized Architecture (as surveyed in Section 4.3), it's obvious that an extra network binding gets created between the WTP and the AC. This brings new and unique security issues, and with them, subsequent requirements. Serious stuff, so let's be careful 🫶
5.8.1. Client Data Security 💅
The survey shows clearly that the termination point for "over the air" 802.11 encryption [4] can be implemented either in the WTP or in the AC. On top of that, the 802.1X/EAP [6] functionality is distributed between the WTP and the AC. In most cases, the AC performs the necessary functions as the authenticator in the 802.1X exchange.
If the STA and AC are the parties in the 4-way handshake (defined in [4]), and 802.11i traffic encryption terminates at the WTP, then the Pairwise Transient Key (PTK) has to be transferred from the AC to the WTP. The keying material is part of the control and provisioning of the WTPs, so a secure encrypted tunnel for control frames is used to transport it 🔒
The centralized model encourages AC implementations to use one PMK for many different WTPs. This makes it way faster for an STA to move from one WTP to another that's connected to the same AC, since it doesn't need to set up a separate PMK. But this leaves the STA in a difficult position, because it can't tell the difference between a compromised PMK and one that's being shared on purpose 😵 This issue must be resolved, but the resolution is beyond the scope of the CAPWAP working group. The venue for that resolution is to be determined by the IEEE 802 and IETF liaisons.
When the 802.11i encryption/decryption is performed in the AC, the key exchange and state transitions happen between the AC and the STA. So there's no need to transfer any crypto material between the AC and the WTP ✨
No matter where the 802.11i termination point is, the Centralized WLAN Architecture has two practices for "over the wire" client data security. In some cases there's an encrypted tunnel (IPsec or SSL) between the WTP and AC, which assumes the security boundary is in the AC. In other cases, an end-to-end mutually authenticated secure VPN tunnel is assumed between the client and the AC, another security gateway, or an end host entity 🦋
5.8.2. Security of Control Channel between the WTP and AC 🛡️
For the CAPWAP functions to be implemented in the Centralized WLAN Architecture, a control channel is necessary between the WTP and AC.
To address potential security threats against the control channel, existing implementations feature one or more of the following security mechanisms:
- Secure discovery of WTP and AC.
- Authentication of the WTPs to the ACs (and possibly mutual authentication).
- Confidentiality, integrity, and replay protection of control channel frames.
- Secure management of WTPs and ACs, including mechanisms for securely setting and resetting secrets and state.
Discovery and authentication of WTPs are handled in the submissions by authentication mechanisms that range from X.509 certificates and AAA authentication to pre-shared credential authentication. In all cases, confidentiality, integrity, and protection against man-in-the-middle attacks for the control frames are handled by a secure encrypted tunnel between the WTP and AC(s), using keys derived from the authentication methods mentioned previously. One of the big motivations for the Centralized WLAN Architecture is to minimize how much cryptographic and security-sensitive information, plus operational configuration parameters, gets stored within the WTPs. That's why most of the submissions under the Centralized Architecture category use a post-WTP-authenticated discovery phase for configuration provisioning, which in turn protects against the theft of WTPs 🔥
5.8.3. Physical Security of WTPs and ACs 🏰
To provide comprehensive radio coverage, WTPs are often installed in locations that are hard to secure physically. It's relatively easier to secure the AC physically. If high-value secrets, such as a RADIUS shared secret, are stored in the AC instead of the WTPs, then the physical loss of a WTP doesn't compromise those secrets. So the Centralized Architecture may reduce the security consequences of a stolen WTP 🙌 On the other hand, concentrating all the high-value secrets in one place makes the AC an attractive target. It requires strict physical, procedural, and technical controls to protect those secrets 😤
6. Distributed Mesh Architecture 🕸️
Out of the sixteen architecture survey submissions, three belong to the Distributed Mesh Architecture family. An example of the Distributed Mesh Architecture is shown in Figure 13, and it reflects some of the common characteristics found in these three submissions 🦋
+-----------------+ +-----------------+
| 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 Architecture6.1. Common Characteristics
okay so mesh nodes are kind of the ultimate team players 🫶 they can act as APs for client stations in their own BSS 💖 and ALSO relay traffic to neighboring mesh nodes over 802.11 wireless links ✨ some mesh nodes can just be traffic relays for other mesh nodes and never serve any clients at all 🦋 and honestly? That's the glow-up, bestie. Instead of pulling Ethernet cable to every single AP, wireless mesh networks give you a super attractive alternative for relaying backhaul traffic 🌸
mesh nodes can also keep tabs on their neighbors, and even nodes further out, by swapping information periodically 👀 so they stay fully aware of the dynamic network topology and the RF conditions around them 📡 this peer-to-peer vibe lets mesh nodes actively coordinate with each other to achieve self-configuration and self-healing 🔥 and this is literally the big difference between the Distributed Architecture family and the Centralized Architecture 💅 much of the CAPWAP functions can be implemented across the mesh nodes in a distributed way, with no centralized entity making all the control decisions 👑
BUT the mesh world doesn't say no to centralized control 🙈 a combination of centralized and distributed control can totally co-exist in mesh networks 💜 some global configuration or policy change might be better handled in a coordinated way if some form of Access Controller (AC) exists in the mesh network 🧚 (even if it's not the full blown version of the AC from the Centralized WLAN Architecture). 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, like user authentication, to a single centralized end point (such as a RADIUS server) 🎀 but mesh networks let each mesh AP talk directly to the RADIUS server 💖 which eliminates the single point of failure and takes advantage of the client distribution in the network 🌈 iconic.
the backhaul transport network of a mesh network can be either an L2 or L3 networking technology 🦋 right now, vendors are using proprietary mesh technologies on top of standard 802.11 wireless links to enable peer-to-peer communication between mesh nodes 😭 which means there is no interoperability among mesh nodes from different vendors 💀 the IEEE 802.11 WG has recently started a new Task Group (TGs) to define the mesh standard for 802.11 🫶 we'll see what they cook ✨
6.2. Security
similar security concerns for client data security, as described in Section 5.8.1, also apply to the Distributed Mesh Architecture 🔐 and one really important mesh-specific thing: the mesh nodes must authenticate each other within the same administrative domain 🚨 that's not optional, bestie 😤 also, to protect user and management data that might not be secured at layer 3, data transmission among neighboring nodes should be secured by a layer 2 mechanism of confidentiality, integrity, and replay protection 🛡️💜 layer 2 security is giving main character energy here 👑
7. Summary and Conclusions ✨
okay recap time 🎀 we asked existing WLAN vendors and other interested parties to submit a short description of existing or desired WLAN access network architectures, so we could define a taxonomy of possible WLAN access network architectures 🧚 the info from the 16 submissions got condensed and summarized in this document 💅
new terminology got defined wherever the existing terms were insufficient or ambiguous 🌸 for example, the broad set of Access Point functions got split into two categories: 802.11 functions (the ones required by the IEEE 802.11 standards) and CAPWAP functions (the ones not required by 802.11 but deemed essential for control, configuration, and management of 802.11 WLAN access networks) 💖 and "Access Point" was causing SO much confusion 😭 it usually meant a physical box with the antennas, but it didn't behave in a uniform, externally consistent way across submissions 🙈 so we redefined the AP as the set of 802.11 and CAPWAP functions, and the physical box that terminates the 802.11 PHY is now called the Wireless Termination Point (WTP) 🦋 clean, iconic, done ✨
based on the submissions from the architecture survey phase, we sorted existing WLAN architectures into three broad classes 🔥
- Autonomous WLAN Architecture: a family of architectures where all the 802.11 functions and, where applicable, CAPWAP functions are implemented in the WTPs 🌈
- Centralized WLAN Architecture: a family of architectures where the AP functions are split between the WTPs and the AC, with the AC acting as a centralized control point for multiple WTPs 👑
- Distributed WLAN Architecture: a family of architectures where part of the control functions is implemented across a distributed network of peer entities 🫶
within the Centralized WLAN Architecture, there are a few visible sub-categories that depend on how you map the MAC functions (at a high level) between the WTP and the AC 💅 three prominent ones showed up in the submissions 😭
- Split MAC Architecture: 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 💜
- Local MAC Architecture: the entire set of 802.11 MAC functions is implemented on the WTP 🦋
- Remote MAC Architecture: the entire set of 802.11 MAC functions is implemented on the AC 🧚
here's the tree diagram that sums up the architectures in this taxonomy 🌸
+----------------+
|Autonomous |
+---------->|Architecture |
| |Family |
| +----------------+
| +--------------+
| |Local |
| +---->|MAC |
| | |Architecture |
| | +--------------+
| |
| +----------------+ | +--------------+
| |Centralized | | |Split |
+---------->|Architecture |--+---->|MAC |
| |Family | | |Architecture |
| +----------------+ | +--------------+
| |
| | +--------------+
| | |Remote |
| +---->|MAC |
| |Architecture |
| +--------------+
| +----------------+
| |Distributed Mesh|
+---------->|Architecture |
|Family |
+----------------+so the numbers: a majority of the submitted WLAN access network architectures (twelve out of sixteen) followed the Centralized WLAN Architecture 👑 all but one of those Centralized submissions were grouped into either a Split MAC Architecture or a Local MAC Architecture 💖 one submission followed the Autonomous WLAN Architecture, and three followed the Distributed WLAN Architecture 🌈
the WLAN access network architectures in the submissions showed these connectivity assumptions between the WTP and the AC 🔥
- Direct connection between the WTP and the AC.
- L2 switched connection between the WTP and the AC.
- L3 routed connection between the WTP and the AC.
- Wireless connection between the mesh nodes in the distributed mesh architecture.
interoperability between equipment from different vendors is one of the fundamental problems in the WLAN market today 😤 so to get interoperability through open standard development, the following steps are suggested for IETF and IEEE 802.11 🫶
using this taxonomy, a functional model of an Access Point should be defined by the new study group recently formed 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 ✨ this functional model should serve as a common foundation to support the existing WLAN architectures outlined in this taxonomy, plus any further architecture development within or outside the IEEE 802.11 group 🎀 it's possible, and even recommended, that the functional model work also includes impact analysis of implementing each functional element on either the WTP or the AC 💜
and as part of the functional model definition, interfaces must be defined as primitives between these functional elements 🦋 if a pair of functional elements with an interface defined between them is being implemented on two different network entities, then a protocol specification between that pair of network elements is required, and should be developed by the IETF 🌸💅
8. Security Considerations 🔒✨
okay bestie, this part is SERIOUS 😭 so let's get into it. This doc isn't trying to be a full threat analysis of every security issue in every WLAN architecture 🫶 But it does do something important: it documents the architectures used in existing IEEE 802.11 products AND catalogues the security problems that come up with them, plus how vendors deal with those threats 💅 The WLAN architectures fall into three families: Autonomous, Centralized, and Distributed 🦋 Sections 4, 5, and 6 cover each family, and each one has its own security subsection.
The big security worry for Autonomous Architecture is mutual authentication between the WTP and the wired (Ethernet) infrastructure equipment 🔐 Physical security of WTPs matters too, because they hold secret information, and if someone steals one, they could potentially compromise even the wired network 💀
Centralized Architecture is where things get spicy 🌶️ because the new network binding between the WTP and AC brings in new security concerns. Here's the list:
- keying material for mobile client traffic may need to be securely transported from the AC to the WTP 🗝️
- secure discovery of the WTP and AC is required, and so is mutual authentication between the WTPs and the AC 🤝
- man-in-the-middle attacks on the control channel between the WTP and AC are a threat 😱
- the control channel frames need confidentiality, integrity, and replay protection 🛡️
- theft of WTPs, to pull out the secrets stored inside them, is a risk 🫠
Every survey result for this architecture category has shown mechanisms that address these issues, so there's hope 🥹✨
The new security issue in the Distributed Mesh Architecture is that mesh nodes need to authenticate each other before they can form a secure mesh network 🕸️ Encrypted communication between mesh nodes is recommended to protect both control and user data 🔐🦋
9. Acknowledgements 🫶🌸
okay this taxonomy is truly a group project with contributions from SO many people 😭💖 First, a huge thank you to every member of the CAPWAP Architecture Design Team who gave up countless hours to teleconference calls, emails, and writing and reviewing the document 🙏 The full Design Team is listed below:
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
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 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)We also want to shout out the people who took part in the architecture survey and gave super detailed input data to help put this taxonomy together: 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 🌟 Honestly, writing this without their big pile of real-world data points would have been simply impossible 😤💜 Last but not least, thanks to our CAPWAP WG co-chairs, Mahalingam Mani and Dorothy Gellert, and our Area Director, Bert Wijnen, for all their unfailing support 🫶👑
10. Normative References 📚
these are the docs the spec leans on, so they're kinda a big deal 🧚
[1] "IEEE WLAN MAC and PHY Layer Specifications", August 1999, <IEEE 802.11-99>.
[2] O'Hara, B., Calhoun, P., and J. Kempf, "Configuration and Provisioning for Wireless Access Points (CAPWAP) Problem Statement", RFC 3990, February 2005.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[4] "IEEE Std 802.11i: Medium Access Control (MAC) Security Enhancements", April 2004.
[5] "IEEE Std 802.11h: Spectrum and Transmit Power Management Extensions in the 5 GHz Band in Europe", October 2003.
[6] "IEEE Std 802.1X: Port-based Network Access Control", June 2001.
Authors' Addresses 💌
and here are the lovely humans who wrote it 🥰
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.comFull Copyright Statement ⚖️
the legal stuff, but make it cute 🎀
Copyright (C) The Internet Society (2005).
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.
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.
Intellectual Property 🧾
the IETF doesn't take a side on whether any IP rights apply to the tech in here, or whether you can get a license for it, and it hasn't checked for any rights on its own either 🤷♀️ If you want the rules on rights in RFC docs, check out BCP 78 and BCP 79 📖
Copies of IPR disclosures sent to the IETF Secretariat, any assurances of licenses that are available, and the results of any attempt to get a general license or permission for implementers or users to use those rights can be found in the IETF online IPR repository at http://www.ietf.org/ipr.
The IETF also invites anyone to tell it about any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org 💜
Acknowledgement 💖
last one, promise 😭🫶
Funding for the RFC Editor function is currently provided by the Internet Society. 🌈💅
📦 where this page comes from
- ietf: rfc4118 2005-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms