idnits 2.17.00 (12 Aug 2021) /tmp/idnits62998/draft-ietf-opsawg-capwap-hybridmac-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 18, 2014) is 2704 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Shao 3 Internet-Draft H. Deng 4 Intended status: Standards Track China Mobile 5 Expires: June 21, 2015 R. Pazhyannur 6 Cisco Systems 7 F. Bari 8 AT&T 9 R. Zhang 10 China Telecom 11 S. Matsushima 12 SoftBank Telecom 13 December 18, 2014 15 IEEE 802.11 MAC Profile for CAPWAP 16 draft-ietf-opsawg-capwap-hybridmac-08 18 Abstract 20 The CAPWAP protocol binding for IEEE 802.11 defines two MAC (Medium 21 Access Control) modes for IEEE 802.11 WTP (Wireless Transmission 22 Point): Split and Local MAC. In the Split MAC mode, the partitioning 23 of encryption/decryption functions are not clearly defined. In the 24 Split MAC mode description, IEEE 802.11 encryption is specified as 25 located in either the AC (Access Controller) or the WTP, with no 26 clear way for the AC to inform the WTP of where the encryption 27 functionality should be located. This leads to interoperability 28 issues, especially when the AC and WTP come from different vendors. 29 To prevent interoperability issues, this specification defines an 30 IEEE 802.11 MAC profile message element in which each profile 31 specifies an unambiguous division of encryption functionality between 32 the WTP and AC. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on June 21, 2015. 50 Copyright Notice 52 Copyright (c) 2014 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. IEEE MAC Profile Descriptions . . . . . . . . . . . . . . . . 4 69 2.1. Split MAC with WTP encryption . . . . . . . . . . . . . . 4 70 2.2. Split MAC with AC encryption . . . . . . . . . . . . . . 5 71 2.3. IEEE 802.11 MAC Profile Frame Exchange . . . . . . . . . 6 72 3. MAC Profile Message Element Definitions . . . . . . . . . . . 7 73 3.1. IEEE 802.11 Supported MAC Profiles . . . . . . . . . . . 7 74 3.2. IEEE 802.11 MAC Profile . . . . . . . . . . . . . . . . . 8 75 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 76 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 77 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9 78 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 79 8. Normative References . . . . . . . . . . . . . . . . . . . . 9 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 82 1. Introduction 84 The CAPWAP protocol supports two MAC modes of operation: Split and 85 Local MAC, as described in [RFC5415], [RFC5416]. However, there are 86 MAC functions that have not been clearly defined. For example IEEE 87 802.11 encryption is specified as located in either in the AC or the 88 WTP with no clear way to negotiate where it should be located. 89 Because different vendors have different definitions of the MAC mode, 90 many MAC layer functions are mapped differently to either the WTP or 91 the AC by different vendors. Therefore, depending upon the vendor, 92 the operators in their deployments have to perform different 93 configurations based on implementation of the two modes by their 94 vendor. If there is no clear specification, then operators will 95 experience interoperability issues with WTPs and ACs from different 96 vendors. 98 Figure 1 from [RFC5416], illustrates how some functions are processed 99 in different places in the Local MAC and Split MAC mode. 100 Specifically, note that in the Split MAC mode the IEEE 802.11 101 encryption/decryption is specified as WTP/AC implying that it could 102 be at either location. This is not an issue with Local MAC because 103 encryption is always at the WTP. 105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 106 | Functions | Local MAC | Split MAC | 107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 108 | |Distribution Service | WTP/AC | AC | 109 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 110 | |Integration Service | WTP | AC | 111 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 112 | |Beacon Generation | WTP | WTP | 113 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 114 | |Probe Response Generation| WTP | WTP | 115 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 116 | Function |Power Mgmt | WTP | WTP | 117 + |/Packet Buffering | | | 118 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 119 | |Fragmentation | WTP | WTP/AC | 120 + |/Defragmentation | | | 121 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 122 | |Assoc/Disassoc/Reassoc | WTP/AC | AC | 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 | |Classifying | WTP | AC | 125 + IEEE +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 | 802.11 QoS |Scheduling | WTP | WTP/AC | 127 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 | |Queuing | WTP | WTP | 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 | |IEEE 802.1X/EAP | AC | AC | 131 + IEEE +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 | 802.11 RSN |RSNA Key Management | AC | AC | 133 + (WPA2) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 | |IEEE 802.11 | WTP | WTP/AC | 135 + |Encryption/Decryption | | | 136 |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 Figure 1: Functions in Local MAC and Split MAC 140 To solve this problem, this specification introduces IEEE 802.11 MAC 141 profile. The MAC profile unambiguously specifies where the various 142 MAC functionality should be located. 144 2. IEEE MAC Profile Descriptions 146 A IEEE MAC Profile refers to a description of how the MAC 147 functionality is split between the WTP and AC shown in Figure 1. 149 2.1. Split MAC with WTP encryption 151 The functional split for the Split MAC with WTP encryption is 152 provided in Figure 2. This profile is similar to the Split MAC 153 description in [RFC5416], except that IEEE 802.11 encryption/ 154 decryption is at the WTP. Note that fragmentation is always done at 155 the same entity as the encryption. Consequently, in this profile 156 fragmentation/defragmentation is also done only at the WTP. Note 157 that scheduling functionality is denoted as WTP/AC. As explained in 158 [RFC5416], this means that the admission control component of IEEE 159 802.11 resides on the AC, the real-time scheduling and queuing 160 functions are on the WTP. 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | Functions | Profile | 164 | | 0 | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | |Distribution Service | AC | 167 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | |Integration Service | AC | 169 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | |Beacon Generation | WTP | 171 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | |Probe Response Generation| WTP | 173 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 | Function |Power Mgmt | WTP | 175 + |/Packet Buffering | | 176 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | |Fragmentation | WTP | 178 + |/Defragmentation | | 179 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | |Assoc/Disassoc/Reassoc | AC | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | |Classifying | AC | 183 + IEEE +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | 802.11 QoS |Scheduling | WTP/AC | 185 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | |Queuing | WTP | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | |IEEE 802.1X/EAP | AC | 189 + IEEE +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | 802.11 RSN |RSNA Key Management | AC | 191 + (WPA2) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | |IEEE 802.11 | WTP | 193 + |Encryption/Decryption | | 194 |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 Figure 2: Functions in Split MAC with WTP Encryption 198 2.2. Split MAC with AC encryption 200 The functional split for the Split MAC with AC encryption is provided 201 in Figure 3. This profile is similar to the Split MAC in [RFC5416] 202 except that IEEE 802.11 encryption/decryption is at the AC. Since 203 fragmentation is always done at the same entity as the encryption, in 204 this profile, AC does fragmentation/defragmentation. 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | Functions | Profile | 208 | | 1 | 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | |Distribution Service | AC | 211 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | |Integration Service | AC | 213 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | |Beacon Generation | WTP | 215 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | |Probe Response Generation| WTP | 217 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | Function |Power Mgmt | WTP | 219 + |/Packet Buffering | | 220 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | |Fragmentation | AC | 222 + |/Defragmentation | | 223 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | |Assoc/Disassoc/Reassoc | AC | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | |Classifying | AC | 227 + IEEE +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | 802.11 QoS |Scheduling | WTP | 229 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | |Queuing | WTP | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | |IEEE 802.1X/EAP | AC | 233 + IEEE +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | 802.11 RSN |RSNA Key Management | AC | 235 + (WPA2) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | |IEEE 802.11 | AC | 237 + |Encryption/Decryption | | 238 |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 Figure 3: Functions in Split MAC with AC encryption 242 2.3. IEEE 802.11 MAC Profile Frame Exchange 244 An example of message exchange using the IEEE 802.11 MAC Profile 245 message element is shown in Figure 4. The WTP informs the AC of the 246 various MAC profiles it supports. This happens either in a Discovery 247 Request message or the Join Request message. The AC determines the 248 appropriate profile and configures the WTP with the profile while 249 configuring the WLAN. 251 +-+-+-+-+-+-+ +-+-+-+-+-+-+ 252 | WTP | | AC | 253 +-+-+-+-+-+-+ +-+-+-+-+-+-+ 254 |Join Request[Supported IEEE 802.11 | 255 | MAC Profiles ] | 256 |---------------------------------------->| 257 | | 258 |Join Response | 259 |<----------------------------------------| 260 | | 261 |IEEE 802.11 WLAN Config. Request [ | 262 | IEEE 802.11 Add WLAN, | 263 | IEEE 802.11 MAC Profile | 264 | ] | 265 |<----------------------------------------| 266 | | 267 |IEEE 802.11 WLAN Config. Response | 268 |---------------------------------------->| 270 Figure 4: Message Exchange For Negotiating MAC Profile 272 3. MAC Profile Message Element Definitions 274 3.1. IEEE 802.11 Supported MAC Profiles 276 The IEEE 802.11 Supported MAC Profile message element allows the WTP 277 to communicate the profiles it supports. The Discovery Request 278 message, Primary Discovery Request message, and Join Request message 279 may include one such message element. 281 0 1 2 3 282 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 283 +=+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 284 | Num_Profiles | Profile_1 | Profile_[2..N].. 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 287 Figure 5: IEEE 802.11 Supported MAC Profiles 289 o Type: TBD for IEEE 802.11 Supported MAC Profiles 290 o Num_Profiles >=1: This refers to number of profiles present in 291 this message element. There must be at least one profile. 292 o Profile: Each profile is identified by a value specified in 293 Section 3.2. 295 3.2. IEEE 802.11 MAC Profile 297 The IEEE 802.11 MAC Profile message element allows the AC to select a 298 profile. This message element may be provided along with the IEEE 299 802.11 ADD WLAN message element while configuring a WLAN on the WTP. 301 0 1 2 3 4 5 6 7 302 +=+-+-+-+-+-+-+-+ 303 | Profile | 304 +-+-+-+-+-+-+-+-+ 306 Figure 6: IEEE 802.11 MAC Profile 308 o Type: TBD for IEEE 802.11 MAC Profile 309 o Profile: The profile is identified by a value as given below 311 * 0: This refers to the Split MAC Profile with WTP encryption 312 * 1: This refers to the Split MAC Profile with AC encryption 314 4. Security Considerations 316 This document does not introduce any new security risks compared to 317 [RFC5416]. The negotiation messages between the WTP and AC have 318 origin authentication and data integrity. As a result an attacker 319 cannot interfere with the messages to force a less secure mode 320 choice. The security considerations described in [RFC5416] apply 321 here as well. 323 5. IANA Considerations 325 This document requires the following IANA actions: 327 o This specification defines two new message elements, IEEE 802.11 328 Supported MAC Profiles (described in Section 3.1) and IEEE 802.11 329 MAC Profile (described in Section 3.2). These elements needs to 330 be registered in the existing CAPWAP Message Element Type 331 registry, defined in [RFC5415]. The values for these elements 332 needs to be between 1024 and 2047 (see Section 15.7 in [RFC5415]). 334 CAPWAP Protocol Message Element Type Value 335 IEEE 802.11 Supported MAC Profiles TBD1 336 IEEE 802.11 MAC Profile TBD2 337 o The IEEE 802.11 Supported MAC Profiles message element and IEEE 338 802.11 MAC Profile message element include a Profile Field (as 339 defined in Section 3.2). The Profile field in the IEEE 802.11 340 Supported MAC Profiles denotes the MAC profiles supported by the 341 WTP. The profile field in the IEEE MAC profile denotes MAC 342 profile assigned to the WTP. The namespace for the field is 8 343 bits (0-255). This specification defines two values, zero (0) and 344 one (1) as described below. The remaining values (2-255) are 345 controlled and maintained by IANA and require an Expert Review. 346 IANA needs to create a new sub-registry called IEEE 802.11 Split 347 MAC Profile and add the new sub-registry to the existing registry 348 "Control And Provisioning of Wireless Access Points (CAPWAP) 349 Parameters". The registry format is given below. 351 Profile Type Value Reference 352 Split MAC with WTP encryption 0 353 Split MAC with AC encryption 1 355 6. Contributors 357 Yifan Chen chenyifan@chinamobile.com 359 Naibao Zhou zhounaibao@chinamobile.com 361 7. Acknowledgments 363 The authors are grateful for extremely valuable suggestions from 364 Dorothy Stanley in developing this specification. 366 Guidance from management team: Melinda Shore, Scott Bradner, Chris 367 Liljenstolpe, Benoit Claise, Joel Jaeggli, Dan Romascanu are highly 368 appreciated. 370 8. Normative References 372 [RFC5415] Calhoun, P., Montemurro, M., and D. Stanley, "Control And 373 Provisioning of Wireless Access Points (CAPWAP) Protocol 374 Specification", RFC 5415, March 2009. 376 [RFC5416] Calhoun, P., Montemurro, M., and D. Stanley, "Control and 377 Provisioning of Wireless Access Points (CAPWAP) Protocol 378 Binding for IEEE 802.11", RFC 5416, March 2009. 380 Authors' Addresses 382 Chunju Shao 383 China Mobile 384 No.32 Xuanwumen West Street 385 Beijing 100053 386 China 388 Email: shaochunju@chinamobile.com 389 Hui Deng 390 China Mobile 391 No.32 Xuanwumen West Street 392 Beijing 100053 393 China 395 Email: denghui@chinamobile.com 397 Rajesh S. Pazhyannur 398 Cisco Systems 399 170 West Tasman Drive 400 San Jose, CA 95134 401 USA 403 Email: rpazhyan@cisco.com 405 Farooq Bari 406 AT&T 407 7277 164th Ave NE 408 Redmond WA 98052 409 USA 411 Email: farooq.bari@att.com 413 Rong Zhang 414 China Telecom 415 No.109 Zhongshandadao avenue 416 Guangzhou 510630 417 China 419 Email: zhangr@gsta.com 421 Satoru Matsushima 422 SoftBank Telecom 423 1-9-1 Higashi-Shinbashi, Munato-ku 424 Tokyo 425 Japan 427 Email: satoru.matsushima@g.softbank.co.jp