draft-ietf-opsawg-capwap-hybridmac-07.txt | draft-ietf-opsawg-capwap-hybridmac-08.txt | |||
---|---|---|---|---|
Network Working Group C. Shao | Network Working Group C. Shao | |||
Internet-Draft H. Deng | Internet-Draft H. Deng | |||
Intended status: Standards Track China Mobile | Intended status: Standards Track China Mobile | |||
Expires: June 6, 2015 R. Pazhyannur | Expires: June 21, 2015 R. Pazhyannur | |||
Cisco Systems | Cisco Systems | |||
F. Bari | F. Bari | |||
AT&T | AT&T | |||
R. Zhang | R. Zhang | |||
China Telecom | China Telecom | |||
S. Matsushima | S. Matsushima | |||
SoftBank Telecom | SoftBank Telecom | |||
December 3, 2014 | December 18, 2014 | |||
IEEE 802.11 MAC Profile for CAPWAP | IEEE 802.11 MAC Profile for CAPWAP | |||
draft-ietf-opsawg-capwap-hybridmac-07 | draft-ietf-opsawg-capwap-hybridmac-08 | |||
Abstract | Abstract | |||
The Control And Provisioning of Wireless Access Points (CAPWAP) | The CAPWAP protocol binding for IEEE 802.11 defines two MAC (Medium | |||
protocol defines two entities: a Wireless Transmission Point (WTP) | Access Control) modes for IEEE 802.11 WTP (Wireless Transmission | |||
and an Access Controller (AC). The CAPWAP protocol binding for IEEE | Point): Split and Local MAC. In the Split MAC mode, the partitioning | |||
802.11 defines two MAC (Medium Access Control) modes for IEEE 802.11 | of encryption/decryption functions are not clearly defined. In the | |||
WTP: Split and Local MAC, and describes the required functionality | Split MAC mode description, IEEE 802.11 encryption is specified as | |||
split between the WTP and AC for each mode. However, in the Split | located in either the AC (Access Controller) or the WTP, with no | |||
MAC mode, the partitioning of encryption/decryption functions are not | clear way for the AC to inform the WTP of where the encryption | |||
clearly defined. In the Split MAC mode description, IEEE 802.11 | functionality should be located. This leads to interoperability | |||
encryption is specified as located in either at the AC or the WTP, | issues, especially when the AC and WTP come from different vendors. | |||
with no clear way for the AC to inform the WTP of where the | To prevent interoperability issues, this specification defines an | |||
encryption functionality should be located. This lack of | IEEE 802.11 MAC profile message element in which each profile | |||
specification leads to interoperability issues, especially when the | specifies an unambiguous division of encryption functionality between | |||
AC and WTP come from different vendors. To prevent interoperability | the WTP and AC. | |||
issues, this specification defines an IEEE 802.11 MAC profile message | ||||
element in which each profile specifies an unambiguous division of | ||||
encryption functionality between the WTP and AC. The IEEE 802.11 MAC | ||||
profile is used as follows: the WTP informs the AC of the supported | ||||
profiles during the discovery or join process and the AC configures | ||||
the WTP with one of the supported profiles when configuring the WLAN. | ||||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on June 21, 2015. | ||||
This Internet-Draft will expire on June 6, 2015. | ||||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2014 IETF Trust and the persons identified as the | Copyright (c) 2014 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
described in the Simplified BSD License. | described in the Simplified BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
2. IEEE MAC Profile Descriptions . . . . . . . . . . . . . . . . 4 | 2. IEEE MAC Profile Descriptions . . . . . . . . . . . . . . . . 4 | |||
2.1. Split MAC with WTP encryption . . . . . . . . . . . . . . 5 | 2.1. Split MAC with WTP encryption . . . . . . . . . . . . . . 4 | |||
2.2. Split MAC with AC encryption . . . . . . . . . . . . . . 6 | 2.2. Split MAC with AC encryption . . . . . . . . . . . . . . 5 | |||
2.3. IEEE 802.11 MAC Profile Frame Exchange . . . . . . . . . 7 | 2.3. IEEE 802.11 MAC Profile Frame Exchange . . . . . . . . . 6 | |||
3. MAC Profile Message Element Definitions . . . . . . . . . . . 8 | 3. MAC Profile Message Element Definitions . . . . . . . . . . . 7 | |||
3.1. IEEE 802.11 Supported MAC Profiles . . . . . . . . . . . 8 | 3.1. IEEE 802.11 Supported MAC Profiles . . . . . . . . . . . 7 | |||
3.2. IEEE 802.11 MAC Profile . . . . . . . . . . . . . . . . . 9 | 3.2. IEEE 802.11 MAC Profile . . . . . . . . . . . . . . . . . 8 | |||
4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 | 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 | |||
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 | 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 | |||
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 | 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 | 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
8. Normative References . . . . . . . . . . . . . . . . . . . . 10 | 8. Normative References . . . . . . . . . . . . . . . . . . . . 9 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
1. Introduction | 1. Introduction | |||
The CAPWAP protocol supports two MAC modes of operation: Split and | The CAPWAP protocol supports two MAC modes of operation: Split and | |||
Local MAC, as described in [RFC5415], [RFC5416]. However, there are | Local MAC, as described in [RFC5415], [RFC5416]. However, there are | |||
MAC functions that have not been clearly defined. For example IEEE | MAC functions that have not been clearly defined. For example IEEE | |||
802.11 encryption is specified as located in either in the AC or the | 802.11 encryption is specified as located in either in the AC or the | |||
WTP with no clear way to negotiate where it should be located. | WTP with no clear way to negotiate where it should be located. | |||
Because different vendors have different definitions of the MAC mode, | Because different vendors have different definitions of the MAC mode, | |||
many MAC layer functions are mapped differently to either the WTP or | many MAC layer functions are mapped differently to either the WTP or | |||
skipping to change at page 3, line 16 | skipping to change at page 3, line 12 | |||
configurations based on implementation of the two modes by their | configurations based on implementation of the two modes by their | |||
vendor. If there is no clear specification, then operators will | vendor. If there is no clear specification, then operators will | |||
experience interoperability issues with WTPs and ACs from different | experience interoperability issues with WTPs and ACs from different | |||
vendors. | vendors. | |||
Figure 1 from [RFC5416], illustrates how some functions are processed | Figure 1 from [RFC5416], illustrates how some functions are processed | |||
in different places in the Local MAC and Split MAC mode. | in different places in the Local MAC and Split MAC mode. | |||
Specifically, note that in the Split MAC mode the IEEE 802.11 | Specifically, note that in the Split MAC mode the IEEE 802.11 | |||
encryption/decryption is specified as WTP/AC implying that it could | encryption/decryption is specified as WTP/AC implying that it could | |||
be at either location. This is not an issue with Local MAC because | be at either location. This is not an issue with Local MAC because | |||
encryption is always at the Access Controller. | encryption is always at the WTP. | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Functions | Local MAC | Split MAC | | | Functions | Local MAC | Split MAC | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| |Distribution Service | WTP/AC | AC | | | |Distribution Service | WTP/AC | AC | | |||
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| |Integration Service | WTP | AC | | | |Integration Service | WTP | AC | | |||
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| |Beacon Generation | WTP | WTP | | | |Beacon Generation | WTP | WTP | | |||
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
skipping to change at page 4, line 30 | skipping to change at page 3, line 39 | |||
+ |/Defragmentation | | | | + |/Defragmentation | | | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| |Assoc/Disassoc/Reassoc | WTP/AC | AC | | | |Assoc/Disassoc/Reassoc | WTP/AC | AC | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| |Classifying | WTP | AC | | | |Classifying | WTP | AC | | |||
+ IEEE +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + IEEE +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| 802.11 QoS |Scheduling | WTP | WTP/AC | | | 802.11 QoS |Scheduling | WTP | WTP/AC | | |||
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| |Queuing | WTP | WTP | | | |Queuing | WTP | WTP | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| |IEEE 802.1X/EAP | AC | AC | | | |IEEE 802.1X/EAP | AC | AC | | |||
+ IEEE +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + IEEE +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| 802.11 RSN |RSNA Key Management | AC | AC | | | 802.11 RSN |RSNA Key Management | AC | AC | | |||
+ (WPA2) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + (WPA2) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| |IEEE 802.11 | WTP | WTP/AC | | | |IEEE 802.11 | WTP | WTP/AC | | |||
+ |Encryption/Decryption | | | | + |Encryption/Decryption | | | | |||
|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Figure 1: Functions in Local MAC and Split MAC | Figure 1: Functions in Local MAC and Split MAC | |||
To solve this problem, this specification introduces IEEE 802.11 MAC | To solve this problem, this specification introduces IEEE 802.11 MAC | |||
skipping to change at page 9, line 27 | skipping to change at page 8, line 27 | |||
o Type: TBD for IEEE 802.11 MAC Profile | o Type: TBD for IEEE 802.11 MAC Profile | |||
o Profile: The profile is identified by a value as given below | o Profile: The profile is identified by a value as given below | |||
* 0: This refers to the Split MAC Profile with WTP encryption | * 0: This refers to the Split MAC Profile with WTP encryption | |||
* 1: This refers to the Split MAC Profile with AC encryption | * 1: This refers to the Split MAC Profile with AC encryption | |||
4. Security Considerations | 4. Security Considerations | |||
This document does not introduce any new security risks compared to | This document does not introduce any new security risks compared to | |||
[RFC5416]. The negotiation between the WTP and AC is encrypted and | [RFC5416]. The negotiation messages between the WTP and AC have | |||
as a result an attacker cannot interfere with it to force a less | origin authentication and data integrity. As a result an attacker | |||
secure mode choice. The security considerations described in | cannot interfere with the messages to force a less secure mode | |||
[RFC5416] apply here as well. | choice. The security considerations described in [RFC5416] apply | |||
here as well. | ||||
5. IANA Considerations | 5. IANA Considerations | |||
This document requires the following IANA actions: | This document requires the following IANA actions: | |||
o This specification defines two new message elements, IEEE 802.11 | o This specification defines two new message elements, IEEE 802.11 | |||
Supported MAC Profiles (described in Section 3.1) and IEEE 802.11 | Supported MAC Profiles (described in Section 3.1) and IEEE 802.11 | |||
MAC Profile (described in Section 3.2). These elements needs to | MAC Profile (described in Section 3.2). These elements needs to | |||
be registered in the existing CAPWAP Message Element Type | be registered in the existing CAPWAP Message Element Type | |||
registry, defined in [RFC5415]. The values for these elements | registry, defined in [RFC5415]. The values for these elements | |||
skipping to change at page 10, line 7 | skipping to change at page 9, line 8 | |||
IEEE 802.11 MAC Profile TBD2 | IEEE 802.11 MAC Profile TBD2 | |||
o The IEEE 802.11 Supported MAC Profiles message element and IEEE | o The IEEE 802.11 Supported MAC Profiles message element and IEEE | |||
802.11 MAC Profile message element include a Profile Field (as | 802.11 MAC Profile message element include a Profile Field (as | |||
defined in Section 3.2). The Profile field in the IEEE 802.11 | defined in Section 3.2). The Profile field in the IEEE 802.11 | |||
Supported MAC Profiles denotes the MAC profiles supported by the | Supported MAC Profiles denotes the MAC profiles supported by the | |||
WTP. The profile field in the IEEE MAC profile denotes MAC | WTP. The profile field in the IEEE MAC profile denotes MAC | |||
profile assigned to the WTP. The namespace for the field is 8 | profile assigned to the WTP. The namespace for the field is 8 | |||
bits (0-255). This specification defines two values, zero (0) and | bits (0-255). This specification defines two values, zero (0) and | |||
one (1) as described below. The remaining values (2-255) are | one (1) as described below. The remaining values (2-255) are | |||
controlled and maintained by IANA and require an Expert Review. | controlled and maintained by IANA and require an Expert Review. | |||
IANA needs to create a registry called CAPWAP IEEE 802.11 Split | IANA needs to create a new sub-registry called IEEE 802.11 Split | |||
MAC Profile. The registry format is given below. | MAC Profile and add the new sub-registry to the existing registry | |||
"Control And Provisioning of Wireless Access Points (CAPWAP) | ||||
Parameters". The registry format is given below. | ||||
Profile Type Value Reference | Profile Type Value Reference | |||
Split MAC with WTP encryption 0 | Split MAC with WTP encryption 0 | |||
Split MAC with AC encryption 1 | Split MAC with AC encryption 1 | |||
6. Contributors | 6. Contributors | |||
Yifan Chen chenyifan@chinamobile.com | Yifan Chen chenyifan@chinamobile.com | |||
Naibao Zhou zhounaibao@chinamobile.com | Naibao Zhou zhounaibao@chinamobile.com | |||
End of changes. 10 change blocks. | ||||
44 lines changed or deleted | 40 lines changed or added | |||
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |