RFC 4564
Objectives for Control and Provisioning of Wireless Access Points (CAPWAP)
Hiii, Welcome to RFC 4564 💖
Okay so this is RFC 4564, and it's giving Informational 🎀 (aka "here's some info, no official standard, go nerd out"). It came out in July 2006 from the Network Working Group, and the title is Objectives for Control and Provisioning of Wireless Access Points (CAPWAP) ✨. The editor is S. Govindan, Ed. (no affiliation is listed for them), and the co-authors are H. Cheng (Panasonic), ZH. Yao (Huawei), WH. Zhou (China Mobile), and L. Yang (Intel) 🌸. It doesn't obsolete or update anything, since the title block doesn't list any.
Status of This Memo 📜
Okay, this part is the disclaimer. This memo gives information to the Internet community 🧚. It is not an Internet standard of any kind, and it's unlimited to distribute, so share it with your whole group chat 💅.
Copyright Notice 🔒
The Internet Society owns the copyright, and the year is 2006 🦋.
Abstract ✨
Bestie, this doc lays out objectives for an interoperable protocol to control and provision Wireless Access Points (CAPWAP) 🍓. The goal is a focused set of requirements for developing and evaluating a CAPWAP protocol 💜. The objectives cover architecture, operation, security, and network operator requirements, all so that Wireless Local Area Network (WLAN) devices with different designs can actually talk to each other 🫶.
Table of Contents 🗂️
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Requirements Notation ...........................................4
4. Objectives Overview .............................................4
5. Objectives ......................................................5
5.1. Mandatory and Accepted Objectives ..........................5
5.1.1. Logical Groups ......................................5
5.1.2. Support for Traffic Separation ......................6
5.1.3. Wireless Terminal Transparency ......................8
5.1.4. Configuration Consistency ...........................8
5.1.5. Firmware Trigger ....................................9
5.1.6. Monitoring and Exchange of System-wide
Resource State .....................................10
5.1.7. Resource Control Objective .........................11
5.1.8. CAPWAP Protocol Security ...........................12
5.1.9. System-wide Security ...............................14
5.1.10. IEEE 802.11i Considerations .......................15
5.1.11. Interoperability Objective .......................17
5.1.12. Protocol Specifications ..........................18
5.1.13. Vendor Independence ..............................19
5.1.14. Vendor Flexibility ...............................19
5.1.15. NAT Traversal ....................................20
5.2. Desirable Objectives ......................................21
5.2.1. Multiple Authentication Mechanisms .................21
5.2.2. Support for Future Wireless Technologies ...........21
5.2.3. Support for New IEEE Requirements ..................22
5.2.4. Interconnection Objective ..........................23
5.2.5. Access Control ....................................24
5.3. Non-Objectives ............................................25
5.3.1. Support for Non-CAPWAP WTPs ........................25
5.3.2. Technical Specifications ...........................26
5.4. Operator Requirements .....................................27
5.4.1. AP Fast Handoff ....................................27
6. Summary and Conclusion .........................................27
7. Security Considerations ........................................28
8. Acknowledgements ...............................................29
9. Normative References ...........................................29
10. Informative References ........................................291. Introduction 🌈
Okay, so big WLAN deployments are getting really popular, and that's bringing some real challenges into focus 👑. The biggest headache is managing tons of Wireless Termination Points (WTPs), and it's even messier because every WTP can be designed differently 💀. Keeping configurations consistent across all those WTPs in one system is another problem, and the wireless medium is unpredictable on top of that, plus WLAN security is its own thing 🙈. All of this was highlighted in [RFC3990] ✨.
Many vendors have already tried to fix this with new architectures and solutions 🔥. A survey was done to understand all these developments, and it's a first step toward making the solutions interoperable 💅. The Architecture Taxonomy [RFC4118] came out of that survey and sorts the major WLAN architecture families into groups 🦋. Broadly, those are autonomous, centralized WLAN, and distributed mesh architectures 🍓.
The Architecture Taxonomy describes the centralized WLAN architecture as one where parts of the wireless medium access control (MAC) operations live in a WLAN controller 🧚. This centralized design splits further into remote-MAC, split-MAC, and local-MAC designs. Each one differs in how much of the wireless MAC layer work is separated between the WTPs and the WLAN controller 💜.
This document puts forward critical objectives for interoperability in the CAPWAP framework 🫶. It presents requirements for controlling and provisioning large-scale WLAN deployments. If CAPWAP protocols realize these objectives, WLAN equipment of the major design types can be deployed and managed together, and that's the whole point 😭.
2. Terminology 📖
This document uses terminology from [RFC4118], [802.11], [802.11i], and [802.11e]. On top of that, these terms are defined here:
Centralized WLAN: A WLAN based on the centralized WLAN Architecture [RFC4118] 🎀.
Switching Segment: The parts of a centralized WLAN that mainly deal with switching or routing control and data information between Wireless Termination Points (WTPs) and the WLAN controller 🔀.
Wireless Medium Segment: The parts of a centralized WLAN that mainly deal with the wireless interface between WTPs and wireless terminals 📡. This segment is specific to layer 2 wireless technology, such as IEEE 802.11 ✨.
CAPWAP Framework: A term covering the local-MAC and split-MAC designs of the Centralized WLAN Architecture 👑. Standardization efforts are focused on these designs 💖.
CAPWAP Protocol: The protocol between the WLAN controller and WTPs in the CAPWAP framework 🌸. It handles control, management, and provisioning of WTPs in an interoperable way 🫶.
Logical Group: A logical separation of a physical WTP 🦋. So one physical WTP can run a bunch of logical groups 🍓. Virtual access points (APs) are examples of logical groups 🧚. Here, each Basic Service Set Identifier (BSSID) and the radios of the constituent wireless terminals are counted as distinct logical groups of a physical WTP 💜. Logical groups are maintained without conflicting with the CAPWAP objectives, especially the 'Wireless Terminal Transparency' objective 💅.
3. Requirements Notation ⭐
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 [RFC2119] 🎀.
4. Objectives Overview 🔥
The CAPWAP objectives are broadly sorted to cover architecture, operation, and security requirements for managing large-scale WLAN deployments 🌈.
Architecture objectives are about system-level aspects of the CAPWAP protocol 🏗️. They deal with protocol extensibility, diversity in network deployments and architecture designs, and differences in transport technologies 🦋.
Operational objectives cover the control and management features of the CAPWAP protocol 👑. They deal with WLAN monitoring, resource management, Quality of Service (QoS), and access control 💖.
Security objectives address potential threats to WLANs and how to contain them 🔒. In the CAPWAP context, the security requirements cover the protocol between the WLAN controller and WTPs, and also the WLAN system as a whole 🫶.
There's also a general classification for objectives about the overall impact of the CAPWAP protocol specifications ✨.
5. Objectives 💅
The objectives in this document are prioritized based on how immediately significant they are for developing and evaluating a control and provisioning protocol for large-scale WLAN deployments 🌸. The priorities are:
- i. Mandatory and Accepted Objectives
- ii. Desirable Objectives
- iii. Non-Objectives
The working group discussions decided the priorities for individual objectives 🧚.
There's also a separate category of objectives based on requirements gathered from network service operators 🍓. These are the specific needs that come up from operators' real experience deploying and managing large-scale WLANs 🙈.
- a. Operator Requirements
5.1. Mandatory and Accepted Objectives 👑
Objectives marked as mandatory and accepted are considered crucial for controlling and provisioning WTPs 🔥. They directly address the challenges of large-scale WLAN deployments, and they MUST be realized by a CAPWAP protocol 💖.
5.1.1. Logical Groups ✨
Classification: Architecture
Description:
okay so big WLANs are complex AND expensive 💸, and enterprises are under real pressure to get more bang for their buck 📈
shared WLAN deployments are the glow-up here 🦋. that's where one physical WLAN infrastructure supports a bunch of logical networks at once, and it's getting popular bc it lets deployment and management costs get split across businesses. so both of those big-WLAN problems get handled at the same time 🫶
in traditional WLANs, each physical WTP is one complete subset of a bigger WLAN system. in shared WLANs it's different: each physical WTP holds a number of logical subsets, possibly from a number of bigger WLAN systems 🌸 each logical division of a physical WTP is called a logical group (see the definition in Section 2). so WLANs get managed in terms of logical groups instead of physical WTPs 🎀 and logical groups are based on BSSIDs and other types of virtual APs.
Protocol Requirement:
the CAPWAP protocol MUST be capable of controlling and managing physical WTPs in terms of logical groups, including BSSID-based groups 💅
and for ALL operating modes 👑, including the ones where the WTP does local bridging and the ones where the Access Controller (AC) does centralized bridging, the protocol MUST provide provisions for configuring logical groups at the WTP 🔥
Motivation and Protocol Benefits:
commercial realities mean WLANs have to be manageable in terms of their logical groups 💼 this lets logical services get separated from the underlying infrastructure management 🧚 a protocol that makes this happen gives you simpler, cost-effective WLANs, which is exactly what network service operators are asking for ✨
Relation to Problem Statement:
this objective is about the management complexity problem in terms of costs 💰 sharing WLAN deployments reduces that cost complexity, so the deployment and management cost-efficiencies actually get realized 🍓
5.1.2. Support for Traffic Separation 🎀
Classification: Operations
Description:
so the centralized WLAN architecture makes large-scale deployments less complicated by moving some of the wireless MAC functionality to a central WLAN controller and spreading the rest across the WTPs 🧠 that means WTPs and the WLAN controller end up exchanging control AND data information 📦 this objective says those control and data aspects should be mutually separated, for extra simplicity 🫧 that way, the solution for each type of exchange can be independently optimized 💖
it gets even more important in shared WLAN deployments 😭 mutual separation of control and data also helps with security. given that different logical groups, like the ones set up by different virtual APs, are likely to be managed by different administrators, separating control from data is a first step toward individually containing and securing each logical group 🔐
it's also important that traffic from each logical group stays mutually separated, so the integrity and independence of the logical groups is maintained 🦋
Protocol Requirement:
the CAPWAP protocol MUST define transport control messages so that the transport of control messages is separate from the transport of data messages 💅
Motivation and Protocol Benefits:
separating the data and control parts of the protocol is all about simplifying it 🧚 it also gives flexibility to handle each type of traffic in whatever way fits it best ✨
this requirement also helps remotely located WTPs handle data traffic in alternative ways, without having to forward it across a wide network to the WLAN controller 🌈
and honestly, separating WTP control and data also helps with the secure realization of shared WLAN deployments 🔥
Relation to Problem Statement:
broadly, this objective is about managing complexity in large-scale WLANs 🌸 the traffic separation requirement makes control simpler, because control is separated from the job of data transport 💜
5.1.3. Wireless Terminal Transparency 🙈
Classification: Operations
Description:
the CAPWAP protocol applies between a centralized WLAN controller and a number of WTPs, so it only affects the switching segment of the centralized WLAN architecture 🧚 that means its operations should be independent of the wireless terminal. wireless terminals shouldn't need to know CAPWAP even exists 🫶
Protocol Requirement:
wireless terminals MUST NOT be required to recognize or be aware of the CAPWAP protocol 🙅♀️
this one is a big deal. no changes to terminals means no homework for the terminals 💀
Motivation and Protocol Benefits:
IEEE 802.11-based wireless terminals are mature and widely available 📱 it would be super beneficial for CAPWAP not to slap new requirements on them ✨ basically, this requirement keeps the setup cost of the protocol low, because the numerous existing wireless terminals don't need to be altered 💰
Relation to Problem Statement:
the Problem Statement is all about the challenges of large WLANs made up of many WTPs 🌷 it doesn't talk about how wireless terminals operate, and this objective is there to emphasize that independence 🦋
5.1.4. Configuration Consistency 🌈
Classification: Operations
Description:
WLANs in the CAPWAP framework have numerous WTPs, and every one of them needs to be configured and managed in a consistent way 🧁 the main concern for consistency is having the right information about each WTP's configuration state 📋 so consistency can be achieved by giving the centralized WLAN controller regular updates on the state of WTP operations. the controller can then use those updates to keep the WTPs consistent with each other 💖
Protocol Requirement:
the CAPWAP protocol MUST include support for regular exchanges of state information between WTPs and the WLAN controller 🔥 examples of state information include WTP processing load and memory utilization 📊
Motivation and Protocol Benefits:
a protocol that gives access to regular state information can be used to improve WLAN configuration and performance 🚀 CAPWAP will be better equipped to handle configuration-related problems when that state information is regularly available. so with more state information, control and management operations get better 🫧
Relation to Problem Statement:
the Problem Statement describes maintaining consistent configuration across the many WTPs of a WLAN as one of the major challenges 😤 this objective goes after the root issue behind it, which is having timely state information 💜
5.1.5. Firmware Trigger 💾
Classification: Operations
Description:
one specific part of configuration consistency is the firmware used by the various WTPs 👀 the scale of large WLANs opens the door to variations in the firmware used across WTPs. this objective highlights that CAPWAP needs a way to trigger the delivery of appropriate firmware versions to WTPs 🎀 the actual delivery of firmware doesn't have to be part of the protocol itself 🧚
Protocol Requirement:
the CAPWAP protocol MUST support a trigger for delivery of firmware updates 💅
Motivation and Protocol Benefits:
CAPWAP connects many WTPs to a centralized WLAN controller, and firmware distribution is what keeps those interfaces compatible 🔗 that results in consistent configuration and simpler management 🫶 so the protocol benefits from including triggers for firmware update distribution ✨
Relation to Problem Statement:
the Problem Statement identifies inconsistencies in WTP configuration as a major challenge for large-scale WTPs 🌸 this objective helps overcome that by giving CAPWAP a way to start delivering firmware updates that are compatible across all WTPs 🦋
5.1.6. Monitoring and Exchange of System-wide Resource State 📡
Classification: Operations
Description:
the centralized WLAN architecture is made up of a switching segment and a wireless medium segment 🧠 in the switching segment, network congestion, WTP status, and firmware information all have to be monitored 👀 in the wireless medium segment, the dynamic nature of the medium itself has to be monitored 🌊 overall, there are also various statistics that need to be considered for efficient WLAN operation 📊
the CAPWAP protocol should be capable of monitoring the various information sources and delivering the resulting information to the relevant WLAN devices -- either WTPs or the WLAN controller 💌 and since those information sources are related to each other, the CAPWAP protocol should combine state information from them too 🫧 for example, statistics information and status signals from WTPs may be merged before being exchanged 🔀
examples of statistics that CAPWAP should monitor and exchange include congestion state, interference levels, loss rates, and various delay factors 🍓
Protocol Requirement:
the CAPWAP protocol MUST allow for the exchange of statistics, congestion, and other WLAN state information 🔥
Motivation and Protocol Benefits:
a protocol is only as effective as the information it works with 🧚 this requirement for resource monitoring and exchange gets the CAPWAP protocol the appropriate information it needs ✨
Relation to Problem Statement:
the Problem Statement calls out the challenge of dealing with large numbers of WTPs and the dynamic nature of the wireless medium 🌍 information about the state of WTPs and the medium is key to handling both well 💜 so this objective is about managing consistency in large WLANs 🫶
5.1.7. Resource Control Objective ✨
Classification: Operations
Description:
Okay bestie, performance and quality are everything for a wireless network 💅 Since CAPWAP-based WLANs combine a switching segment and a wireless medium segment, performance and quality need to be coordinated across both segments. So QoS performance must be enforced system-wide 🔥
This objective is all about QoS over the entire WLAN system, which covers the switching segment and the wireless medium segment 🦋 The two are fundamentally different, so it's likely there are alternate QoS mechanisms between WTPs and wireless service subscribers and between WTPs and WLAN controllers. For instance, the former will be based on IEEE 802.11e, whereas the latter will be an alternative. So resources need to be adjusted in a coordinated fashion over both segments. The CAPWAP protocol should ensure that these adjustments are appropriately exchanged between WLAN controllers and WTPs 🫶
There are also a bunch of other IEEE 802.11 task groups that may affect network resources, like IEEE 802.11 TGk, TGu, and TGv, which are currently in progress 👀 So CAPWAP should not be restricted to IEEE 802.11e-based mapping. Main character energy means not being boxed in 💜
Protocol Requirement:
The CAPWAP protocol MUST map the IEEE 802.11e QoS priorities to equivalent QoS priorities across the switching and wireless medium segments.
Motivation and Protocol Benefits:
Okay so a protocol that handles the QoS side of WLAN systems delivers high performance, which is great for subscribers and for resource utilization efficiency 🌸 Since CAPWAP deals with WTPs directly and with the wireless medium indirectly, both of these need to be considered for performance.
On the wireless medium side, QoS aspects in the protocol enable high-quality communications within the domain of a WLAN controller. Each domain generally covers an enterprise or a group of service providers, so the effects are wide-ranging 🌈
Within the switching segment of CAPWAP, a QoS-enabled protocol minimizes the adverse effects of dynamic traffic characteristics, which keeps system-wide performance on track ✨
Relation to Problem Statement:
QoS control is critical to large WLANs and touches a bunch of aspects. This objective can help address the problem of managing dynamic conditions of the wireless medium 🧚
Also, traffic characteristics in large-scale WLANs are constantly changing. So network utilization becomes inefficient, and user experience gets unpredictable 😭
The interaction and coordination between the two aspects of system-wide QoS are therefore critical for performance 💖
5.1.8. CAPWAP Protocol Security 🔐
Classification: Security
Description:
This objective is all about keeping the CAPWAP protocol secure 🛡️
The CAPWAP protocol MUST first provide for the participating entities -- the WLAN controller and WTPs -- to be explicitly mutually authenticated. This is to make sure rogue elements can't get into the WLAN system. Rogue WTPs should not be allowed to breach legitimate WLANs, and rogue WLAN controllers should not be allowed to gain control of legitimate WTPs. For example, WTPs may need to regularly renew their authentication state with the WLAN controller, and the same goes for WLAN controllers 🙈
If authentication is performed via an authenticated key exchange, future knowledge of derived keys is not sufficient for authentication. Big deal, no shortcuts 💅
Any session keys used between the WLAN controller and WTPs MUST be mutually derived using entropy contributed by both parties. This way no one party has control over the resulting session keys 🫶
Once WTPs and the WLAN controller have been mutually authenticated, information exchanges between them must be secured against various security threats. So the CAPWAP protocol MUST provide integrity protection and replay protection. The protocol SHOULD provide confidentiality through encryption. This should cover illegitimate modifications to protocol exchanges, eavesdropping, and Denial of Service (DoS) attacks, among other potential compromises. So the protocol must provide confidentiality, integrity, and authenticity for those exchanges 🔥
As a result of realizing this objective, it should not be possible for individual WTP breaches to affect the security of the WLAN as a whole. So WTP misuse will be protected against 👑
Additionally, the key establishment protocol for authentication and securing CAPWAP exchanges must be designed to minimize the possibility of future compromises after the keys are established.
CAPWAP MUST NOT prevent the use of asymmetric authentication. The security considerations of such asymmetric authentication are described in the Security Considerations section 🙃
If the CAPWAP protocol meets the criteria to require automated key management per BCP 107 [RFC4107], then mutual authentication MUST be accomplished via an authenticated key exchange.
Protocol Requirement:
The CAPWAP protocol MUST support mutual authentication of WTPs and the centralized controller. It also MUST ensure that information exchanges are integrity protected and SHOULD ensure confidentiality through encryption.
Motivation and Protocol Benefits:
WLANs are showing up in critical parts of enterprise and consumer networks more and more 📈 In these contexts, protocol security is crucial to protect the privacy and integrity that network administrators and end-users expect. So securing the CAPWAP protocol has direct benefits for these concerns 💜
In many cases, the network path between a WTP and WLAN controller contains untrusted links. Rogue WTPs could use those links to get into the WLAN system. Rogue WLAN controllers could use them to take control of legitimate WTPs and their associated terminals, to redirect or compromise terminal traffic. This objective can help mitigate these security concerns 🛡️
Relation to Problem Statement:
Security problems in large-scale WLANs are detailed in the Problem Statement. These include complications from rogue WTPs and compromised interfaces between WTPs and the WLAN controller. The protocol security requirement addresses these problems and highlights why it's so important to protect against them 🧚
5.1.9. System-wide Security 🌍
Classification: Security
Description:
This objective puts its focus on security threats external to the centralized CAPWAP segment of a WLAN system 👀 So the spotlight is on rogue wireless clients and other illegitimate wireless interference. There are a number of specific external threats that need to be addressed within the CAPWAP framework 🫣
i. PMK Sharing
One part of this objective relates to recent discussions on Pairwise Master Key (PMK) sharing in the CAPWAP framework. It highlights the need to stop rogue wireless clients from exploiting this ambiguity. Any ambiguities arising from the CAPWAP framework must not become a cause for security breaches 🙅♀️
Protocol Requirement:
The design of the CAPWAP protocol MUST NOT allow for any compromises to the WLAN system by external entities.
Motivation and Protocol Benefits:
External threats to the centralized WLAN architecture are getting more and more serious, because wireless clients are so cheap now 💀 Since it's relatively inexpensive for rogue individuals to mount attacks, it's important that WLAN systems are protected against them. Adequate mechanisms to thwart these external threats will be of tremendous benefit to WLAN systems controlled and managed with the CAPWAP protocol 🏆
Relation to Problem Statement:
This objective is based on the security needs highlighted in the Problem Statement. The Problem Statement discusses the effects of the shared wireless medium, which represents the external aspects of the CAPWAP framework where certain threats can come from. The system-wide security objective addresses those threats in relation to the Problem Statement 🍓
5.1.10. IEEE 802.11i Considerations 🎀
Classification: Operations
Description:
The CAPWAP protocol must support authentication in the centralized WLAN architecture, where the authenticator and encryption points can live on distinct entities, i.e., WLAN controller or WTP 🧩 The Architecture Taxonomy shows a number of variants, in both local-MAC and split-MAC designs, where the authenticator sits at the WLAN controller and the encryption points are at the WTPs. The CAPWAP protocol must be applicable to these variants and allow authentication mechanisms and their constituent processes to be operable in these cases.
An important issue here is the exchange of key information when the authenticator and encryption points are on distinct entities. Take the case where IEEE 802.11i is used in a WLAN where the WLAN controller realizes the authenticator, some WTPs realize encryption (possibly local-MAC WTPs), and other WTPs rely on the WLAN controller for encryption (possibly split-MAC WTPs) 🤯
In that case, CAPWAP will first need to identify where the authenticator and encryption points are between each WLAN controller-WTP pair. This will likely be part of the initial WTP configuration. After that, the WTPs that realize encryption will need CAPWAP to exchange key information with the authenticator at the WLAN controller. For the WTPs that don't realize encryption, CAPWAP needs to adapt its control to bypass the key exchange phase 🙌
Honestly the centralized WLAN architecture is a totally different platform for authentication mechanisms compared to legacy WLANs, where a WTP realized both the authenticator and encryption roles 💅 So this objective highlights the need for CAPWAP to support authentication and key management in the centralized WLAN architecture.
Protocol Requirement:
The CAPWAP protocol MUST determine the exact structure of the centralized WLAN architecture in which authentication needs to be supported, i.e., the location of major authentication components. This may be achieved during WTP initialization, where major capabilities are distinguished.
The protocol MUST allow for the exchange of key information when authenticator and encryption roles are located in distinct entities.
Motivation and Protocol Benefits:
CAPWAP is focused on supporting IEEE 802.11-based WLANs right now. So the protocol needs to recognize the major distinction in WLAN design when it comes to the IEEE 802.11i authenticator and encryption points 🦋 This is a significant variation that the Architecture Taxonomy has highlighted. CAPWAP benefits by accommodating this major consideration from IEEE 802.11i ✨
These requirements are common to all authentication mechanisms over the centralized WLAN architecture, so they apply to IEEE 802.11i, Universal Access Method (UAM), and other mechanisms 🫶
Relation to Problem Statement:
The Problem Statement highlights that different WTP designs are available and that interoperability among them needs to be ensured 🤝 In this regard, the operational changes that happen when the IEEE 802.11i authenticator and encryption points are separated need to be accommodated within the CAPWAP protocol 💖
5.1.11. Interoperability Objective 🦋
Classification: Architecture
Description:
okay so there are two big designs for centralized WLANs, local-MAC and split-MAC 🎀 and since standards folks are focusing on these two, it's crucial that they can actually talk to each other 🫶
This objective for the CAPWAP protocol is about making sure WTPs of both local-MAC and split-MAC designs can interoperate inside a single WLAN ✨ so one WLAN controller can manage both types of WTPs using a single CAPWAP protocol 👑 supporting both designs takes a bunch of protocol aspects, periodt 💅
i. Capability negotiations between WLAN controller and WTPs
WTP designs differ in how much of the IEEE 802.11 MAC functionality each one actually handles 🤓 the big split, split-MAC vs. local-MAC, is all about how they process IEEE 802.11 MAC frames. So the CAPWAP protocol should include functionality that lets WTPs and the WLAN controller negotiate significant capabilities 🔥
As a first step, those negotiations could cover whether a WTP is split-MAC or local-MAC, since that tells you a lot about what it can do 💜
ii. Establishment of alternative interfaces
Capability differences between WTPs basically work like alternative interfaces to the WLAN controller 🦋 so the CAPWAP protocol should be capable of adapting its operations to the major different interfaces. The first case is accommodating the capability differences between local-MAC and split-MAC WTPs 🌸
The finer-grained definition of these interfaces will be based on AP functionality documents produced by the IEEE 802.11 AP Functionality (APF) Ad-Hoc Committee 📚
Protocol Requirement:
The CAPWAP protocol MUST include sufficient capabilities negotiations to distinguish between major types of WTPs 💖
Motivation and Protocol Benefits:
The benefits of this architecture objective are both technical and practical 🌈 first, local-MAC and split-MAC designs have a lot of overlap in their control operations. The Architecture Taxonomy tabulates the major common features of the two designs, so it's technically practical to devise one protocol that manages both types of devices ✨
Next, being able to run CAPWAP for both architectural designs makes it more appealing in practice, since it will have wider appeal 🫧
Also, the extra complexity from these alternative interfaces is marginal 🙌 so honestly the benefits of this objective will far outweigh the cost of realizing it.
Relation to Problem Statement:
Supporting both local-MAC and split-MAC WTPs is fundamental to addressing the Problem Statement 🎯 it's the basis for solving those problems uniformly across the major WLAN architectures, which is the ultimate aim of standardization efforts. Realizing this objective ensures a comprehensive set of mechanisms that address the challenges of large-scale WLAN deployments 🧚
5.1.12. Protocol Specifications 📜
Classification: General
Description:
WLAN equipment vendors need enough detail from protocol specifications that implementing them lets their gear stay compatible with other equipment running the same protocol 🫶 so it's important that the CAPWAP protocol specifications are reasonably complete enough to actually implement.
Protocol Requirement:
Any WTP or WLAN controller vendor, or any person, MUST be able to implement the CAPWAP protocol from the specification itself, and that means all such implementations are required to interoperate 🔥
Motivation and Protocol Benefits:
It's super helpful for WLAN equipment vendors to refer to one single set of specifications while implementing CAPWAP 💅 this eases and speeds up the development process.
Relation to Problem Statement:
This requirement is based on WG discussions that were determined to be important for CAPWAP 🌸
5.1.13. Vendor Independence 🦋
Classification: General
Description:
WLAN technologies develop so fast that equipment vendors are constantly modifying their devices 🚀 in lots of cases, the developments happen independently for WLAN controllers and WTPs. The CAPWAP protocol should not affect the independence of those device modifications 🙈
Protocol Requirement:
A WTP vendor SHOULD be able to make modifications to hardware without any WLAN controller vendor involvement 💜
Motivation and Protocol Benefits:
Independence in the type of hardware for WLAN equipment means new developments don't get in the way of protocol operation ✨
Relation to Problem Statement:
This requirement is based on WG discussions that were determined to be important for CAPWAP 🌈
5.1.14. Vendor Flexibility 🎀
Classification: General
Description:
The CAPWAP protocol must not be specified for one particular type of wireless MAC design 💅 it should be compatible with both local-MAC and split-MAC WTPs.
Protocol Requirement:
The CAPWAP protocol MUST NOT limit WTP vendors in their choice of local-MAC or split-MAC WTPs. It MUST be compatible with both types of WTPs 🫶
Motivation and Protocol Benefits:
This requirement makes sure WTP vendors have enough flexibility to pick whichever wireless MAC design they think is best for their deployments 👑
Relation to Problem Statement:
This requirement is based on WG discussions that were determined to be important for CAPWAP 🦋
5.1.15. NAT Traversal 🌐
Classification: General
Description:
WLAN deployments can have WTPs and the WLAN controller talking across Network Address Translators (NATs) 🧭 the CAPWAP protocol must be able to work across topologies that contain known NAT configurations. That means it needs appropriate discovery and identification mechanisms for NAT traversal.
Protocol Requirement:
The CAPWAP protocol MUST NOT prevent the operation of established methods of NAT traversal 🔓
Motivation and Protocol Benefits:
As WLANs become more widespread, topologies with NATs become more likely 🌸 so it's important that CAPWAP can be used inside those topologies. This requirement is all about making CAPWAP relevant for NAT traversal 💖
Relation to Problem Statement:
This requirement is based on WG discussions that were determined to be important for CAPWAP ✨
5.2. Desirable Objectives 🌟
These objectives have been determined to be desirable for a CAPWAP protocol, but they're not mandatory 💅 realizing them may help improve control of WLANs, but they don't need to be required for all networks or scenarios.
5.2.1. Multiple Authentication Mechanisms 🔐
Classification: Architecture
Description:
Shared WLAN infrastructure brings up the issue of multiple authentication mechanisms 🫧 that's because each logical group is likely to be tied to different service providers or WLAN domains, so the authentication needs within them will be different. Although CAPWAP is required to support IEEE 802.11i, it also needs to support other authentication mechanisms 👑 for example, one logical group might use IEEE 802.11i while another uses web authentication. CAPWAP must be able to operate in shared WLANs like that 🙌
Protocol Requirement:
The CAPWAP protocol MUST support different authentication mechanisms in addition to IEEE 802.11i 💜
Motivation and Protocol Benefits:
Supporting various authentication mechanisms makes the protocol flexible for lots of different deployments 🦋 so it won't mandate any particular mechanism that might not suit a given deployment.
Relation to Problem Statement:
This objective relates to the problem of management complexity 🎯 shared WLAN deployments make large networks easier to manage.
5.2.2. Support for Future Wireless Technologies 🔮
Classification: Architecture
Description:
Technology moves so fast that new advances have to be catered for in current analyses 🚀 one example is supporting new wireless technologies inside CAPWAP, such as IEEE 802.16. So the protocol should not rely on the specifics of IEEE 802.11 technology 🙈
Wherever CAPWAP protocol messages contain specific layer 2 information elements, the protocol definition needs to be extensible so those elements can be defined for specific layer 2 wireless protocols 🧩 this might mean assigning a layer 2 wireless protocol type and version field to the message PDU. Other wireless protocols that might be supported include, but aren't limited to, 802.16e, 802.15.x, etc. 🌈
Protocol Requirement:
CAPWAP protocol messages MUST be designed to be extensible for specific layer 2 wireless technologies. They should not be limited to carrying elements related to IEEE 802.11 🫶
Motivation and Protocol Benefits:
Extensible protocols are amazing bestie 💖 they can be applied in different networks and give way more scope. Plus, service providers need WLAN solutions that can meet current and future market requirements 💅
Relation to Problem Statement:
The Problem Statement describes some advances happening in other standards bodies like the IEEE 🎀 it's important for CAPWAP to reflect those advances and provide a framework where they can be supported ✨
5.2.3. Support for New IEEE Requirements 📡
Classification: Architecture
Description:
The IEEE 802.11 APF Ad-Hoc Committee has reviewed IEEE 802.11 functionality and made more thorough definitions for the new requirements 🤓 CAPWAP must be able to incorporate these definitions with minimal change. On top of that, a bunch of extensions for IEEE 802.11 are currently being standardized, and CAPWAP must also be able to incorporate those new extensions with minimal change 🔥
Protocol Requirement:
The CAPWAP protocol MUST be openly designed to support new IEEE 802.11 definitions and extensions 💜
Motivation and Protocol Benefits:
Lots of advances are being made within the IEEE about IEEE 802.11 functionality 🌸 since it's one of the major wireless technologies in use today, it'll be super beneficial for CAPWAP to incorporate the relevant new extensions 👑
Relation to Problem Statement:
The Problem Statement gives an overview of the IEEE 802.11 working group's task 🎯 this group focuses on defining the functional architecture of WTPs and new extensions for it, so CAPWAP needs to reflect those definitions and extensions 🫧
5.2.4. Interconnection Objective 🌐
Classification: Architecture 🧩
Description:
okay so bestie, big deployments are gonna use a whole bunch of different interconnection technologies between the devices in the network 🔗 which means CAPWAP should be able to run over different kinds of them. no cap, that's the vibe ✨
as a result of hitting this objective, the protocol will be able to run over both IPv4 and IPv6 🌈 and it'll also be built so it works inside tightly administered networks (think enterprise networks 🏢) or on open, public access networks 🌍. for example, VLAN tunnels can be used across different types of networks that CAPWAP runs over 🎀
Protocol Requirement:
The CAPWAP protocol MUST NOT be constrained to specific underlying transport mechanisms. 🙅♀️
Motivation and Protocol Benefits:
the main goal of CAPWAP is to get interoperability between all the various WTPs and WLAN controllers 💖 so the reason for this requirement is that the protocol should work no matter what interconnection technology is underneath it. iconic, right? 👑
Relation to Problem Statement:
the Problem Statement talks about how hard it is to configure large WLANs 😭 and picking which interconnection technologies to use for big deployments makes that even messier. this requirement takes some of that stress away by making the protocol's operation independent of the underlying transport 🫶
5.2.5. Access Control 🔐
Classification: Operations ⚙️
Description:
this objective is all about the info needed for WLAN access control 📇 and the part CAPWAP plays in carrying that info between WTPs and their WLAN controller 🚚
here are some specific info aspects that CAPWAP needs to carry:
i. IEEE 802.11 association and authentication 🦋
wireless clients have a different association process for their initial connection versus when they roam 🏃♀️💨 so access control needs specific context for each case. load balancing, QoS, security, and congestion info in both the wireless medium segments and the switching segments also need to be considered 📊
ii. WTP Access Control 🚪
it's not just about wireless clients, we also have to control which new WTPs get admitted 🛂 and given the threat of rogue WTPs 😈, it's super important for CAPWAP to pass along the right authentication info between new WTPs and the WLAN controller 🔑
Protocol Requirement:
The CAPWAP protocol MUST be capable of exchanging information required for access control of WTPs and wireless terminals. 💅
Motivation and Protocol Benefits:
because these deployments are so big, comprehensive access control is crucial 🙌 and how well access control works depends on the information it's based on. so this objective is super relevant to CAPWAP 💜
Relation to Problem Statement:
this objective tackles access control in large WLANs 🏗️ and it's basically about managing the complexity of those networks 🧠 when you've got the info from both the switching and wireless medium segments together, hitting this objective helps control and manage that complexity 🌸
5.3. Non-Objectives 🙅♀️
The following objectives were marked as non-objectives during working group consultations 🗣️ they got that label only in the context of CAPWAP and its considerations, so they may still be useful in other contexts 🌈
5.3.1. Support for Non-CAPWAP WTPs 🧃
Classification: Architecture 🧩
Description:
the CAPWAP protocol should provide an engine-mechanism to spring WTP auto-configuration and/or software version updates 🚀 and it should support integration with existing network management systems. a WLAN controller acting as a management agent is optional 💁♀️
if entities other than WLAN controllers manage some parts of WTPs, like software downloads 📦 the CAPWAP protocol may be used so WTPs can tell WLAN controllers about any changes those other entities made 📣
Protocol Requirement:
The CAPWAP protocol SHOULD be capable of recognizing legacy WTPs and existing network management systems. 🕰️
Motivation and Protocol Benefits:
it's expected that lots of centralized WLAN setups will be rolled out bit by bit alongside legacy systems 🧱 so the protocol needs to work in scenarios with mixed WLAN devices. mixing is the way 🫶
Relation to Problem Statement:
the Problem Statement calls out management complexity as a major issue with large WLANs 😵💫 and part of that complexity comes from rolling out centralized WLAN devices step by step, which is exactly where this objective applies 🎯
5.3.2. Technical Specifications 📜
Classification: General 🌷
Description:
the CAPWAP protocol must not require AC and WTP vendors to share technical specifications in order to be compatible 🙅♀️ the protocol specifications alone must be enough for compatibility ✨
Protocol Requirement:
WTP vendors SHOULD NOT have to share technical specifications for hardware and software with AC vendors in order for interoperability to be achieved. 🔒
Motivation and Protocol Benefits:
it's really helpful for WLAN equipment vendors to refer to one single set of specs while implementing CAPWAP 📚 which makes development easier and faster 🏃♀️💨
Relation to Problem Statement:
this requirement comes from WG discussions that were judged important for CAPWAP 🗨️
this objective was prioritized as a non-objective because it duplicates the Protocol Specifications objective (Section 5.1.12) 👯♀️
5.4. Operator Requirements 💼
The following objectives come from network service operators 📣 these are the requirements from the people who will actually deploy CAPWAP in their WLANs 🛜
5.4.1. AP Fast Handoff 🏎️
Classification: Operations ⚙️
Description:
network service operators think handoffs are crucial because their customers are always on the move 🚶♀️📱 so CAPWAP should not adversely affect AP fast-handoff procedures 🙏 the protocol may support optimizations for fast handoff procedures so it can better support real-time services during handoffs ⏱️📞
Protocol Requirement:
CAPWAP protocol operations MUST NOT impede or obstruct the efficacy of AP fast-handoff procedures. 🚫
6. Summary and Conclusion 🎀
The objectives in this document cover three main aspects of CAPWAP 💫 namely:
i. Architecture 🏛️ ii. Operations 🛠️ iii. Security 🔐
these requirements are all about focusing standardization on a simple, interoperable protocol for managing large-scale WLANs 🌐 the architecture requirements lay out the structural features of the protocol, like the WTP types (local-MAC and split-MAC) and WTP structures (logical groups) 🧱 the operations requirements deal with how WTPs get configured and managed ⚙️ and the security requirements cover the authentication and integrity side of protocol exchanges 🛡️
the objectives were also prioritized to show how immediately important they are for developing and evaluating an interoperable CAPWAP protocol 📊 the priorities are Mandatory and Accepted, Desirable, and Non-Objectives 🏷️ and they reflect working group consensus on how effective the requirements are for protocol design 🤝
on top of that, this document includes requirements from network service operators, based on their experience running large-scale WLANs 💼
the resulting requirements from this document will be used together with the CAPWAP Problem Statement [RFC3990] and the CAPWAP Architecture Taxonomy [RFC4118] to develop and evaluate an interoperable protocol for controlling and provisioning WTPs in large-scale WLANs 🧁
7. Security Considerations 🚨
The CAPWAP framework supports both local-MAC and split-MAC WTPs 🫧 when both types are used in the same deployment, it is crucial to make sure each one is secured according to its capabilities 🔏 the Architecture Taxonomy shows how different WTPs come with different levels of functionality 📖 development of the CAPWAP protocol should make sure that deploying both local-MAC and split-MAC WTPs within a single WLAN doesn't open loopholes for security compromises 😱
in shared WLAN deployments made of several logical groups, traffic from each group has to be kept separate 🚧 so beyond protocol exchanges, data traffic from wireless terminals should also be segregated by the logical groups they belong to 🧺 it should not be possible for data or control traffic from one logical group to stray into, or influence, another logical group 🙅♀️💥
using IEEE 802.11i over the centralized WLAN architecture allows implementations where the PMK is shared across WTPs 🔑 this creates ambiguity between legitimate sharing and illegitimate copies 👀 wireless terminals may unknowingly fall prey to this ambiguity, or exploit it 😬 the IEEE 802 and IETF liaisons are currently evaluating how to resolve this issue 🤔
the low cost of launching attacks on WLANs makes CAPWAP a target 🎯 a first step in guarding against any form of attack is to keep monitoring the WLAN for conditions that point to potential threats from rogue WTPs or wireless terminals 👁️ for example, profiles for DoS and replay attacks need to be considered so CAPWAP can effectively monitor security conditions 🛰️
the open environment of many WLAN deployments makes physical security breaches highly probable 🥺 compromises from theft and physical damage must be considered during protocol development 🔧 for instance, it should not be possible for a single compromised WTP to affect the WLAN as a whole 🧯
considering asymmetric, non-mutual authentication between WTPs and the WLAN controller, there is a risk of a rogue participant exploiting that setup 🦹♀️ it is preferable to avoid non-mutual authentication 🚫 in some cases, the legitimacy of the protocol exchange participants can be verified externally, for example by physical containment within a close environment 🏠 asymmetric authentication may be appropriate there without risk of security compromises ✅
8. Acknowledgements 💌
the authors want to thank the working group chairs, Dorothy Gellert and Mahalingam Mani, for their support and patience with this document 🥰 they also want to thank the working group participants who helped shape the objectives 🫶 in particular, the authors thank James Kempf, Pat Calhoun, Inderpreet Singh, Dan Harkins, T. Sridhar, Charles Clancy, and Emek Sadot for their invaluable inputs 👑 the authors also extend gratitude to the IEEE 802.11 Ad-Hoc Committee for evaluating the document 🙌 and they acknowledge contributions from Meimei Dang, Satoshi Iino, Mikihito Sugiura, and Dong Wang 💖
9. Normative References ✨
okay bestie, these are the must-reads 💅 Pull these up before you touch anything else.
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 🌸 This is the one that explains those capital-letter key words, iykyk.
- [RFC3990] O'Hara, B., Calhoun, P., and J. Kempf, "Configuration and Provisioning for Wireless Access Points (CAPWAP) Problem Statement", RFC 3990, February 2005. 🦋
- [RFC4118] Yang, L., Zerfos, P., and E. Sadot, "Architecture Taxonomy for Control and Provisioning of Wireless Access Points (CAPWAP)", RFC 4118, June 2005. 🧚
10. Informative References 📚
these ones are the extra context, super helpful but not the core rules ✨
- [802.11] IEEE Standard 802.11, "Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", June 2003. 📶
- [802.11i] IEEE Standard 802.11i, "Medium Access Control (MAC) Security Enhancements", July 2004. 🔐
- [802.11e] IEEE Standard 802.11e, "Medium Access Control (MAC) Quality of Service Enhancements", November 2005. 💜
- [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, June 2005. 🗝️
Authors' Addresses 🫶
the squad behind this doc, and where to find them 💖
Saravanan Govindan
Panasonic Singapore Laboratories
Block 1022, Tai Seng Industrial Estate
#06-3530, Tai Seng Avenue
Singapore 534 415
Singapore
Phone: +65 6550 5441
EMail: saravanan.govindan@sg.panasonic.comZhonghui Yao
Huawei Longgang Production Base
Shenzhen 518 129
P. R. China
Phone: +86 755 2878 0808
EMail: yaoth@huawei.comWenhui Zhou
China Mobile
53A, Xibianmen Ave, Xuanwu District
Beijing 100 053
P. R. China
Phone: +86 10 6600 6688 ext.3061
EMail: zhouwenhui@chinamobile.comL. Lily Yang
Intel Corp.
JF3-206, 2111 NE 25th Ave.
Hilsboro, OR 97124
USA
Phone: +1 503 264 8813
EMail: lily.l.yang@intel.comHong Cheng
Panasonic Singapore Laboratories
Block 1022, Tai Seng Industrial Estate
#06-3530, Tai Seng Avenue
Singapore 534 415
Singapore
Phone: +65 6550 5447
EMail: hong.cheng@sg.panasonic.comFull Copyright Statement 🌈
Copyright (C) The Internet Society (2006).
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 🔥
okay, so the IETF doesn't take a side on whether any IPR claims cover the tech in this doc, or whether you can get a license for it. It also doesn't claim it went looking for any of that stuff. If you want the rules about rights in RFCs, check out BCP 78 and BCP 79 📜
Copies of IPR disclosures sent to the IETF Secretariat, plus any assurances of licenses, or the results of any attempt to get a general license or permission for implementers or users of this spec, can be found in the IETF online IPR repository at http://www.ietf.org/ipr. 🔍
The IETF also invites anyone to flag 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 🙏
Funding for the RFC Editor function comes from the IETF Administrative Support Activity (IASA). Thank you, IASA, you're the real MVP ✨👑
📦 where this page comes from
- ietf: rfc4564 2006-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms