Network Working Group S. Kelly
Request for Comments: 5418 Aruba Networks
Category: Informational T. Clancy
LTS
March 2009
Network Working Group S. Kelly
Request for Comments: 5418 Aruba Networks
Category: Informational T. Clancy
LTS
March 2009
Control And Provisioning of Wireless Access Points (CAPWAP) Threat Analysis for IEEE 802.11 Deployments
IEEE 802.11部署中无线接入点（CAPWAP）威胁分析的控制和配置
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束(http://trustee.ietf.org/license-info). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Abstract
摘要
Early Wireless Local Area Network (WLAN) deployments feature a "fat" Access Point (AP), which serves as a stand-alone interface between the wired and wireless network segments. However, this model raises scaling, mobility, and manageability issues, and the Control and Provisioning of Wireless Access Points (CAPWAP) protocol is meant to address these issues. CAPWAP effectively splits the fat AP functionality into two network elements, and the communication channel between these components may traverse potentially hostile hops. This document analyzes the security exposure resulting from the introduction of CAPWAP and summarizes the associated security considerations for IEEE 802.11-based CAPWAP implementations and deployments.
早期的无线局域网（WLAN）部署以“fat”接入点（AP）为特征，该接入点充当有线和无线网段之间的独立接口。然而，这种模式带来了可扩展性、移动性和可管理性问题，而无线接入点（CAPWAP）协议的控制和配置就是为了解决这些问题。CAPWAP有效地将fat AP功能拆分为两个网络元素，这些组件之间的通信信道可能会穿越潜在的恶意跳。本文档分析了CAPWAP引入带来的安全风险，并总结了基于IEEE 802.11的CAPWAP实施和部署的相关安全注意事项。
Table of Contents
目录
1. Introduction ....................................................4
1.1. Rationale for Limiting Analysis Scope to IEEE 802.11 .......5
1.2. Notations ..................................................6
2. Abbreviations and Definitions ...................................7
3. CAPWAP Security Goals for IEEE 802.11 Deployments ...............8
4. Overview of IEEE 802.11 and AAA Security ........................8
4.1. IEEE 802.11 Authentication and AAA .........................9
4.2. IEEE 802.11 Link Security .................................11
4.3. AAA Security ..............................................11
4.4. Cryptographic Bindings ....................................12
5. Structure of the Analysis ......................................13
6. Representative CAPWAP Deployment Scenarios .....................14
6.1. Preliminary Definitions ...................................14
6.1.1. Split MAC ..........................................15
6.1.2. Local MAC ..........................................15
6.1.3. Remote MAC .........................................15
6.1.4. Data Tunneling .....................................16
6.2. Example Scenarios .........................................16
6.2.1. Localized Modular Deployment .......................16
6.2.2. Internet Hotspot or Temporary Network ..............17
6.2.3. Distributed Deployments ............................18
6.2.3.1. Large Physically Contained Organization ...18
6.2.3.2. Campus Deployments ........................18
6.2.3.3. Branch Offices ............................18
6.2.3.4. Telecommuter or Remote Office .............19
7. General Adversary Capabilities .................................19
7.1. Passive versus Active Adversaries .........................20
8. Vulnerabilities Introduced by CAPWAP ...........................22
8.1. The Session Establishment Phase ...........................22
8.1.1. The Discovery Phase ................................22
8.1.2. Forming an Association (Joining) ...................23
1. Introduction ....................................................4
1.1. Rationale for Limiting Analysis Scope to IEEE 802.11 .......5
1.2. Notations ..................................................6
2. Abbreviations and Definitions ...................................7
3. CAPWAP Security Goals for IEEE 802.11 Deployments ...............8
4. Overview of IEEE 802.11 and AAA Security ........................8
4.1. IEEE 802.11 Authentication and AAA .........................9
4.2. IEEE 802.11 Link Security .................................11
4.3. AAA Security ..............................................11
4.4. Cryptographic Bindings ....................................12
5. Structure of the Analysis ......................................13
6. Representative CAPWAP Deployment Scenarios .....................14
6.1. Preliminary Definitions ...................................14
6.1.1. Split MAC ..........................................15
6.1.2. Local MAC ..........................................15
6.1.3. Remote MAC .........................................15
6.1.4. Data Tunneling .....................................16
6.2. Example Scenarios .........................................16
6.2.1. Localized Modular Deployment .......................16
6.2.2. Internet Hotspot or Temporary Network ..............17
6.2.3. Distributed Deployments ............................18
6.2.3.1. Large Physically Contained Organization ...18
6.2.3.2. Campus Deployments ........................18
6.2.3.3. Branch Offices ............................18
6.2.3.4. Telecommuter or Remote Office .............19
7. General Adversary Capabilities .................................19
7.1. Passive versus Active Adversaries .........................20
8. Vulnerabilities Introduced by CAPWAP ...........................22
8.1. The Session Establishment Phase ...........................22
8.1.1. The Discovery Phase ................................22
8.1.2. Forming an Association (Joining) ...................23
8.2. The Connected Phase .......................................23
9. Adversary Goals in CAPWAP ......................................24
9.1. Eavesdrop on AC-WTP Traffic ...............................24
9.2. WTP Impersonation and/or Rootkit Installation .............25
9.3. AC Impersonation and/or Rootkit Installation ..............26
9.4. Other Goals or Sub-Goals ..................................26
10. Countermeasures and Their Effects .............................27
10.1. Communications Security Elements .........................27
10.1.1. Mutual Authentication .............................27
10.1.1.1. Authorization ............................27
10.1.2. Data Origin Authentication ........................29
10.1.3. Data Integrity Verification .......................29
10.1.4. Anti-Replay .......................................29
10.1.5. Confidentiality ...................................29
10.2. Putting the Elements Together ............................30
10.2.1. Control Channel Security ..........................30
10.2.2. Data Channel Security .............................30
11. Countermeasures Provided by DTLS ..............................30
12. Issues Not Addressed By DTLS ..................................31
12.1. DoS Attacks ..............................................31
12.2. Passive Monitoring (Sniffing) ............................32
12.3. Traffic Analysis .........................................32
12.4. Active MitM Interference .................................32
12.5. Other Active Attacks .....................................32
13. Security Considerations .......................................32
14. Acknowledgements ..............................................32
15. References ....................................................33
15.1. Normative References .....................................33
15.2. Informative References ...................................33
8.2. The Connected Phase .......................................23
9. Adversary Goals in CAPWAP ......................................24
9.1. Eavesdrop on AC-WTP Traffic ...............................24
9.2. WTP Impersonation and/or Rootkit Installation .............25
9.3. AC Impersonation and/or Rootkit Installation ..............26
9.4. Other Goals or Sub-Goals ..................................26
10. Countermeasures and Their Effects .............................27
10.1. Communications Security Elements .........................27
10.1.1. Mutual Authentication .............................27
10.1.1.1. Authorization ............................27
10.1.2. Data Origin Authentication ........................29
10.1.3. Data Integrity Verification .......................29
10.1.4. Anti-Replay .......................................29
10.1.5. Confidentiality ...................................29
10.2. Putting the Elements Together ............................30
10.2.1. Control Channel Security ..........................30
10.2.2. Data Channel Security .............................30
11. Countermeasures Provided by DTLS ..............................30
12. Issues Not Addressed By DTLS ..................................31
12.1. DoS Attacks ..............................................31
12.2. Passive Monitoring (Sniffing) ............................32
12.3. Traffic Analysis .........................................32
12.4. Active MitM Interference .................................32
12.5. Other Active Attacks .....................................32
13. Security Considerations .......................................32
14. Acknowledgements ..............................................32
15. References ....................................................33
15.1. Normative References .....................................33
15.2. Informative References ...................................33
Wireless Local Area Network (WLAN) deployments are increasingly common as the technology matures and wireless interface chips become standard equipment in laptops and various hand-held computing devices. In the simplest deployments, WLAN access is entirely provided by a wireless Access Point (AP), which bridges the client system (station or "STA") and the Distribution System (DS) or wired network.
随着技术的成熟和无线接口芯片成为笔记本电脑和各种手持计算设备的标准设备，无线局域网（WLAN）部署越来越普遍。在最简单的部署中，WLAN接入完全由无线接入点（AP）提供，该接入点连接客户端系统（站或“STA”）和配电系统（DS）或有线网络。
+------+
|client| +--------+ |
|(STA) | | Access | | +------+
+------+ ) ) ) ) | Point |-----| /optional\ +-------+
/ / +--------+ |--( L3 )---| AAA |
+------+ | \ cloud / +-------+
| +------+
+------+
|client| +--------+ |
|(STA) | | Access | | +------+
+------+ ) ) ) ) | Point |-----| /optional\ +-------+
/ / +--------+ |--( L3 )---| AAA |
+------+ | \ cloud / +-------+
| +------+
Figure 1: IEEE 802.11 Deployment Using RSN
图1：使用RSN的IEEE 802.11部署
In this architecture, the AP serves as a gatekeeper, facilitating client access to the network. Typically, the client must somehow authenticate prior to being granted access, and in enterprise deployments, this is frequently accomplished using [8021X]. When using IEEE 802.11, this mode is called a Robust Security Network (RSN) [80211I]. Here, the client is called the "supplicant", the AP is the "authenticator", and either the AP or an external Authentication, Authorization, and Accounting (AAA) server fulfill the role of "authentication server", depending on the authentication mechanism used.
在这种体系结构中，AP充当网守，方便客户端访问网络。通常，客户端在被授予访问权限之前必须以某种方式进行身份验证，在企业部署中，这通常使用[8021X]来完成。当使用IEEE 802.11时，这种模式称为健壮安全网络（RSN）[80211I]。这里，客户端被称为“请求者”，AP是“认证者”，AP或外部认证、授权和计费（AAA）服务器根据使用的认证机制履行“认证服务器”的角色。
From the perspective of the network administrator, the wired LAN to which the AP is attached is typically considered to be more trusted than the wireless LAN, either because there is some physical boundary around the wired segment (i.e., the building walls), or because it is otherwise secured somehow (perhaps cryptographically). The AAA server may reside within this same physical administrative domain, or it may be remote. Common AAA protocols are RADIUS [RFC3579] and Diameter [RFC4072].
从网络管理员的角度来看，AP连接到的有线LAN通常被认为比无线LAN更可信，这是因为有线段（即，建筑物墙壁）周围存在一些物理边界，或者是因为它以某种方式（可能是加密方式）被保护。AAA服务器可能位于同一物理管理域内，也可能是远程的。常见的AAA协议是RADIUS[RFC3579]和Diameter[RFC4072]。
The CAPWAP protocol [RFC5415] modifies this architecture by splitting the AP into two pieces, the Wireless Termination Point (WTP), and the Access Controller (AC), and creating a communications link between the two new components. In this model, the WTP implements the WLAN edge functions with respect to the user (wireless transmit/receive), while the AC implements the wired-side edge functions. For a complete description of CAPWAP architecture, see [RFC4118].
CAPWAP协议[RFC5415]通过将AP分为两部分，即无线终端点（WTP）和接入控制器（AC），并在两个新组件之间创建通信链路来修改此架构。在此模型中，WTP实现与用户相关的WLAN边缘功能（无线发送/接收），而AC实现有线侧边缘功能。有关CAPWAP体系结构的完整说明，请参阅[RFC4118]。
+------+ +==========================+
|client| | +---+ | | +------+
|(STA) | | +-----+ / L3 \ +----+ | | /optional\ +-----+
+------+ ) )|)| WTP |-( cloud )-| AC |-|---|--( L3 )--| AAA |
/ / | +-----+ \ / +----+ | | \ cloud / +-----+
+------+ | +---+ | | +------+
+==========================+
AP equivalence boundary
+------+ +==========================+
|client| | +---+ | | +------+
|(STA) | | +-----+ / L3 \ +----+ | | /optional\ +-----+
+------+ ) )|)| WTP |-( cloud )-| AC |-|---|--( L3 )--| AAA |
/ / | +-----+ \ / +----+ | | \ cloud / +-----+
+------+ | +---+ | | +------+
+==========================+
AP equivalence boundary
Figure 2: WLAN Deployment utilizing CAPWAP
图2：利用CAPWAP的WLAN部署
For our purposes, it is useful to think of the entire CAPWAP system as a sort of "AP equivalent", and the figure above illustrates this concept. With this model in mind, our ideal is to ensure that CAPWAP introduces no vulnerabilities that aren't present in the original fat AP scenario. As we will see, this is not entirely possible, but from a security perspective, we should nonetheless strive to achieve this equivalence as nearly as we can.
出于我们的目的，将整个CAPWAP系统视为一种“AP等价物”是很有用的，上图说明了这一概念。考虑到这个模型，我们的理想是确保CAPWAP不会引入原始fat AP场景中不存在的漏洞。正如我们将看到的那样，这并非完全可能，但从安全角度来看，我们应该尽可能努力实现这种等价性。
Although CAPWAP derives from protocols that were designed explicitly for management of IEEE 802.11 wireless LANs, it may also turn out to be useful for managing other types of network device deployments, wireless and otherwise. This might lead one to conclude that a single security analysis, except for minor per-binding variations, might be sufficient. However, based on a limited number of additional related scenarios that have been described as likely candidates for CAPWAP thus far, e.g., use with Radio Frequency Identification (RFID) sensors, this does not seem to be a simple, binary decision.
尽管CAPWAP源自专门为管理IEEE 802.11无线局域网而设计的协议，但它也可能对管理其他类型的网络设备部署（无线或其他）非常有用。这可能会导致人们得出结论，一个单一的安全性分析，除了每个绑定的微小变化外，可能就足够了。然而，根据迄今为止被描述为CAPWAP可能候选方案的有限数量的其他相关场景，例如，与射频识别（RFID）传感器一起使用，这似乎不是一个简单的二元决策。
Contrasting RFID and IEEE 802.11 deployment scenarios, IEEE 802.11 users typically authenticate to some a back-end AAA server, and as a result of that exchange, derive cryptographic keys that are used by the STA and WTP to encrypt and authenticate over-air communications. That is, the threat environment is such that the following typically holds:
与RFID和IEEE 802.11部署场景相比，IEEE 802.11用户通常向某个后端AAA服务器进行身份验证，并且作为交换的结果，派生出STA和WTP用于加密和验证空中通信的加密密钥。也就是说，威胁环境通常包含以下内容：
o The user is not immediately trusted, and therefore must authenticate.
o 用户不立即受信任，因此必须进行身份验证。
o The WTP is not immediately trusted, and therefore must indirectly authenticate to the user via the AAA server.
o WTP不立即受信任，因此必须通过AAA服务器间接向用户进行身份验证。
o The AAA server is not necessarily trusted, and therefore must authenticate.
o AAA服务器不一定受信任，因此必须进行身份验证。
o The medium is not trusted, and therefore communications must be secured.
o 介质不受信任，因此必须确保通信安全。
RFID tags, on the other hand, typically do not have the same authentication, confidentiality, and integrity requirements as the principals in a WLAN deployment, and are not, generally speaking, well suited to environments in which similar threats exist. As a result of the combination of WLAN security requirements and the Medium Access Control (MAC)-splitting behavior that epitomizes the IEEE 802.11 binding for CAPWAP, there are definite security-related considerations in the WLAN case that simply do not exist for an RFID-based adaptation of CAPWAP.
另一方面，RFID标签通常不具有与WLAN部署中的主体相同的身份验证、机密性和完整性要求，并且通常不适合存在类似威胁的环境。由于WLAN安全要求和媒体访问控制（MAC）拆分行为的结合，这些行为概括了CAPWAP的IEEE 802.11绑定，因此在WLAN情况下，存在明确的安全相关考虑因素，而基于RFID的CAPWAP适配根本不存在。
Now, there certainly are similarities and overlapping security considerations that will apply to any CAPWAP deployment scenario. For example, authentication of the AC for purposes of WTP device management operations is probably always important. Even so, the threats to RFID are different enough to suggest the need for a separate security analysis in that case. For example, since RFID tags commonly deployed today implement no over-air authentication, integrity, or confidentiality mechanisms, the need for similar mechanisms between the WTP and AC for RFID tag data communications is not clearly indicated -- that is, the threats are different.
现在，在任何CAPWAP部署场景中都肯定存在相似和重叠的安全注意事项。例如，出于WTP设备管理操作的目的对AC进行认证可能总是很重要的。即便如此，RFID所面临的威胁也大不相同，因此需要对这种情况进行单独的安全分析。例如，由于目前普遍部署的RFID标签没有空中认证、完整性或保密机制，因此WTP和AC之间对于RFID标签数据通信的类似机制的需求没有明确指出——也就是说，威胁是不同的。
We have limited visibility into the varied ways in which CAPWAP might be adapted in the future, although we may observe that it seems to provide the basis for a generalized scalable provisioning protocol. Given our currently limited view of the technologies for which it might be used, it seems prudent to recognize that our current view is colored by the IEEE 802.11 roots of the protocol, and make that recognition explicit in our analysis. If newly added bindings turn out to be substantially similar to IEEE 802.11, then the associated binding documents can simply reference this document in their security considerations, while calling out any substantive differences. However, it does appear, based on our current limited visibility, that per-binding threat analyses will be required.
我们对CAPWAP在未来可能采用的各种方式的了解有限，尽管我们可能会观察到它似乎为通用的可伸缩供应协议提供了基础。鉴于我们目前对可能使用该协议的技术的看法有限，明智的做法是认识到我们当前的观点受到协议的IEEE 802.11根的影响，并在我们的分析中明确认识到这一点。如果新添加的绑定与IEEE 802.11基本相似，那么相关的绑定文档可以在其安全性考虑中简单地引用此文档，同时指出任何实质性差异。然而，基于我们目前有限的可视性，似乎确实需要进行每绑定威胁分析。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
o AAA - Authentication Authorization and Accounting
o AAA-认证授权和记帐
o AC - Access Controller
o 交流存取控制器
o AES-CCMP - Advanced Encryption Standard - Counter-mode CBC MAC Protocol
o AES-CCMP-高级加密标准-计数器模式CBC MAC协议
o AP - (wireless) Access Point
o AP-（无线）接入点
o CAPWAP - Control And Provisioning of Wireless Access Points
o CAPWAP-无线接入点的控制和配置
o Cert - X509v3 Certificate
o 证书-X509v3证书
o DIAMETER - proposed successor to RADIUS protocol (see below)
o DIAMETER——RADIUS协议的拟议后续协议（见下文）
o DoS - Denial of Service (attack)
o 拒绝服务-拒绝服务（攻击）
o DTLS - Datagram Transport Layer Security
o DTLS-数据报传输层安全性
o EAP - Extensible Authentication Protocol
o 可扩展认证协议
o MitM - Man in the Middle
o 中间人
o PMK - Pairwise Master Key
o PMK-成对主密钥
o PSK - Pre-Shared Key
o PSK-预共享密钥
o RADIUS - Remote Authentication Dial-In User Service
o RADIUS-远程身份验证拨入用户服务
o STA - (wireless) STAtion
o STA-（无线）站
o TK - Transient Key
o TK-瞬态密钥
o TKIP - Temporal Key Integrity Protocol
o 时间密钥完整性协议
o WEP - Wired Equivalent Privacy
o 有线等效隐私
o WLAN - Wireless Local Area Network
o 无线局域网
o WTP - Wireless Termination Point
o 无线终端点
When deployed for use with IEEE 802.11, CAPWAP should avoid introducing any system security degradation as compared to the fat AP scenario. However, by splitting the AP functions between the WTP and AC, CAPWAP places potentially sensitive protocol interactions that were previously internal to the AP onto the Layer 3 (L3) network between the AC and WTP. Therefore, the security properties of this new system are dependent on the security properties of the intervening network, as well as on the details of the split.
当部署用于IEEE 802.11时，与fat AP方案相比，CAPWAP应避免引入任何系统安全降级。然而，通过在WTP和AC之间拆分AP功能，CAPWAP将以前AP内部的潜在敏感协议交互放置在AC和WTP之间的第3层（L3）网络上。因此，这个新系统的安全特性取决于介入网络的安全特性以及拆分的细节。
Since CAPWAP does not directly interact with over-air or AAA protocols, these are mostly out of scope for this analysis. That is, we do not analyze the basic AAA or IEEE 802.11 security protocols directly here, as CAPWAP does not modify these protocols in any way, nor do they directly interact with CAPWAP. However, by splitting AP functionality, CAPWAP may expose security elements of these protocols that would not otherwise be exposed. In such cases, CAPWAP should explicitly avoid degrading the security of these protocols in any way when compared to the fat AP scenario.
由于CAPWAP不直接与空中或AAA协议交互，因此这些协议大多不在本分析的范围之内。也就是说，我们在此不直接分析基本AAA或IEEE 802.11安全协议，因为CAPWAP不会以任何方式修改这些协议，也不会直接与CAPWAP交互。但是，通过拆分AP功能，CAPWAP可能会公开这些协议中不会公开的安全元素。在这种情况下，与fat AP方案相比，CAPWAP应明确避免以任何方式降低这些协议的安全性。
While this document is not directly concerned with IEEE 802.11 or AAA security, there are some subtle interactions introduced by CAPWAP, and there will be related terminology we must touch on in discussing these. The following figure illustrates some of the complex relationships between the various protocols, and illustrates where CAPWAP sits:
虽然本文档与IEEE 802.11或AAA安全性没有直接关系，但CAPWAP引入了一些微妙的交互，在讨论这些交互时，我们必须涉及相关术语。下图说明了各种协议之间的一些复杂关系，并说明了CAPWAP的位置：
+-----+ RADIUS/Diameter
| AAA |<==============\\
+-----+ ||
| ||
+-----------+------------+ ||
| | ||
+-----+ +----+ ||
| AC | | AC |<==//
+-----+ +----+
+---| |---+ +---| |---+
| | | |
| | | CAPWAP |
+-----+ +-----+ +-----+ +-----+
| WTP | | WTP | | WTP | | WTP |
+-----+ +-----+ +-----+ +-----+
^ ^^^
^^ ^^^ 802.11i,
^^ ^^ 802.1X, WPA,
+-----+ +-----+ WEP
| STA | | STA |
+-----+ +-----+
/ / / /
+-----+ +-----+
+-----+ RADIUS/Diameter
| AAA |<==============\\
+-----+ ||
| ||
+-----------+------------+ ||
| | ||
+-----+ +----+ ||
| AC | | AC |<==//
+-----+ +----+
+---| |---+ +---| |---+
| | | |
| | | CAPWAP |
+-----+ +-----+ +-----+ +-----+
| WTP | | WTP | | WTP | | WTP |
+-----+ +-----+ +-----+ +-----+
^ ^^^
^^ ^^^ 802.11i,
^^ ^^ 802.1X, WPA,
+-----+ +-----+ WEP
| STA | | STA |
+-----+ +-----+
/ / / /
+-----+ +-----+
Figure 3: CAPWAP Protocol Hierarchy
图3:CAPWAP协议层次结构
CAPWAP is being inserted between the 802.ll link security mechanism and the authentication server communication, so to provide supporting context, we give a very brief overview of IEEE 802.11 and AAA security below. It is very important to note that we only cover those topics that are relevant to our discussion, so what follows is not by any means exhaustive. For more detailed coverage of IEEE 802.11-related security topics, see e.g., [80211SEC].
CAPWAP被插入802.ll链路安全机制和身份验证服务器通信之间，因此为了提供支持上下文，我们在下面简要概述IEEE 802.11和AAA安全。非常重要的是要注意，我们只涉及与我们讨论相关的主题，因此下面的内容并不详尽。有关IEEE 802.11相关安全主题的更多详细内容，请参见[80211SEC]。
IEEE 802.11 provides for multiple methods of authentication prior to granting access to the network. In the simplest case, open authentication is used, and this is equivalent to no authentication. However, if IEEE 802.11 link security is to be provided, then some sort of authentication is required in order to bootstrap the trust relationship that underlies the associated key establishment process.
IEEE 802.11在授予网络访问权之前提供了多种身份验证方法。在最简单的情况下，使用开放式身份验证，这相当于没有身份验证。但是，如果要提供IEEE 802.11链路安全性，则需要某种身份验证，以便引导相关密钥建立过程中的信任关系。
This authentication can be implemented through use of a shared secret. In such cases, the authentication may be implicitly tied to the link security mechanism, (e.g., when Wired Equivalent Privacy (WEP) is used with open authentication), or it may be explicit, e.g., when Wi-fi Protected Access is used with a Pre-Shared Key (WPA-PSK).
这种身份验证可以通过使用共享秘密来实现。在这种情况下，认证可以隐式地绑定到链路安全机制（例如，当有线等效隐私（WEP）与开放认证一起使用时），或者认证可以是显式的，例如，当Wi-fi保护访问与预共享密钥（WPA-PSK）一起使用时。
In other cases, authentication requires an explicit cryptographic exchange, and this operation bootstraps link security. In most such cases, IEEE 802.1X is used in conjunction with the Extensible Authentication Protocol [RFC3748] to authenticate either the client or both the client and the authentication server. This exchange produces cryptographic keying material for use with IEEE 802.11 security mechanisms.
在其他情况下，身份验证需要显式加密交换，此操作将引导链接安全性。在大多数此类情况下，IEEE 802.1X与可扩展认证协议[RFC3748]结合使用，以认证客户端或客户端和认证服务器。此交换生成用于IEEE 802.11安全机制的加密密钥材料。
The resulting trust relationships are complex, as can be seen from the following (simplified) figure:
由此产生的信任关系是复杂的，如下图（简化）所示：
/--------------------------------------------\
| TK (6) | EAP Credentials,
V /--------------\ | PMK (3)
+------+ | PSK/Cert(1) | |
|client| V | V
|(STA) | +--------+ | v | +-----+
+------+ ) ) ) ) | WTP |-----| +----+ |--| AAA |
/ / +--------+ |--| AC |--| +-----+
+------+ ^ | +----+ | ^
^ ^ | ^ ^ (2,4) |
| | PTK (7) | | \----------/
| \----------------/ | Radius PSK,
\-----------------------------------/ PMK
4-Way Handshake (w/PMK) (5)
/--------------------------------------------\
| TK (6) | EAP Credentials,
V /--------------\ | PMK (3)
+------+ | PSK/Cert(1) | |
|client| V | V
|(STA) | +--------+ | v | +-----+
+------+ ) ) ) ) | WTP |-----| +----+ |--| AAA |
/ / +--------+ |--| AC |--| +-----+
+------+ ^ | +----+ | ^
^ ^ | ^ ^ (2,4) |
| | PTK (7) | | \----------/
| \----------------/ | Radius PSK,
\-----------------------------------/ PMK
4-Way Handshake (w/PMK) (5)
Figure 4: Trust Relationships
图4：信任关系
The following describes each of the relationships:
以下描述了每种关系：
1. WTP and AC establish secure link
1. WTP和AC建立安全链接
2. AC establishes secure link with AAA server
2. AC与AAA服务器建立安全链接
3. STA and AAA server conduct EAP, produce PMK
3. STA和AAA服务器执行EAP，产生PMK
4. AAA server pushes PMK to AC
4. AAA服务器将PMK推送到AC
5. AC and STA conduct 4-way handshake (producing TK, among other keys)
5. AC和STA进行4路握手（产生TK等键）
6. AC pushes TK to WTP (if decentralized encryption is used)
6. AC将TK推送到WTP（如果使用分散加密）
7. WTP/STA use TK for IEEE 802.11 link security
7. WTP/STA使用TK实现IEEE 802.11链路安全
The current CAPWAP binding for IEEE 802.11 primarily supports the use of IEEE 802.11i [80211I] security on the wireless link. However, since IEEE 802.11i does not prohibit the use of WEP for link security, neither does CAPWAP. Nonetheless, use of WEP with CAPWAP is NOT RECOMMENDED.
当前针对IEEE 802.11的CAPWAP绑定主要支持在无线链路上使用IEEE 802.11i[80211I]安全性。然而，由于IEEE 802.11i并不禁止使用WEP进行链路安全，CAPWAP也不禁止。尽管如此，不建议将WEP与CAPWAP结合使用。
If WEP is used with CAPWAP, the CAPWAP system will inherit all the security problems associated with the use of WEP in any wireless network. In particular, 40-bit keys can be subject to brute-force attacks, and statistical attacks can be used to crack session keys of any length after enough packets have been collected [WEPSEC]. As of late 2008, such attacks are trivial, and take mere seconds to accomplish.
如果WEP与CAPWAP一起使用，CAPWAP系统将继承与在任何无线网络中使用WEP相关的所有安全问题。特别是，40位密钥可能受到暴力攻击，并且统计攻击可用于在收集足够的数据包后破解任意长度的会话密钥[WEPSEC]。截至2008年底，此类攻击微不足道，只需几秒钟即可完成。
Newer link security mechanisms described in IEEE 802.11i, including TKIP and AES-CCMP, significantly improve the security of wireless networks. It is strongly RECOMMENDED that CAPWAP only be used with these newer techniques.
IEEE 802.11i中描述的更新的链路安全机制，包括TKIP和AES-CCMP，显著提高了无线网络的安全性。强烈建议CAPWAP仅与这些较新的技术一起使用。
The only slight insecurity introduced by CAPWAP when using it with IEEE 802.11i is the handling of the KeyRSC counter. When performing decentralized encryption, this value is maintained by the WTP, but needed by the AC to perform the 4-way handshake. The value used during the handshake initializes the counter on the client. In CAPWAP, this value is initialized to zero, allowing the possibility for replay attacks of broadcast traffic in the window between initial authentication and the client receiving the first valid broadcast packet from the WTP. This slight window of attack has been documented in [RFC5416].
当CAPWAP与IEEE 802.11i一起使用时，唯一一个轻微的不安全因素是KeyRSC计数器的处理。执行分散加密时，该值由WTP维护，但AC需要该值来执行4路握手。握手期间使用的值初始化客户端上的计数器。在CAPWAP中，该值初始化为零，允许在初始身份验证和客户端从WTP接收第一个有效广播数据包之间的窗口中重播广播流量攻击的可能性。[RFC5416]中记录了这种轻微的攻击窗口。
CAPWAP has very little control over how AAA security is deployed, as it's not directly bound to AAA as it is to IEEE 802.11. As a result, CAPWAP can only provide guidance on how to best secure the AAA portions of a CAPWAP-enabled wireless network.
CAPWAP无法控制AAA安全性的部署方式，因为它不像IEEE 802.11那样直接绑定到AAA。因此，CAPWAP只能就如何最好地保护支持CAPWAP的无线网络的AAA部分提供指导。
The AAA protocol is a term that refers to use of either RADIUS [RFC3579] or Diameter [RFC4072] to transport EAP communications between the authenticator and the AAA server. Here the authenticator is the AC, thus the AAA protocol secures the link between the AC and AAA server. Use of non-unique or low-entropy long-term credentials to secure the AC-AAA link can severely impact the overall security of a CAPWAP deployment, and consequently is NOT RECOMMENDED. Each AC should have a mutually authenticated link that provides robust data
AAA协议是指使用RADIUS[RFC3579]或Diameter[RFC4072]在认证器和AAA服务器之间传输EAP通信的术语。在这里，身份验证器是AC，因此AAA协议保护AC和AAA服务器之间的链路。使用非唯一或低熵长期凭据来保护AC-AAA链路可能会严重影响CAPWAP部署的整体安全性，因此不建议使用。每个AC应具有相互认证的链路，以提供可靠的数据
confidentiality and integrity. The AAA protocols and keys used SHOULD be consistent with the guidance in [RFC4962].
保密性和完整性。使用的AAA协议和密钥应与[RFC4962]中的指南一致。
Since CAPWAP does not directly interact with AAA, it does not affect the overall security of a AAA network. In fact, by decreasing the number of devices that communicate with the AAA server, we can actually decrease its exposure and risk of attack.
由于CAPWAP不直接与AAA交互，因此不会影响AAA网络的整体安全性。事实上，通过减少与AAA服务器通信的设备数量，我们实际上可以减少其暴露和攻击风险。
One key shortcoming of both the EAP and AAA models is that they are inherently two-party models. In CAPWAP deployments, we rely on a variety of security associations when an IEEE 802.11 WLAN client session is established. These include:
EAP和AAA模型的一个关键缺点是它们本质上是两方模型。在CAPWAP部署中，当建立IEEE 802.11 WLAN客户端会话时，我们依赖于各种安全关联。这些措施包括：
o WTP-AC (CAPWAP Authentication)
o WTP-AC（CAPWAP认证）
o AC-AAA (AAA Authentication)
o AC-AAA（AAA认证）
o STA-AAA (EAP Method Execution)
o STA-AAA（EAP方法执行）
o STA-AC (AAA pushes keys to AC)
o STA-AC（AAA向AC按键）
o STA-WTP (AC pushes keys to WTP)
o STA-WTP（AC向WTP按键）
Each of these security associations involve a pairwise trust relationship, and none result from a multi-party key agreement protocol such as Kerberos. In particular, just because an STA trusts a AAA server who trusts an AC who trusts a WTP doesn't necessarily mean that the STA should trust the WTP. The WTP may be compromised and using his credentials to maintain a trust relationship with an AC, while advertising false information about the network to an STA.
这些安全关联中的每一个都涉及一个成对的信任关系，没有一个是由多方密钥协商协议（如Kerberos）产生的。特别是，仅仅因为STA信任信任信任WTP的AC的AAA服务器并不一定意味着STA应该信任WTP。WTP可能被破坏并使用其凭证来维持与AC的信任关系，同时向STA公布关于网络的虚假信息。
Protection against attacks like these can be very difficult, while maintaining scalable trust relationships with other entities in the network. Since multiple protocols are being used, multi-party keying to derive end-to-end trust relationships is infeasible.
在与网络中的其他实体保持可伸缩的信任关系的同时，防范此类攻击可能非常困难。由于使用了多个协议，因此无法使用多方密钥来导出端到端信任关系。
Since CAPWAP is a collection of pairwise trust relationships, in order to claim CAPWAP is secure, we must believe in the transitivity of these trust relationships. Its hierarchal nature mitigates the domino effect, but any compromised device in the hierarchy can affect those below it in the hierarchy.
由于CAPWAP是成对信任关系的集合，为了声称CAPWAP是安全的，我们必须相信这些信任关系的可传递性。它的层次性减轻了多米诺效应，但层次结构中的任何受损设备都会影响层次结构中位于其下方的设备。
In order to conduct a comprehensive threat analysis, there are some basic questions we must answer:
为了进行全面的威胁分析，我们必须回答一些基本问题：
o Exactly what are we trying to protect?
o 我们到底想保护什么？
o What are the risks?
o 风险是什么？
* What are the capabilities of would-be attackers?
* 潜在攻击者的能力是什么？
* What might be goals of would-be attackers?
* 潜在攻击者的目标可能是什么？
* What are the vulnerabilities or conditions they might attempt to exploit?
* 他们可能试图利用哪些漏洞或条件？
* For various attackers, what is the likelihood of attempting to exploit a given vulnerability given the cost of the exploit versus the value of attack?
* 对于各种攻击者，考虑到攻击成本和攻击价值，尝试利用给定漏洞的可能性有多大？
o What potential mitigation strategies are available to us?
o 我们有哪些潜在的缓解策略？
o What kinds of trade-offs do these mitigation strategies offer, and do they introduce any new risks?
o 这些缓解策略提供了什么样的权衡？它们是否引入了任何新的风险？
This is a very simplistic overview of what we must accomplish below, but it should give some insight into the manner in which the discussion proceeds.
这是一个非常简单的概述，我们必须在下面完成，但它应该让一些深入了解的方式进行讨论。
As a preliminary, we describe some representative CAPWAP deployment scenarios. This helps to frame subsequent discussion, so that we better understand what we are trying to protect. Following this, we describe a threat model in terms of adversary capabilities, vulnerabilities introduced by the CAPWAP functionality split, and a representative sampling of adversary goals. Note that we do not spend a lot of time speculating about specific attackers here, as this is a very general analysis, and there are many different circumstances under which a WLAN might be deployed.
作为初步介绍，我们将介绍一些具有代表性的CAPWAP部署场景。这有助于构建后续讨论的框架，以便我们更好地理解我们试图保护的内容。在此之后，我们根据敌方能力、CAPWAP功能划分引入的漏洞以及敌方目标的代表性抽样来描述威胁模型。请注意，我们不会在这里花费大量时间猜测特定的攻击者，因为这是一个非常一般的分析，并且在许多不同的情况下可能会部署WLAN。
Following the development of the general threat model, we describe appropriate countermeasures, and discuss how these are implemented through various means within the CAPWAP protocol. Finally, we discuss those issues that are not (or cannot be) completely addressed, and we give recommendations for mitigating the resulting exposure.
随着通用威胁模型的发展，我们描述了适当的对策，并讨论了如何在CAPWAP协议中通过各种方式实施这些对策。最后，我们讨论了那些没有（或不能）完全解决的问题，并给出了减少由此产生的风险的建议。
In this section, we describe some representative CAPWAP deployment scenarios, and in particular, those scenarios that have been taken into consideration for the current CAPWAP protocol security design. For clarity, we first provide some preliminary definitions, along with descriptions of common deployment configurations that span multiple scenarios. Following this is a sampling of individual deployment scenarios.
在本节中，我们将介绍一些具有代表性的CAPWAP部署场景，特别是当前CAPWAP协议安全设计中考虑的场景。为清楚起见，我们首先提供一些初步定义，以及跨多个场景的常见部署配置的描述。下面是单个部署场景的示例。
The IEEE 802.11 standard describes several frame types, and variations in WLAN architectures dictate where these frame types originate and/or terminate (i.e., at the WTP or AC). There are three basic IEEE 802.11 frame types currently defined:
IEEE 802.11标准描述了几种帧类型，WLAN架构中的变化规定了这些帧类型的起始和/或终止位置（即，在WTP或AC）。目前定义了三种基本的IEEE 802.11帧类型：
o Control: These are for managing the transmission medium (i.e., the airwaves). Examples include RTS, CTS, ACK, PS-POLL, CF-POLL, CF-END, and CF-ACK.
o 控制：用于管理传输介质（即电波）。示例包括RTS、CTS、ACK、PS-POLL、CF-POLL、CF-END和CF-ACK。
o Management: These are for managing access to the logical network, as opposed to the physical medium. Example functions include association/disassociation, reassociation, deauthentication, Beacons, and Probes.
o 管理：用于管理对逻辑网络的访问，而不是对物理介质的访问。示例功能包括关联/解除关联、重新关联、取消身份验证、信标和探测。
o Data: Transit data (network packets).
o 数据：传输数据（网络数据包）。
There are a number of other services provided by the WLAN infrastructure, including these:
WLAN基础设施还提供许多其他服务，包括：
o Packet distribution
o 数据包分发
o Synchronization
o 同步
o Retransmissions
o 重发
o Transmission Rate Adaptation
o 传输速率自适应
o Privacy/Confidentiality/Integrity (e.g., IEEE 802.11i)
o 隐私/机密性/完整性（如IEEE 802.11i）
The manner in which these (and other) services are divided among the AC and WTP is collectively referred to in terms of "MAC-splitting" characteristics. We briefly describe various forms of MAC-splitting below. For further detail, see [RFC5415] and [RFC5416].
根据“MAC分割”特性，在AC和WTP之间划分这些（和其他）服务的方式被统称为。下面我们简要介绍各种形式的MAC拆分。有关更多详细信息，请参阅[RFC5415]和[RFC5416]。
Split MAC scenarios are characterized by the fact that some IEEE 802.11 MAC messages are processed by the WTP, while some are processed by the AC. For example, a Split MAC implementation might divide IEEE 802.11 frame processing as follows:
拆分MAC方案的特点是，一些IEEE 802.11 MAC消息由WTP处理，而一些则由AC处理。例如，拆分MAC实现可能将IEEE 802.11帧处理拆分如下：
WTP
水处理厂
* Beacons
* 信标
* Probes
* 探测
* RTS, CTS, ACK, PS-POLL, CF-POLL,CF-END, CF-ACK
* RTS、CTS、ACK、PS-POLL、CF-POLL、CF-END、CF-ACK
AC
自动控制
* Association/Reassociation/Disassociation
* 关联/重新关联/解除关联
* Authentication/Deauthentication
* 身份验证/取消身份验证
* Key Management
* 密钥管理
* IEEE 802.11 Link Security (WEP, TKIP, IEEE 802.11i)
* IEEE 802.11链路安全（WEP、TKIP、IEEE 802.11i）
The Split MAC model is not confined to any one particular deployment scenario, as we'll see below, and vendors have considerable leeway in choosing how to distribute the IEEE 802.11 functionality.
拆分MAC模型并不局限于任何一种特定的部署场景，我们将在下面看到，供应商在选择如何分发IEEE 802.11功能方面有很大的回旋余地。
Local MAC scenarios are characterized by the fact that most IEEE 802.11 MAC messages are processed by the WTP. Some IEE 802.11 MAC frames must be forwarded to the AC (i.e., IEEE 802.11 Association Request frames), but in general, the WTP manages the MAC interactions. Data frames may also be forwarded to the AC, but are generally bridged locally.
本地MAC场景的特点是大多数IEEE 802.11 MAC消息由WTP处理。某些IEE 802.11 MAC帧必须转发到AC（即，IEEE 802.11关联请求帧），但通常情况下，WTP管理MAC交互。数据帧也可以转发到AC，但通常在本地桥接。
Remote MAC scenarios are characterized by the fact that all IEEE 802.11 MAC messages are forwarded to the AC. The WTP does not process any of these locally. This model supports very lightweight WTPs that need be little more than smart antennas. While Remote MAC scenarios are not addressed by the current IEEE 802.11 protocol binding for CAPWAP, the description is included here for completeness.
远程MAC场景的特点是所有IEEE 802.11 MAC消息都转发到AC。WTP不在本地处理任何这些消息。该型号支持非常轻量级的WTP，只需智能天线即可。虽然当前针对CAPWAP的IEEE 802.11协议绑定未解决远程MAC方案，但为了完整起见，此处提供了说明。
Regardless of the approach to MAC splitting, there is also the matter of where user data packets are translated between wired and wireless frame formats, i.e., where the bridging function occurs. In some cases, user data frames are tunneled back to the AC, and in others, they are locally bridged by the WTP. While one might expect Remote MAC implementations to always tunnel data packets back to the AC, for Local and Split MAC modes the decision is not so clear. Also, it's important to note that there are no rules or standards in place that rigidly define these terms and associated handling. Data tunneling is further discussed for each scenario below.
不管MAC分割的方法如何，还存在用户数据包在有线和无线帧格式之间转换的位置问题，即桥接功能发生的位置。在某些情况下，用户数据帧通过隧道传输回AC，而在另一些情况下，用户数据帧通过WTP进行本地桥接。虽然人们可能期望远程MAC实现总是将数据包通过隧道传回AC，但对于本地和拆分MAC模式，决策并不那么明确。另外，需要注意的是，没有严格定义这些术语和相关处理的规则或标准。下面将针对每个场景进一步讨论数据隧道。
In this section, we describe a number of example deployment scenarios. This is not meant to be an exhaustive enumeration; rather, it is intended to give a general sense of how WLANs currently are or may be deployed. This will provide important context when we discuss adversaries and threats in subsequent sections below.
在本节中，我们将描述一些示例部署场景。这并不是详尽的列举；相反，它的目的是让人们大致了解无线局域网目前是如何部署的。当我们在下面的章节中讨论对手和威胁时，这将提供重要的背景。
The localized modular model describes a WLAN that is deployed within a single domain of control, typically within either a single building or some otherwise physically contained area. This would be typical of a small to medium-sized organization. In general, the LAN enjoys some sort of physical security (e.g., it's within the confines of a building for which access is somehow limited), although the actual level of physical security is often far less than is assumed.
本地化模块化模型描述了部署在单个控制域内的WLAN，通常部署在单个建筑或其他物理包含区域内。这是中小型组织的典型特征。一般来说，LAN享有某种物理安全性（例如，它位于访问受到某种限制的建筑物的范围内），尽管实际的物理安全性水平通常远低于假设的水平。
In such deployments, the WLAN is typically an extension of a wired LAN. However, its interface to the wired LAN can vary. For example, the interconnection between the WTPs and ACs can have its own wiring, and its only connection to the LAN is via the AC's Distribution System (DS) port(s). In such cases, the WLAN frequently occupies its own distinct addressing partition(s) in order to facilitate routing, and the AC often acts as a forwarding element.
在这种部署中，WLAN通常是有线LAN的扩展。但是，其与有线LAN的接口可能会有所不同。例如，WTP和ACs之间的互连可以有自己的布线，其与LAN的唯一连接是通过AC的配电系统（DS）端口。在这种情况下，WLAN经常占用其自己的不同寻址分区以便于路由，并且AC经常充当转发元件。
In other cases, the WTPs may be mingled with the existing LAN elements, perhaps sharing address space, or perhaps somehow logically isolated from other wired elements (e.g., by Virtual LAN). Under these circumstances, it is possible that traffic destined to/from the WLAN is mixed with traffic to/from the LAN.
在其他情况下，wtp可与现有LAN元件混合，可能共享地址空间，或者可能以某种方式与其他有线元件（例如，通过虚拟LAN）逻辑隔离。在这些情况下，发送到/来自WLAN的流量可能与发送到/来自LAN的流量混合。
Localized deployments such as these could potentially choose any one of the MAC-splitting scenarios, depending on the size of the deployment, mobility requirements, and other considerations. In many
此类本地化部署可能会根据部署规模、移动性要求和其他考虑因素选择任何一种MAC拆分方案。在许多方面
cases, any one of the various MAC-splitting approaches would be sufficient. This implies that user data may be bridged by either the WTP or the AC.
在这种情况下，各种MAC分割方法中的任何一种都足够了。这意味着用户数据可以由WTP或AC桥接。
The Internet hotspot scenario is representative of a more general deployment model one might find at cafes, hotels, or airports. It is also quite similar to temporary WLANs, which are created for conferences, conventions, and the like. Some common characteristics of these networks include the following:
互联网热点场景代表了在咖啡馆、酒店或机场可以找到的更通用的部署模型。它也非常类似于为会议、会议等创建的临时wlan。这些网络的一些共同特征包括：
o Primary function is to provide Internet access
o 主要功能是提供互联网接入
o Authentication may be very weak
o 身份验证可能非常弱
o There frequently is no IEEE 802.11 link security
o 通常不存在IEEE 802.11链路安全性
Sometimes, the Local MAC model is used. In such cases, the AC may be "in the clouds" (out on the Internet somewhere), and user data traffic will typically be locally bridged, rather than tunneled back to the AC. Some IEEE 802.11 management traffic may be tunneled back to the AC, but frequently the authentication consists in simply knowing the Service Set Identifier (SSID) and perhaps a shared key for use with WEP or WPA-PSK.
有时，使用本地MAC模型。在这种情况下，AC可能“在云中”（在Internet上的某个地方），用户数据流量通常会在本地桥接，而不是通过隧道传回AC。一些IEEE 802.11管理流量可能通过隧道传回AC，但身份验证通常只需知道服务集标识符（SSID）可能还有一个用于WEP或WPA-PSK的共享密钥。
In other cases, a Split MAC model may be used. This is more common in airport and hotel scenarios, where users may have an account that requires verification with some back-end infrastructure prior to access. In these cases, IEEE 802.11 management frames are tunneled back to the AC (e.g., user authentication), and stronger IEEE 802.11 link security may be provided (e.g., RSN), but user data is still typically locally bridged, as the primary goal is to provide Internet access.
在其他情况下，可以使用分割MAC模型。这在机场和酒店场景中更为常见，在这些场景中，用户可能有一个帐户，需要在访问之前通过一些后端基础设施进行验证。在这些情况下，IEEE 802.11管理帧通过隧道传回AC（例如，用户认证），并且可以提供更强的IEEE 802.11链路安全性（例如，RSN），但是用户数据通常仍然是本地桥接的，因为主要目标是提供因特网接入。
A third variation on this scenario entails tunneling user data through a local AC in order to apply centralized policy. For example, in a hotel or airport scenario, there is no reason to provide direct access between WLAN users (who typically are within a private address space), and in fact, allowing such access might invite various sorts of malicious behavior. In such cases, tunneling all user data back to the (local) AC provides a security choke point at which policy may be applied to the traffic.
此场景的第三种变体需要通过本地AC对用户数据进行隧道传输，以便应用集中式策略。例如，在酒店或机场场景中，没有理由在WLAN用户（通常位于私人地址空间内）之间提供直接访问，事实上，允许此类访问可能会引发各种恶意行为。在这种情况下，通过隧道将所有用户数据传输回（本地）AC提供了一个安全瓶颈，在该瓶颈处，策略可以应用于流量。
The distributed deployment model describes a more complex WLAN topology that features network segments that are typically somehow spatially separated, although not necessarily so. These segments might be connected in a physically secure manner, or (if they are widely separated) they might be connected across potentially hostile hops. Below we discuss several subgroups of this model.
分布式部署模型描述了更复杂的WLAN拓扑，其特征是网段通常以某种方式在空间上分离，尽管不一定如此。这些段可能以物理安全的方式连接，或者（如果它们被广泛分离）它们可能跨潜在的敌对跃点连接。下面我们将讨论此模型的几个子组。
One distributed deployment example involves a single large organization that is physically contained, typically within one large building. The network might feature logically distinct (e.g., per-department or per-floor) network segments, and in some cases, there might be firewalls between the segments for access control. In such deployments, the AC is typically in a centralized datacenter, but there might also be a hierarchy of ACs, with a master in the datacenter, and subordinate ACs distributed among the network segments. Such deployments typically assume some level of physical security for the network infrastructure.
一个分布式部署示例涉及物理上包含的单个大型组织，通常位于一个大型建筑内。网络可能具有逻辑上不同的（例如，每个部门或每个楼层）网段，在某些情况下，网段之间可能有防火墙用于访问控制。在这种部署中，AC通常位于集中的数据中心，但也可能存在一个ACs层次结构，其中主ACs位于数据中心，而从属ACs分布在网络段之间。此类部署通常假定网络基础设施具有一定程度的物理安全性。
Some large organizations have networks that span multiple buildings. The interconnections between these buildings might be wired (e.g., underground cables), or might be wireless (e.g., a point-to-point Metropolitan Area Network (MAN) link). The interconnections may be secured, but sometimes they are not. The organization may be providing outdoor wireless access to users, in which case some WTPs will typically be located outdoors, and these may or may not be within physically secure space. For example, college campuses frequently provide outdoor wireless access, and the associated WTPs may simply be mounted on a light post.
一些大型组织拥有跨多个建筑的网络。这些建筑物之间的互连可能是有线的（如地下电缆），也可能是无线的（如点对点城域网（MAN）链路）。互连可能是安全的，但有时不是。该组织可能向用户提供室外无线接入，在这种情况下，一些WTP通常位于室外，并且这些WTP可能在物理安全空间内，也可能不在物理安全空间内。例如，大学校园经常提供室外无线接入，相关WTP可以简单地安装在灯柱上。
For such deployments, ACs may be centrally located in a datacenter, or they may be distributed. User data traffic may be locally bridged, but more frequently it is tunneled back to the AC, as this facilitates mobility and centralized policy enforcement.
对于此类部署，ACs可能集中位于数据中心，也可能是分布式的。用户数据流量可以在本地桥接，但更频繁的情况是通过隧道传回AC，因为这有助于移动性和集中的策略实施。
A common deployment model entails an enterprise consisting of a headquarters and one or more branch offices, with the branches connected to the central HQ. In some cases, the site-to-site connection is via a private WAN link, and in others it is across the
通用部署模型要求企业由一个总部和一个或多个分支机构组成，分支机构与中央总部相连。在某些情况下，站点到站点的连接是通过专用WAN链接进行的，而在另一些情况下，它是跨网络的
Internet. For connections crossing potentially hostile hops (e.g., the Internet), some sort of Virtual Private Network (VPN) is typically employed as a protective measure.
互联网对于跨越潜在敌对跃点的连接（例如，互联网），通常使用某种虚拟专用网络（VPN）作为保护措施。
In some simple branch office scenarios, there are only WTPs at the remote site, and these are managed by a controller residing at the central site. In other cases, a branch site may have its own subordinate controller, with the master controller again residing at the central site. In the first case, local bridging is often the best choice for user data, due to latency and link capacity issues. In the second case, traffic may be locally bridged by the WTPs, or it may be forwarded to the local subordinate controller for centralized policy enforcement. The choice depends on many factors, including local topology and security policy.
在一些简单的分支办公室场景中，远程站点上只有WTP，这些WTP由驻留在中心站点的控制器管理。在其他情况下，分支站点可能有自己的下级控制器，而主控制器再次驻留在中心站点。在第一种情况下，由于延迟和链路容量问题，本地桥接通常是用户数据的最佳选择。在第二种情况下，流量可以由wtp在本地桥接，或者可以转发到本地从属控制器以进行集中策略实施。选择取决于许多因素，包括本地拓扑和安全策略。
It is becoming increasingly common to send WTPs home with employees for use as a telecommuting solution. While there are not yet any standards or hard rules for how these work, a fairly typical configuration provides Split MAC with all user data tunneled back to the controller in the organization's datacenter so that the WTP is essentially providing wireless VPN services. These devices may in some cases provide their own channel security (e.g., IPsec), but alternative approaches are possible. For example, there may be a stand-alone VPN gateway between the WTP and the Internet, which forwards all organization-bound traffic to the VPN gateway.
将WTP与员工一起送回家作为远程办公解决方案越来越普遍。虽然目前还没有任何标准或硬规则来说明这些工作方式，但相当典型的配置提供了拆分MAC，所有用户数据通过隧道传输回组织数据中心的控制器，因此WTP基本上提供了无线VPN服务。在某些情况下，这些设备可以提供自己的通道安全性（例如IPsec），但也可以采用其他方法。例如，WTP和Internet之间可能有一个独立的VPN网关，它将所有组织绑定的流量转发到VPN网关。
Similarly, it is becoming increasingly common for travelers to plug a WTP into a hotel broadband connection. While in many cases, these WTPs are stand-alone fat APs, in some cases they are configured to create a secure connection to a centralized controller back at headquarters, essentially forming a VPN connection. In such scenarios, a Split MAC approach is typical, but split-tunneling may also be supported (i.e., only data traffic destined for the headquarters is tunneled back to the controller, with Internet-bound traffic locally bridged).
同样，旅行者将WTP接入酒店宽带连接也变得越来越普遍。虽然在许多情况下，这些WTP是独立的fat AP，但在某些情况下，它们被配置为创建到总部集中控制器的安全连接，基本上形成VPN连接。在这种情况下，分割MAC方法是典型的，但也可能支持分割隧道（即，只有发往总部的数据流量通过隧道传输回控制器，而互联网绑定的流量通过本地桥接）。
This section describes general capabilities we might expect an adversary to have in various CAPWAP scenarios. Obviously, it is possible to limit what an adversary can do through various deployment restrictions (e.g., provide strict physical security for the AC-WTP link), but such restrictions are simply not always feasible. For
本节描述了我们可能期望对手在各种CAPWAP场景中具备的一般能力。显然，可以通过各种部署限制（例如，为AC-WTP链路提供严格的物理安全）来限制对手的行动，但这种限制并不总是可行的。对于
example, it is not possible to provide strict physical security for various aspects of the telecommuter scenario. Thus, we must consider what capabilities an adversary might have in the worst case, and plan accordingly.
例如，不可能为远程办公场景的各个方面提供严格的物理安全。因此，我们必须考虑对手在最坏的情况下可能具备的能力，并据此计划。
One way to classify adversaries is in terms of their ability to interact with AC/WTP communications. For example, a passive adversary is one who can observe and perhaps record traffic, but cannot interact with it. They can "see" the traffic as it goes by, but they cannot interfere in any way, and they cannot inject traffic of their own. Note that such an adversary does not necessarily see all traffic -- they may miss portions of a communication, e.g., because some packets traverse a different path, or because the network is so busy that the adversary can't keep up (and drops packets as a result).
分类对手的一种方法是根据其与AC/WTP通信的交互能力。例如，被动对手可以观察并记录流量，但不能与之互动。他们可以“看到”经过的流量，但他们不能以任何方式进行干预，也不能注入自己的流量。请注意，这样的对手不一定能看到所有的流量——他们可能会错过部分通信，例如，因为一些数据包穿过不同的路径，或者因为网络太忙以至于对手无法跟上（并因此丢弃数据包）。
An active adversary, on the other hand, can directly interact with the traffic in real-time. There are two modes in which an active adversary might operate:
另一方面，主动对手可以直接与流量实时交互。有两种模式可供主动对手操作：
Pass-by (or sniffer)
路过（或嗅探）
* Can observe/record traffic
* 可以观察/记录交通状况
* Can inject packets
* 可以注入数据包
* Can replay packets
* 可以重播数据包
* Can reflect packets (i.e., send duplicate packets to a different destination, including the to the packet source)
* 可以反映数据包（即，将重复数据包发送到不同的目的地，包括发送到数据包源）
* Can cause redirection (e.g., via Address Resolution Protocol (ARP)/DNS poisoning)
* 可能导致重定向（例如，通过地址解析协议（ARP）/DNS中毒）
Inline (Man-in-the-Middle, or MitM)
内联（中间人，或MitM）
* Can observe/record traffic
* 可以观察/记录交通状况
* Can inject packets
* 可以注入数据包
* Can replay packets
* 可以重播数据包
* Can reflect packets (with or without duplication)
* 可以反映数据包（有或无重复）
* Can delete packets
* 可以删除数据包
* Can modify packets
* 可以修改数据包
* Can delay packets
* 可以延迟数据包
A passive adversary could be located anywhere along the path between the AC and WTP, and is characterized by the fact that it only listens:
被动对手可以位于AC和WTP之间路径的任何位置，其特点是它只监听：
+------+
|client| +--------+ |
|(STA) | | WTP | | +------+
+------+ ) ) ) ) | |-----| / \ +------+
/ / +--------+ |-x-( optional )---| AC |
+------+ | | \ cloud / +------+
| | +------+
|
| +-----------+
+--| pass-by |
| listener |
+-----------+
+------+
|client| +--------+ |
|(STA) | | WTP | | +------+
+------+ ) ) ) ) | |-----| / \ +------+
/ / +--------+ |-x-( optional )---| AC |
+------+ | | \ cloud / +------+
| | +------+
|
| +-----------+
+--| pass-by |
| listener |
+-----------+
Figure 5: Passive Attacker
图5：被动攻击者
An active adversary may attach in the same manner as the passive adversary (in which case it is in pass-by mode), or it may be lodged directly in the path between the AC and WTP (inline mode):
主动对手可以与被动对手以相同的方式连接（在这种情况下，它处于旁路模式），或者它可以直接放置在AC和WTP之间的路径中（内联模式）：
+------+
|client| +--------+ |
|(STA) | | WTP | | +------+ +------+
+------+ ) ) ) | |---| |active| / \ +------+
/ / +--------+ |-| MitM |--( optional )---| AC |
+------+ | +------+ \ cloud / +------+
| +------+
+------+
|client| +--------+ |
|(STA) | | WTP | | +------+ +------+
+------+ ) ) ) | |---| |active| / \ +------+
/ / +--------+ |-| MitM |--( optional )---| AC |
+------+ | +------+ \ cloud / +------+
| +------+
Figure 6: Active Man-in-the-Middle Attacker
图6：活跃的中间人攻击者
If it is not inline, it can only observe and create traffic; if it is inline, it can do whatever it wishes with the traffic it sees.
如果它不在线，它只能观察和创建流量；如果它是内联的，它可以对它看到的流量做任何它想做的事情。
It is important to recognize that becoming a MitM does not necessarily require physical insertion directly into the transmission path. Alternatively, the adversary can cause traffic to be diverted to the MitM system, e.g., via ARP or DNS poisoning. Hence, launching an MitM attack is not so difficult as it might first appear.
重要的是要认识到，成为MitM并不一定需要直接物理插入传输路径。或者，敌方可以使通信量转向MitM系统，例如，通过ARP或DNS。因此，发起MitM攻击并不像最初看起来那么困难。
In this section, we discuss vulnerabilities that arise as a result of splitting the AP function across potentially hostile hops. We primarily consider network-based vulnerabilities, and while in particular we do not address how an adversary might affect a physical compromise of the WTP or AC, we do consider the potential effects of such compromises with respect to CAPWAP and the operational changes it introduces when compared to stand-alone AP deployments.
在本节中，我们将讨论由于在潜在的恶意跃点之间拆分AP功能而产生的漏洞。我们主要考虑基于网络的脆弱性，特别是我们不讨论对手如何影响WTP或AC的物理折衷，我们考虑与CAPPAP有关的这种妥协的潜在影响以及与独立AP部署相比引入的操作变化。
Functionally, we are interested in two general "states of being" with respect to AC-WTP communications: the session establishment phase or state, and the "connected" (or session established) state. We discuss each of these further below. Also, it is important to note that we first describe vulnerabilities assuming that the CAPWAP communications lack security of any kind. Later, we will evaluate the protocol given the security mechanisms currently planned for CAPWAP.
在功能上，我们对AC-WTP通信的两种一般“存在状态”感兴趣：会话建立阶段或状态，以及“连接”（或会话建立）状态。我们将在下文中进一步讨论这些问题。此外，需要注意的是，我们首先描述了假设CAPWAP通信缺乏任何类型的安全性的漏洞。稍后，我们将根据目前计划用于CAPWAP的安全机制评估该协议。
The session establishment phase consists of two subordinate phases: discovery, and association or joining. These are treated individually in the following sections.
会话建立阶段包括两个从属阶段：发现、关联或加入。以下各节将分别对这些问题进行处理。
Discovery consists of an information exchange between the AC and WTP. There are several potential areas of exposure:
发现包括AC和WTP之间的信息交换。有几个潜在的接触区域：
Information Leakage: During Discovery, information about the WTP and AC hardware and software are exchanged, as well as information about the AC's current operational state. This could provide an adversary with valuable insights.
信息泄漏：在发现过程中，交换有关WTP和AC硬件和软件的信息，以及有关AC当前运行状态的信息。这可以为对手提供有价值的见解。
DoS Potential: During Discovery, there are several opportunities for Denial of Service (DoS), beyond those inherently available to an inline adversary. For example, an adversary might respond to a WTP more quickly than a valid AC, causing the WTP to attempt to join with a non-existent AC, or one which is currently at maximum load.
DoS潜力：在发现过程中，除了内联对手固有的拒绝服务（DoS）机会外，还存在多个拒绝服务（DoS）机会。例如，对手对WTP的响应可能比有效AC更快，导致WTP尝试加入不存在的AC或当前处于最大负载的AC。
Redirection Potential: There are multiple ways in which an adversary might redirect a WTP during Discovery. For example, the adversary might pretend to be a valid AC, and entice the WTP to connect to it. Or, the adversary might instead cause the WTP to associate
重定向潜力：对手可以通过多种方式在发现过程中重定向WTP。例如，对手可能假装是有效的AC，并诱使WTP连接到它。或者，对手可能会导致WTP关联
with the AC of the adversary's choosing, by posing as a DNS or DHCP server, injecting a spoofed Discovery Response, or by modifying valid AC responses.
由对手选择AC，通过冒充DNS或DHCP服务器、注入伪造的发现响应或修改有效AC响应。
Misdirection: An adversary might mislead either the WTP or AC by modifying the Discovery Request or Response in flight. In this way, the AC and/or WTP will have a false view of the other's capabilities, and this might cause a change in the way they interact (e.g., they might not use important features not supported by earlier versions).
误导：敌方可能通过修改飞行中的发现请求或响应误导WTP或AC。通过这种方式，AC和/或WTP将对另一方的功能有错误的看法，这可能会导致它们的交互方式发生变化（例如，它们可能不会使用早期版本不支持的重要功能）。
The association phase begins once the WTP has determined with which AC it wishes to join. There are several potential areas of exposure during this phase:
一旦WTP确定希望加入哪个AC，关联阶段即开始。在这一阶段，有几个潜在的暴露区域：
Information Leakage: During association, the adversary could glean useful information about hardware, software, current configuration, etc. that could be used in various ways.
信息泄漏：在关联过程中，对手可以收集有关硬件、软件、当前配置等的有用信息，这些信息可以以各种方式使用。
DoS Potential: During formation of a WTP-AC association, there are several opportunities for Denial of Service (DoS), beyond those inherently available to an inline adversary. For example, the adversary could flood the AC with connection setup requests. Or, it could respond to the WTP with invalid connection setup responses, causing a connection reset. An adversary with MitM capability could delete critical session establishment packets.
DoS可能性：在WTP-AC关联形成过程中，除了内联对手固有的拒绝服务（DoS）机会外，还存在多个拒绝服务（DoS）机会。例如，对手可能会向AC发送大量连接设置请求。或者，它可能以无效的连接设置响应响应WTP，从而导致连接重置。具有MitM能力的对手可以删除关键会话建立数据包。
Misdirection: An adversary might mislead either the WTP or AC by modifying the association request(s) or response(s) in flight. In this way, the AC and/or WTP will have an inaccurate view of the other's capabilities, and this might cause a change in the way they interact.
误导：对手可能通过修改飞行中的关联请求或响应误导WTP或AC。这样，AC和/或WTP将无法准确了解对方的能力，这可能会导致其交互方式发生变化。
Some of these types of exposure are extremely difficult to prevent. However, there are things we can do to mitigate the effects, as we will see below.
其中一些类型的接触极难预防。然而，我们可以做一些事情来减轻影响，如下所示。
Once the WTP and AC have established an association, the adversary's attention will turn to the network connection. If we assume a passive adversary, the primary concern for established connections is eavesdropping. If we assume an active adversary, there are several other potential areas of exposure:
一旦WTP和AC建立了关联，对手的注意力将转向网络连接。如果我们假设对方是被动的，那么建立连接的首要问题就是窃听。如果我们假设一个积极的对手，那么还有其他几个潜在的暴露领域：
Connection Hijacking: An adversary may assume the identity of one end of the connection and take over the conversation. There are numerous ways in which the true owner of the identity may be taken off-line, including DoS or MitM attacks.
连接劫持：对手可以假定连接一端的身份并接管对话。身份的真正所有者可以通过多种方式离线，包括DoS或MitM攻击。
Eavesdropping: An adversary may glean useful information from knowledge of the contents of CAPWAP control and/or data traffic.
窃听：敌方可以从CAPWAP控制和/或数据通信内容的知识中收集有用的信息。
Modification of User Data: An adversary with MitM capabilities could modify, delete, or insert user data frames.
修改用户数据：具有MitM功能的对手可以修改、删除或插入用户数据帧。
Modification of Control/Monitoring Messages: An adversary with MitM capability could modify control traffic such as statistics, status information, etc. to create a false impression at the recipient.
控制/监视消息的修改：具有MitM能力的对手可以修改控制通信量，如统计数据、状态信息等，以在收件人处造成虚假印象。
Modification/Control of Configuration: An adversary with MitM capability could modify configuration messages to create unexpected conditions at the recipient. Likewise, if a WTP is redirected during Discovery (or joining) and connects to an adversary rather than an authorized AC, the adversary may exert complete control over the WTPs configuration, including potentially loading tainted WTP firmware.
修改/控制配置：具有MitM能力的对手可以修改配置消息，以在收件人处造成意外情况。类似地，如果WTP在发现（或加入）期间被重定向并连接到对手而不是授权AC，则对手可以对WTPs配置施加完全控制，包括可能加载受污染的WTP固件。
This section gives an sampling of potential adversary goals. It is not exhaustive, and makes no judgment as to the relative likelihood or value of each individual goal. Rather, it is meant to give some idea of what is possible. It is important to remember that clever attacks often result when seemingly innocuous flaws or vulnerabilities are combined in some non-intuitive way. Hence, we don't rule out some goal that, taken alone, might not seem to make sense from an adversarial perspective.
本节给出了潜在对手目标的示例。它并非详尽无遗，也不会对每个目标的相对可能性或价值做出判断。相反，这是为了给一些想法什么是可能的。重要的是要记住，当看似无害的缺陷或漏洞以某种非直观的方式组合在一起时，往往会导致巧妙的攻击。因此，我们不排除某些目标，单从对抗的角度来看，这些目标似乎没有意义。
There are numerous reasons why an adversary might want to eavesdrop on AC-WTP traffic. For example, it allows for reconnaissance, providing answers to the following questions:
对手想要窃听AC-WTP流量的原因有很多。例如，它允许侦察，提供以下问题的答案：
o Where are the ACs?
o ACs在哪里？
o Where are the WTPs?
o WTP在哪里？
o Who owns them?
o 谁拥有它们？
o Who manufactured them?
o 谁制造的？
o What version of firmware do they run?
o 他们运行什么版本的固件？
o What cryptographic capabilities do they have?
o 他们有什么加密功能？
Similarly, snooping on tunneled data traffic might potentially reveal a great deal about the network, including answers to the following:
类似地，窥探隧道数据流量可能会揭示大量网络信息，包括以下问题的答案：
o Who's using the WLAN?
o 谁在使用无线局域网？
o When, and for how long?
o 什么时候，多久？
o What addresses are they using?
o 他们使用什么地址？
o What protocols are they using?
o 他们使用什么协议？
o What over-the-air security are they using?
o 他们使用什么空中安全？
o Who/What are they talking to?
o 他们在和谁/什么说话？
Additionally, access to tunneled user data could allow the attacker to see confidential information being exchanged by applications (e.g., financial transactions). An eavesdropper may gain access to valuable information that either provides the basis for another perhaps more sophisticated attack, or which has its own intrinsic value.
此外，通过对隧道用户数据的访问，攻击者可以看到应用程序交换的机密信息（例如，金融交易）。窃听者可能获得有价值的信息，这些信息要么为另一种可能更复杂的攻击提供基础，要么具有自身的内在价值。
An adversary might want to impersonate or control an authorized WTP for many reasons, some of which we might realistically imagine today, and perhaps others about which we have no clue at this point. Examples we might reasonably imagine include the following:
对手可能出于多种原因想要模拟或控制授权的WTP，其中一些原因我们今天可能会现实地想象出来，而另一些原因我们目前尚不清楚。我们可以合理想象的例子包括：
o to facilitate MitM attacks against WLAN users
o 促进针对WLAN用户的MitM攻击
o to leak/inject or otherwise compromise WLAN data
o 泄漏/注入或以其他方式破坏WLAN数据
o to give an inaccurate view of the state of the WLAN
o 提供WLAN状态的不准确视图
o to gain access to a trusted channel to an AC, through which various protocol attacks might be launched (e.g., hijack client sessions from other WTPs)
o 访问AC的可信通道，通过该通道可能发起各种协议攻击（例如，劫持来自其他WTP的客户端会话）
o to facilitate Denial-of-Service attacks against WLAN users or the network
o 促进针对WLAN用户或网络的拒绝服务攻击
For reasons similar to the WTP impersonation discussed above, an adversary might want to impersonate an authorized AC for many reasons. Examples we might reasonably imagine include the following:
出于与上面讨论的WTP模拟类似的原因，对手可能出于多种原因想要模拟授权的AC。我们可以合理想象的例子包括：
o to facilitate DoS attacks against WLANs
o 促进针对WLAN的DoS攻击
o to facilitate MitM attacks against WLAN users
o 促进针对WLAN用户的MitM攻击
o to intercept user mobility context from another AC (possibly including security-sensitive information such as cryptographic keys)
o 从另一个AC截获用户移动上下文（可能包括安全敏感信息，如加密密钥）
o to facilitate selective control of one or more WTPs
o 促进对一个或多个水处理厂的选择性控制
* modify WTP configuration
* 修改WTP配置
* load tainted firmware onto WTP
* 将受污染的固件加载到WTP
o to assist in controlling which AC associates with which WTP
o 协助控制哪个AC与哪个WTP关联
o to facilitate IEEE 802.11 association of unauthorized WLAN user(s)
o 促进IEEE 802.11未经授权WLAN用户的关联
o to exploit inter-AC trust in order facilitate attacks on other ACs
o 利用AC间信任以促进对其他AC的攻击
In general, AC impersonation opens the door to a large measure of control over the WLAN, and could be used as the foundation to many other attacks.
一般来说，AC模拟打开了对WLAN的大量控制的大门，并且可以被用作许多其他攻击的基础。
There are many less concrete goals an adversary might have which, taken alone, might not seem to have any purpose, but when combined with other goals/attacks, might have very definite and undesirable consequences. Here are some examples:
对手可能有许多不太具体的目标，单凭这些目标似乎没有任何目的，但当与其他目标/攻击相结合时，可能会产生非常明确的不良后果。以下是一些例子：
o cause CAPWAP de-association of WTP/AC
o 导致WTP/AC不关联的原因
o cause IEEE 802.11 de-association of authorized user
o 导致IEEE 802.11取消授权用户的关联
o inject/modify/delete tunneled IEEE 802.11 user traffic
o 注入/修改/删除隧道式IEEE 802.11用户流量
* to interact with a specific application
* 与特定应用程序交互
* to launch various attacks on WLAN user systems
* 对WLAN用户系统发起各种攻击
* to launch protocol fuzzing or other attacks on the AC that bridges between IEEE 802.11 and 802.3 frame formats
* 对连接IEEE 802.11和802.3帧格式的AC发起协议模糊或其他攻击
o control DNS responses
o 控制DNS响应
o control DHCP/BOOTP responses
o 控制DHCP/BOOTP响应
Anticipating all of the things an adversary might want to do is a daunting task. Part of the difficulty stems from the fact that we are analyzing CAPWAP in a very general sense, rather than in a specific deployment scenario with specific assets and very specific adversary goals. However, we have no choice but to take this approach if we are to provide reasonably good security across the board.
预测对手可能想做的所有事情是一项艰巨的任务。部分困难源于这样一个事实，即我们是在非常笼统的意义上分析CAPWAP，而不是在具有特定资产和特定对手目标的特定部署场景中分析CAPWAP。然而，如果我们要全面提供合理良好的安全性，我们别无选择，只能采取这种方法。
In the previous sections, we described numerous vulnerabilities that result from splitting the AP function in two, and also discussed a number of adversary goals that could be realized by exploiting one or more of those vulnerabilities. In this section, we describe countermeasures we can apply to mitigate the risks that come with the introduction of CAPWAP into WLAN deployment scenarios.
在前面的章节中，我们描述了将AP功能一分为二所导致的众多漏洞，并讨论了通过利用其中一个或多个漏洞可以实现的一些对手目标。在本节中，我们将介绍可用于缓解将CAPWAP引入WLAN部署场景所带来的风险的对策。
Mutual authentication consists in each side proving its identity to the other. There are numerous authentication protocols that accomplish this, typically using either a shared secret (e.g., a pre-shared key) or by relying on a trusted third party (e.g., with digital credentials such as X.509 certificates).
相互认证包括双方向对方证明其身份。有许多身份验证协议可以实现这一点，通常使用共享秘密（例如，预共享密钥）或依赖可信第三方（例如，使用数字凭证，如X.509证书）。
Strong mutual authentication accomplishes the following:
强相互身份验证可实现以下功能：
o helps prevent AC/WTP impersonation
o 有助于防止AC/WTP模拟
o helps prevent MitM attacks
o 有助于防止MitM攻击
o can be used to limit DoS attacks.
o 可用于限制DoS攻击。
While authentication consists in proving the identity of an entity, authorization consists in determining whether that entity should have access to some resource. The current IEEE 802.11i CAPWAP protocol binding takes a rather simplistic approach to authorization,
身份验证在于证明实体的身份，而授权在于确定该实体是否应该访问某些资源。当前的IEEE 802.11i CAPWAP协议绑定采用了相当简单的授权方法，
depending on the authentication method chosen. If pre-shared keys are used, authorization is broad and coarse: if the device knows the pre-shared key, the device is "trusted", meaning the that it is believed to be what it claims to be ( AC versus WTP), and it is granted all privilege/access associated with that device class.
取决于所选的身份验证方法。如果使用预共享密钥，则授权是广泛而粗糙的：如果设备知道预共享密钥，则设备是“受信任的”，这意味着它被认为是它所声称的（AC与WTP），并且被授予与该设备类别相关的所有特权/访问权。
When using pre-shared keys, some granularity may be achieved by creating classes, each with their own pre-shared key, but this still has drawbacks. For example, while possession of the key may suffice to identify the device as a member of a given group or class, it cannot be used to prove a device is either a WTP or an AC. This means the key can be abused, and those possessing the key can claim to be either type of device.
使用预共享密钥时，可以通过创建类来实现一定的粒度，每个类都有自己的预共享密钥，但这仍然有缺点。例如，虽然拥有密钥可能足以将设备识别为给定组或类别的成员，但它不能用来证明设备是WTP或AC。这意味着密钥可能被滥用，拥有密钥的人可以声称是任何类型的设备。
When X.509v3 certificates are used for authentication, much more granular authorization policies are possible. Nonetheless, the current IEEE 802.11i protocol binding remains simplistic in its approach (though this may be addressed in future revisions). As currently defined, the X.509v3 certificates facilitate the following authorization checks:
当X.509v3证书用于身份验证时，可以使用更细粒度的授权策略。尽管如此，当前的IEEE 802.11i协议绑定在其方法上仍然过于简单（尽管这可能会在未来的修订中解决）。按照当前定义，X.509v3证书有助于进行以下授权检查：
o CommonName (CN): the CN contains the MAC address of the device; if the relying party (AC or WTP) has a method for determining "acceptability" of a given MAC address, this helps prevent AC/WTP impersonation, MitM attacks, and may help in limiting DoS attacks
o CommonName（CN）：CN包含设备的MAC地址；如果依赖方（AC或WTP）有确定给定MAC地址“可接受性”的方法，这有助于防止AC/WTP模拟、MitM攻击，并可能有助于限制DoS攻击
o Extended Key Usage (EKU) key purpose ID bits: CAPWAP uses specific key purpose ID bits (see [RFC5415] for more information) to explicitly differentiate between an AC and a WTP. If use of these bits is strictly enforced, this segregates devices into AC versus WTP classes, and assists in preventing AC/WTP impersonation, MitM attacks, and may also help in limiting DoS attacks. However, if the id-kp-anyExtendedKeyUsage keyPurposeID is supported, this mechanism may be on a par with pre-shared keys, as a rogue device has the ability to claim it is either a WTP or AC, unless CN-based access controls are employed in tandem.
o 扩展密钥使用（EKU）密钥用途ID位：CAPWAP使用特定密钥用途ID位（有关更多信息，请参阅[RFC5415]）明确区分AC和WTP。如果严格执行这些位的使用，这会将设备划分为AC和WTP类，并有助于防止AC/WTP模拟、MitM攻击，还可能有助于限制DoS攻击。然而，如果支持IDKP AyExpDeDeKEY用法KEP PurPosieID，则该机制可能与预共享密钥一致，因为流氓设备有能力声称它是WTP或AC，除非采用基于CN的访问控制串联。
It should be noted that certificate-based authorization and zero configuration are not fully compatible. Even if the WTPs and the ACs are shipped with manufacturer-provided certificates, the WTPs need a way to identify the correct AC is in this deployment (as opposed to other ACs from the same vendor, purchased and controlled by an adversary), and the AC needs to know which WTPs are part of this deployment (as opposed to WTPs purchased and controlled by an adversary).
应该注意的是，基于证书的授权和零配置并不完全兼容。即使WTP和ACs随附制造商提供的证书，WTP也需要一种方法来识别此部署中的正确AC（与来自同一供应商、由对手购买和控制的其他AC相反），并且AC需要知道哪些WTP是此部署的一部分（与对手购买和控制的WTP相反）。
The threat analysis in this document assumes that WTPs can identify the correct AC, and the AC can identify the correct WTPs. Analysis of situations where either of these do not hold is beyond the scope of this document.
本文件中的威胁分析假设WTP可以识别正确的AC，AC可以识别正确的WTP。对其中任何一项都不适用的情况的分析超出了本文件的范围。
Data origin authentication typically depends on first authenticating the party at the other end of the channel, and then binding the identity derived from that authentication process to the data origin authentication process. Data origin authentication primarily prevents an attacker from injecting data into the communication channel and pretending it was originated by a valid endpoint. This mitigates risk by preventing the following:
数据源身份验证通常取决于首先对通道另一端的参与方进行身份验证，然后将从该身份验证过程派生的身份绑定到数据源身份验证过程。数据源身份验证主要防止攻击者将数据注入通信通道并假装它是由有效端点发起的。这通过防止以下情况来降低风险：
o packet injection
o 包注入
o connection hijacking
o 连接劫持
o modification of control and/or user data
o 控制和/或用户数据的修改
o impersonation
o 模仿
Data integrity verification provides assurance that data has not been altered in transit, and is another link in the trust chain beginning from mutual authentication, extending to data origin authentication, and ending with integrity verification. This prevents the adversary from undetectably modifying otherwise valid data while in transit. It effectively prevents reflection and modification, and in some cases may help to prevent re-ordering.
数据完整性验证确保数据在传输过程中未被更改，并且是信任链中的另一个环节，从相互身份验证开始，扩展到数据源身份验证，并以完整性验证结束。这可以防止对手在传输过程中无法检测到修改其他有效数据。它有效地防止了反射和修改，并且在某些情况下可能有助于防止重新排序。
Anti-replay is somewhat self-explanatory: it prevents replay of valid packets at a later time, or to a different recipient. It may also prevent limited re-ordering of packets. It is typically accomplished by assigning monotonically increasing sequence numbers to packets.
反重播有点不言自明：它防止在以后重播有效的数据包，或者重播到不同的收件人。它还可以防止数据包的有限重新排序。它通常通过为数据包分配单调递增的序列号来实现。
Data confidentiality prevents eavesdropping by protecting data as it passes over the network. This is typically accomplished using encryption.
数据保密性通过在数据通过网络时保护数据来防止窃听。这通常使用加密来完成。
Above we described various security elements and their properties. Below, we discuss combinations of these elements in terms of CAPWAP.
上面我们描述了各种安全元素及其属性。下面，我们将根据CAPWAP讨论这些元素的组合。
The CAPWAP control channel is used for forming an association between a WTP and AC, and subsequently it allows the AC to provision and monitor the WTP. This channel is critical for the control, management, and monitoring of the WLAN, and thus requires all of the security elements described above. With these elements in place, we can effectively create a secure channel that mitigates almost all of the vulnerabilities described above.
CAPWAP控制信道用于在WTP和AC之间形成关联，随后它允许AC提供和监控WTP。该通道对于WLAN的控制、管理和监控至关重要，因此需要上述所有安全元素。有了这些元素，我们可以有效地创建一个安全通道，以缓解上述几乎所有漏洞。
The CAPWAP data channel contains some IEEE 802.11 management traffic including association/disassociation, reassociation, and deauthentication. It also may contain potentially sensitive user data. If we assume that threats to this channel exist (i.e., it traverses potentially hostile hops), then providing strong mutual authentication coupled with data origin/integrity verification would prevent an adversary from injecting and/or modifying transit data, or impersonating a valid AC or WTP. Adding confidentiality would prevent eavesdropping.
CAPWAP数据通道包含一些IEEE 802.11管理流量，包括关联/解除关联、重新关联和取消身份验证。它还可能包含潜在的敏感用户数据。如果我们假设存在对该通道的威胁（即，它穿越潜在的恶意跃点），那么提供强大的相互身份验证以及数据来源/完整性验证将防止对手注入和/或修改传输数据，或模拟有效的AC或WTP。增加保密性可以防止窃听。
Datagram TLS (DTLS) is the currently proposed security solution for CAPWAP. DTLS supports the following security functionality:
数据报TLS（DTLS）是目前提议的CAPWAP安全解决方案。DTLS支持以下安全功能：
o Mutual Authentication (pre-shared secrets or X.509 Certificates)
o 相互认证（预共享机密或X.509证书）
o Mutual Authorization (pre-shared secrets or X.509 Certificates)
o 相互授权（预共享机密或X.509证书）
o Data Origin Authentication
o 数据源身份验证
o Data Integrity Verification
o 数据完整性验证
o Anti-replay
o 反重播
o Confidentiality (supports strong cryptographic algorithms)
o 机密性（支持强加密算法）
Using DTLS for both the control and data channels mitigates nearly all risks resulting from splitting the AP function in two.
对控制通道和数据通道使用DTL可以缓解将AP功能一分为二所带来的几乎所有风险。
Unfortunately, DTLS does not solve all of our CAPWAP security concerns. There are some things it just cannot prevent. These are enumerated below.
不幸的是，DTLS并不能解决我们所有的CAPWAP安全问题。有些事情是它无法阻止的。下文列举了这些问题。
Even with the security provided by DTLS, CAPWAP is still susceptible to various types of DoS attack:
即使有DTLS提供的安全性，CAPWAP仍然容易受到各种类型的DoS攻击：
o Session Initialization: an adversary could initiate thousands of DTLS handshakes simultaneously in order to exhaust memory resources on the AC; DTLS provides a mitigation tool via the HelloVerifyRequest, which ensures that the initiator can receive packets at the claimed source address prior to allocating resources. However, this would not thwart a botnet-style attack.
o 会话初始化：对手可以同时发起数千次DTLS握手，以耗尽AC上的内存资源；DTLS通过HelloVerifyRequest提供了一个缓解工具，它确保启动器可以在分配资源之前在声明的源地址接收数据包。然而，这并不能阻止僵尸网络式的攻击。
o Cryptographic DoS: an adversary could flood either the AC or WTP with properly formed DTLS records containing garbage, causing the recipient to waste compute cycles decrypting and authenticating the traffic.
o 加密DoS：敌方可能会向AC或WTP发送包含垃圾的格式正确的DTLS记录，导致接收方在解密和验证流量时浪费计算周期。
o Session interference: a MitM could either drop important session establishment packets or inject bogus connection resets during session establishment phase. It could also interfere with other traffic in an established session.
o 会话干扰：MitM可能会丢弃重要的会话建立数据包，或者在会话建立阶段注入虚假的连接重置。它还可能干扰已建立会话中的其他通信。
These attacks can be mitigated through various mechanisms, but not entirely avoided. For example, session initialization can be rate-limited, and in case of resource exhaustion, some number of incompletely initialized sessions could be discarded. Also, such events should be strictly audited.
这些攻击可以通过各种机制减轻，但不能完全避免。例如，会话初始化可以是速率受限的，并且在资源耗尽的情况下，可以丢弃一些未完全初始化的会话。此外，此类事件应严格审计。
Likewise, cryptographic DoS attacks are detectable if appropriate auditing and monitoring controls are implemented. When detected, these events should (at minimum) trigger an alert. Additional mitigation might be realized by randomly discarding packets.
同样，如果实施适当的审计和监控控制，则可以检测到加密DoS攻击。检测到这些事件时，应（至少）触发警报。额外的缓解措施可以通过随机丢弃数据包来实现。
Session interference is probably the most difficult of DoS attacks. It is very difficult to detect in real-time, although it may be detected if exceeding a lost packet threshold triggers an alert. However, this depends on the MitM not being in a position to delete the alert before it reaches its appropriate destination.
会话干扰可能是最困难的DoS攻击。实时检测非常困难，但如果超过丢失数据包阈值触发警报，则可能会检测到。但是，这取决于MitM无法在警报到达相应目标之前删除警报。
CAPWAP protocol security cannot prevent (or detect) passive monitoring. The best we can do is provide a confidentiality mechanism.
CAPWAP协议安全性无法阻止（或检测）被动监视。我们所能做的就是提供一个保密机制。
DTLS provides no defense for traffic analysis. If this is a concern, there are traffic generation and padding techniques designed to mitigate this threat, but none of these are currently specified for CAPWAP.
DTLS不为流量分析提供防御。如果这是一个问题，有流量生成和填充技术设计来减轻这种威胁，但目前没有为CAPWAP指定这些技术。
This was discussed in more limited scope in the section above on DoS attacks. An active MitM can delete or re-order packets in a manner that is very difficult to detect, and there is little the CAPWAP protocol can do in such cases. If packet loss is reported upon exceeding some threshold, then perhaps detection might be possible, but this is not guaranteed.
在上面关于DoS攻击的一节中，在更有限的范围内讨论了这一点。活动的MitM可以以一种非常难以检测的方式删除或重新排序数据包，而CAPWAP协议在这种情况下几乎无能为力。如果在超过某个阈值时报告数据包丢失，则可能可以进行检测，但这并不能保证。
In addition to the issues raised above, there are other active attacks that can be mounted if the adversary has access to the wired medium. For example, the adversary may be able to impersonate a DNS or DHCP server, or to poison either a DNS or ARP cache. Such attacks are beyond the scope of CAPWAP, and point to an underlying LAN security problem.
除上述问题外，如果对手可以访问有线媒体，还可以发起其他主动攻击。例如，对手可能能够模拟DNS或DHCP服务器，或者毒害DNS或ARP缓存。此类攻击超出了CAPWAP的范围，并指出了潜在的LAN安全问题。
This document outlines a threat analysis for CAPWAP in the context of IEEE 802.11 deployments, and as such, no additional CAPWAP-related security considerations are described here. However, in some cases additional management channels (e.g., Simple Network Management Protocol (SNMP)) may be introduced into CAPWAP deployments. Whenever this occurs, related security considerations MUST be described in detail in those documents.
本文档概述了在IEEE 802.11部署环境下CAPWAP的威胁分析，因此，此处不介绍与CAPWAP相关的其他安全注意事项。但是，在某些情况下，可能会在CAPWAP部署中引入额外的管理通道（例如，简单网络管理协议（SNMP））。每当发生这种情况时，必须在这些文件中详细说明相关的安全注意事项。
The authors gratefully acknowledge the reviews and helpful comments of Dan Romascanu, Joe Salowey, Sam Hartman, Mahalingham Mani, and Pasi Eronen.
作者感谢Dan Romascanu、Joe Salowey、Sam Hartman、Mahalingham Mani和Pasi Eronen的评论和有益的评论。
[80211I] "IEEE Std 802.11i: WLAN Specification for Enhanced Security", April 2004.
[80211I]“IEEE标准802.11i：增强安全性的WLAN规范”，2004年4月。
[80211SEC] Edney, J. and W. Arbaugh, "Real 802.11 Security - Wi-Fi protected Access and 802.11i", 2004.
[80211SEC]Edney，J.和W.Arbaugh，“真正的802.11安全-Wi-Fi保护访问和802.11i”，2004年。
[8021X] "IEEE Std 802.1X-2004: Port-based Network Access Control", December 2004.
[8021X]“IEEE标准802.1X-2004：基于端口的网络访问控制”，2004年12月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC4118] Yang, L., Zerfos, P., and E. Sadot, "Architecture Taxonomy for Control and Provisioning of Wireless Access Points (CAPWAP)", RFC 4118, June 2005.
[RFC4118]Yang，L.，Zerfos，P.，和E.Sadot，“无线接入点控制和供应（CAPWAP）的体系结构分类”，RFC 4118，2005年6月。
[RFC5415] Calhoun, P., Ed., Montemurro, M., Ed., and D. Stanley, Ed., "Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Specification", RFC 5415, March 2009.
[RFC5415]Calhoun，P.，Ed.，Montemurro，M.，Ed.，和D.Stanley，Ed.，“无线接入点的控制和供应（CAPWAP）协议规范”，RFC 5415，2009年3月。
[RFC5416] Calhoun, P., Ed., Montemurro, M., Ed., and D. Stanley, Ed., "Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Binding for IEEE 802.11", RFC 5416, March 2009.
[RFC5416]Calhoun，P.，Ed.，Montemurro，M.，Ed.，和D.Stanley，Ed.，“IEEE 802.11无线接入点（CAPWAP）协议绑定的控制和供应”，RFC 5416，2009年3月。
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003.
[RFC3579]Aboba，B.和P.Calhoun，“RADIUS（远程认证拨入用户服务）对可扩展认证协议（EAP）的支持”，RFC 3579，2003年9月。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[RFC3748]Aboba，B.，Blunk，L.，Vollbrecht，J.，Carlson，J.，和H.Levkowetz，“可扩展身份验证协议（EAP）”，RFC 3748，2004年6月。
[RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible Authentication Protocol (EAP) Application", RFC 4072, August 2005.
[RFC4072]Eronen，P.，Hiller，T.，和G.Zorn，“直径可扩展认证协议（EAP）应用”，RFC 4072，2005年8月。
[RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, Authorization, and Accounting (AAA) Key Management", BCP 132, RFC 4962, July 2007.
[RFC4962]Housley，R.和B.Aboba，“认证、授权和记帐（AAA）密钥管理指南”，BCP 132，RFC 4962，2007年7月。
[WEPSEC] Petroni, N. and W. Arbaugh, "The Dangers of Mitigating Security Design Flaws: A Wireless Case Study", January 2003.
[WEPSEC]Petroni，N.和W.Arbaugh，“缓解安全设计缺陷的危险：无线案例研究”，2003年1月。
Authors' Addresses
作者地址
Scott G. Kelly Aruba Networks 1322 Crossman Ave Sunnyvale, CA 94089 US
美国加利福尼亚州桑尼维尔市克罗斯曼大道1322号斯科特·G·凯利阿鲁巴网络公司，邮编94089
EMail: scott@hyperthought.com
EMail: scott@hyperthought.com
T. Charles Clancy DoD Laboratory for Telecommunications Sciences 8080 Greenmead Drive College Park, MD 20740 US
T.Charles Clancy国防部电信科学实验室8080美国马里兰州格林米德大道学院公园20740
EMail: clancy@LTSnet.net
EMail: clancy@LTSnet.net