idnits 2.17.1 draft-narasimhan-capwap-slapp-evaluation-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1090. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1067. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1074. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1080. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 25 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 109 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 636 has weird spacing: '...between major...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 6, 2005) is 6898 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) == Unused Reference: '6' is defined on line 998, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 1014, but no explicit reference was found in the text ** Downref: Normative reference to an Historic draft: draft-narasimhan-ietf-slapp (ref. '2') -- Possible downref: Non-RFC (?) normative reference: ref. '3' ** Downref: Normative reference to an Informational RFC: RFC 3990 (ref. '4') == Outdated reference: A later version (-04) exists of draft-ietf-capwap-objectives-00 ** Downref: Normative reference to an Informational draft: draft-ietf-capwap-objectives (ref. '7') == Outdated reference: A later version (-05) exists of draft-rescorla-dtls-04 ** Downref: Normative reference to an Historic draft: draft-rescorla-dtls (ref. '8') ** Obsolete normative reference: RFC 2246 (ref. '9') (Obsoleted by RFC 4346) -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' == Outdated reference: A later version (-03) exists of draft-krishna-slrrp-01 -- Possible downref: Normative reference to a draft: ref. '12' Summary: 10 errors (**), 0 flaws (~~), 9 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 CAPWAP Working Group P. Narasimhan 2 Internet-Draft Aruba Networks 3 Expires: December 8, 2005 D. Harkins 4 Trapeze Networks 5 S. Ponnuswamy 6 Aruba Networks 7 S. Hares 8 NextHop 9 June 6, 2005 11 SLAPP Evaluation 12 draft-narasimhan-capwap-slapp-evaluation-00 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on December 8, 2005. 39 Copyright Notice 41 Copyright (C) The Internet Society (2005). 43 Abstract 45 The CAPWAP Working Group (WG) is currently looking into defining a 46 protocol that would enable interoperability in an IEEE 802.11 based 47 wireless local area network (WLAN) comprised of Wireless Termination 48 Points (WTP) and Access Controllers (AC) belonging to different 49 vendors. 51 This document presents a self-review of Simple Light Access Point 52 Protocol (SLAPP), one of the candidate protocol proposals submitted 53 to the CAPWAP WG for consideration as a CAPWAP protocol. The WG has 54 requested that the authors of all candidate proposals to provide a 55 document which evaluates how their submission meets the objectives, 56 taxonomy, and problem statement. 58 Table of Contents 60 1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 4 61 1.1 Conventions used in this document . . . . . . . . . . . . 4 62 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2.1 SLAPP Highlights . . . . . . . . . . . . . . . . . . . . . 4 64 2.1.1 Extensible Architecture . . . . . . . . . . . . . . . 4 65 2.1.2 Reuse Existing Standards and Protocols . . . . . . . . 5 66 2.1.3 Simple Control Protocol for 802.11 . . . . . . . . . . 5 67 3. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 3.1 Mandatory Objectives . . . . . . . . . . . . . . . . . . . 6 69 3.1.1 Logical Groups . . . . . . . . . . . . . . . . . . . . 6 70 3.1.2 Support for Traffic Separation . . . . . . . . . . . . 7 71 3.1.3 Wireless Terminal Transparency . . . . . . . . . . . . 7 72 3.1.4 Configuration Consistency . . . . . . . . . . . . . . 8 73 3.1.5 Firmware Trigger . . . . . . . . . . . . . . . . . . . 9 74 3.1.6 Monitoring and Exchange of System-Wide Resource 75 State . . . . . . . . . . . . . . . . . . . . . . . . 10 76 3.1.7 Resource Control Objective . . . . . . . . . . . . . . 11 77 3.1.8 CAPWAP Protocol Security . . . . . . . . . . . . . . . 12 78 3.1.9 System-Wide Security . . . . . . . . . . . . . . . . . 13 79 3.1.10 802.11i Considerations . . . . . . . . . . . . . . . 14 80 3.1.11 Interoperability Objective . . . . . . . . . . . . . 15 81 3.1.12 Protocol Specifications . . . . . . . . . . . . . . 15 82 3.1.13 Vendor Independence . . . . . . . . . . . . . . . . 16 83 3.1.14 Vendor Flexibility . . . . . . . . . . . . . . . . . 16 84 3.2 Desirable Objectives . . . . . . . . . . . . . . . . . . . 17 85 3.2.1 Multiple Authentication Mechanisms . . . . . . . . . . 17 86 3.2.2 Support for Future Technologies . . . . . . . . . . . 17 87 3.2.3 Support for New IEEE Requirements . . . . . . . . . . 18 88 3.2.4 Interconnection Objective . . . . . . . . . . . . . . 19 89 3.2.5 WTP Access Control . . . . . . . . . . . . . . . . . . 19 90 3.3 Rejected Objectives . . . . . . . . . . . . . . . . . . . 20 91 3.3.1 Support for Non-CAPWAP WTPs . . . . . . . . . . . . . 20 92 3.4 Operator Requirements . . . . . . . . . . . . . . . . . . 20 93 3.4.1 AP Fast Handoff . . . . . . . . . . . . . . . . . . . 20 94 3.5 Compliance table . . . . . . . . . . . . . . . . . . . . . 21 95 4. Security Considerations . . . . . . . . . . . . . . . . . . 22 96 5. IANA considerations . . . . . . . . . . . . . . . . . . . . 22 97 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 22 98 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 23 100 Intellectual Property and Copyright Statements . . . . . . . 25 102 1. Definitions 104 1.1 Conventions used in this document 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in RFC 2119 [1]. 110 2. Introduction 112 The IETF CAPWAP Working Group is working towards defining a protocol 113 aimed at addressing the interoperability between IEEE 802.11 Wireless 114 Termination Points (WTP) and Access Controllers (AC) belonging to 115 different vendors as stated in the CAPWAP problem statement [4]. The 116 CAPWAP architecture taxonomy document [3] documents the multiple 117 architectural choices present in the industry based on inputs from 118 WLAN vendors and others. 120 The CAPWAP objectives draft [7] documents the list of requirements 121 that a CAPWAP protocol must satisfy in order to enable multi-vendor 122 interoperability between WTPs and ACs. The CAPWAP WG invited 123 proposals for a candidate CAPWAP protocol and requested that the 124 authors of each candidate proposal submit another draft evaluating 125 their submission against the requirements in the CAPWAP objectives 126 draft [7]. 128 The SLAPP protocol draft [2] was submitted to the CAPWAP WG for 129 consideration as a candidate proposal for a CAPWAP protocol. This 130 document is a self-evaluation by the authors of the SLAPP draft of 131 their submission. 133 2.1 SLAPP Highlights 135 The highlights of the SLAPP protocol draft as presented below. 137 2.1.1 Extensible Architecture 139 SLAPP provides a solution to the CAPWAP problem that is explicitly 140 separated into two components - a technology-independent component to 141 enable a WTP to discover and authenticate an AC, and to negotiate a 142 technology-dependent control protocol during the discovery phase. 143 This decoupling of the technology-dependent components from the 144 technology-independent base provides us with extensibility to other 145 technologies as they mature without having to explicitly build it in 146 today. 148 The interoperability issues within WLANs using IEEE 802.11 are 149 reasonably well understood today. So the CAPWAP WG can focus on 150 solving these issues of today while not worrying about similar issues 151 facing technologies that could mature in the future. 153 The base SLAPP protocol is also useful for secure discovery and 154 authentication for more generic applications, including non-wireless 155 ones, that require a central controller to control and manage one or 156 more network elements from a different vendor. For example, the base 157 SLAPP protocol could be used for secure discovery and authentication 158 in SLRRP [12]. 160 2.1.2 Reuse Existing Standards and Protocols 162 The authors of the SLAPP draft strongly believe that a CAPWAP 163 protocol should use existing methods, wherever such methods are 164 readily available, without re-inventing the wheel on what are major 165 components of a 802.11 control protocol. As a result of this, SLAPP 166 inherits the benefits of public reviews and implementations of these 167 existing methods over a period of time enhancing the robustness of 168 the protocol and the reusability of existing implementations. 170 For example, the security component of SLAPP uses DTLS [8], which is 171 a connection-less (datagram) version of the TLS protocol [9] whose 172 security has been reviewed by competent and professional 173 cryptographers and is believed to be secure [11]. DTLS, as TLS, can 174 operate over IPv4 or IPv6. The myriad of authentication options in 175 DTLS allows for a wide array of options with which to secure the 176 channel between the WTP and the AC -- mutual or certificate based, 177 symmetric, asymmetric, or non-mutual, anonymous, etc. Using DTLS 178 lessens the need for the CAPWAP WG to go through additional reviews 179 of the security aspects of the protocol, thus speeding up the work of 180 the WG. 182 For the tunneling of frames between a WTP and an AC, SLAPP uses 183 Generic Routing Encapsulation (GRE) [5] which has been extensively 184 deployed. This removes the need to define a new tunneling mechanism 185 for a CAPWAP protocol. 187 Both TLS and GRE have been used extensively over the last decade or 188 so. Given the tight schedule that the CAPWAP WG is operating under, 189 sparing the group the additional chore of reviews on security and 190 tunneling mechanisms is a highly desirable goal. The authors of the 191 SLAPP draft believe that their submission achieves this goal. 193 2.1.3 Simple Control Protocol for 802.11 195 The SLAPP control protocol for 802.11 defines a simple state machine 196 and a list of operating modes that have been chosen based on the 197 architectural choices prevalent in the market place today. The 198 control protocol closely aligns itself with the specifications 199 present in the IEEE 802.11 standard while avoiding extraneous 200 operating modes not currently defined by 802.11. 202 The SLAPP proposal reflects the collective experience of the authors 203 in deploying large WLANs covering all the architectural variants 204 described in the submission. 206 3. Objectives 208 SLAPP is a simple light-weight protocol that supports communication 209 between Wireless Termination Points and Access Controllers. The 210 communication between the Wireless Termination points and the Access 211 Controllers occurs over a DTLS connection. 213 3.1 Mandatory Objectives 215 This section contains all of the objectives that have been considered 216 as being mandatory in order for a protocol to be consider. 218 3.1.1 Logical Groups 220 Classification: Architecture 222 3.1.1.1 Protocol Requirement 224 "WLAN deployment trends require CAPWAP protocol to be capable of 225 controlling and managing physical WTPS in terms of logical groups." 227 This is being interpreted as stating that a protocol must allow for 228 the WTP to provide service for multiple SSIDs (or WLANs), each with a 229 distinct BSSID. 231 3.1.1.2 Protocol Evaluation 233 In SLAPP, the WTPs may support one or more BSSIDS. The WTPs indicate 234 the number of BSSIDs supported to the AC using a specific message 235 (Section 6.1.3.1.12). This in turn defines the number of logical 236 groups supported by that specific WTP. The AC may choose to 237 configure any number of logical groups per WTP, subject to the 238 maximum number indicated by the WTPs. The BSSID index element 239 defined in SLAPP (Section 6.1.3.1.13) is used to configure all BSSID- 240 specific parameters. The WTPs may use the same element to convey 241 BSSID-specific status to the AC. 243 The SLAPP protocol allows the AC to create a logical group by 244 defining a WLAN with a specific BSSID, ESSID and associated 245 parameters. Each logical group can have a separate set of security 246 policies, QoS policies and any other policies that can be defined 247 using the configuration parameters specified in Section 6.1.3.2.6 of 248 the SLAPP draft. The data between AC and WTP or between an 802.11 249 STA and WTP can also be identified per logical group, based on the 250 BSSID and associated identifiers. 252 3.1.1.3 Compliance 254 SLAPP satisfies this requirement. 256 3.1.2 Support for Traffic Separation 258 Classification: Operations 260 3.1.2.1 Protocol Requirement 262 "In order to maintain the separation of control and data traffic, the 263 CAPWAP protocol is required to define control messages such that they 264 do not involve piggybacking or other combination with data traffic." 266 This requirement specifies that a strict separation between control 267 and data traffic must be established and maintained and that it is 268 not possible to mix the two or somehow carry traffic for one in the 269 other. 271 3.1.2.2 Protocol Evaluation 273 SLAPP has an 802.11 Control Protocol as an option decided upon during 274 WTP and AC discovery. This protocol has two components, one for 275 sending control and provisioning messages between the WTP and AC, and 276 another for tunneling data traffic between the WTP and AC. 278 Control traffic has its own SLAPP Control Protocol header and is sent 279 as UDP traffic to the AC. Data traffic is tunneled via GRE. Control 280 and data are uniquely identified and separation between the two is 281 maintained by SLAPP. It is not possible to send a data frame as a 282 Control message and vice versa. 284 3.1.2.3 Compliance 286 SLAPP satisfies this requirement. 288 3.1.3 Wireless Terminal Transparency 290 Classification: Operations 292 3.1.3.1 Protocol Requirement 294 "Wireless Terminals should not be required to recognize or be aware 295 of the CAPWAP protocol." 297 The use of SLAPP between the WTPs and ACs should be transparent to 298 the 802.11 stations. 300 3.1.3.2 Protocol Evaluation 302 SLAPP is a protocol defined between ACs and WTPs that enable an AC to 303 configure and manage one or more WTPs. SLAPP messages are addressed 304 between ACs and WTPs. They do not extend to the 802.11 wireless link 305 and hence are transparent to the 802.11 stations. Once a BSS is 306 configured by an AC on a WTP, the 802.11 stations do not see a 307 difference between an WTP managed using SLAPP (using any of the 308 CAPWAP modes defined in Section 6.1.3 of the SLAPP draft) and an 309 autonomous WTP (as defined in the CAPWAP architecture taxonomy 310 document [3]). 312 3.1.3.3 Compliance 314 SLAPP satisfies this requirement. 316 3.1.4 Configuration Consistency 318 Classification: Operations 320 3.1.4.1 Protocol Requirement 322 "The CAPWAP protocol must allow for regular exchange of state 323 information between WTPs and WLAN controller. Examples of State 324 information include WTP processing load and memory utilization." 326 Our interpretation of this requirement is that the CAPWAP protocol 327 must support a mechanism to transport WTP capability information so 328 that an AC can make consistent configuration decisions for the WTPs 329 under its control. In addition, we interpret that the WTP must be 330 capable of sending periodic status information to the AC so that the 331 AC can perform dynamic and run-time re-configuration to optimize the 332 overall WLAN performance. 334 We also enhanced this understanding to allow different configurations 335 based on the type of sub-protocol. 337 3.1.4.2 Protocol Evaluation 339 SLAPP requires that the WTPs communicate their capabilities during 340 the initialization process. The capability of a WTP may be limited 341 by the regulatory domain as well as by the WTP hardware and software. 342 The capability exchange mechanism allows AC to have a consistent 343 picture of the capabilities of the WTPs. 345 After the capability exchange, the AC is responsible for sending 346 configuration information to the WTPs. Some configuration parameters 347 have default values and need not be explicitly configured. The 348 defaults can be overridden by the AC with an explicit configuration 349 message. SLAPP also defines a set of mandatory configuration 350 parameters that MUST be explicitly configured by an AC for the WLAN 351 to be operational. This ensures consistency across WTPs, where 352 certain parameters have to be configured and optimized globally 353 (across WTPs). 355 The event mechanism defined in SLAPP (6.1.3.1.27) allows the AC to 356 configure events at the WTP with different importance levels. 357 Specific events such as radar detection and excessive retry and a 358 generic 802.11 management and action event are currently defined in 359 SLAPP. Additional events can be easily added. The event mechanism 360 provides the AC with instantaneous report of specific events so that 361 the AC can make corrective actions if necessary. 363 The WTP statistics and status may be obtained by an AC at any time by 364 sending a request to the WTP. If desired, the AC may periodically 365 send statistics or status requests such as those related to load 366 (e.g., transmit, receive and association statistics) and 367 instantaneous status such as Noise Floor. The AC may also configure 368 the WTP to generate an event for Noise Floor, when the Noise Floor 369 exceeds a specific value. 371 The capability, configuration, statistics, status and event 372 mechanisms defined in SLAPP are fully extensible and additional 373 elements can be easily added, if desired, as the IEEE standards 374 evolve. 376 3.1.4.3 Compliance 378 SLAPP satisfies this requirement. 380 3.1.5 Firmware Trigger 382 Classification: Operations 384 Protocol Evaluation: The CAPWAP protocol must support a trigger for 385 delivery of firmware updates. 387 3.1.5.1 Protocol Evaluation 389 SLAPP has an firmware download mechanism defined in the form of an 390 Image Download protocol. The image download process uses the 391 security context negotiated between an AC and a WTP using DTLS. 392 Other mechanisms such as TFTP would be outside the context of the 393 DTLS session and hence would not be secure for downloading firmware 394 to the WTPs. 396 During SLAPP discovery phase, a WTP identifies its hardware and 397 current software version numbers. If the AC determines that a new 398 image is available for this WTP, then it selects the Image Download 399 protocol so that the new version of the firmware can be transferred 400 to the WTP. 402 The authors of the SLAPP draft recognize that a simpler trigger is 403 possible to include in the 802.11 control protocol state machine to 404 initiate the image download protocol. This will be added in the next 405 version of the SLAPP draft to fully satisfy the requirement. 407 3.1.5.2 Compliance 409 SLAPP partially satisfies this requirement 411 3.1.6 Monitoring and Exchange of System-Wide Resource State 413 Classification: Operations 415 3.1.6.1 Protocol Requirement 417 "The CAPWAP protocol must allow for the exchange of statistics, 418 congestion and other WLAN state information." 420 Our interpretation of this requirement includes statistics for any 421 type of media define: 802.11, 802.15, or 802.16. 423 3.1.6.2 Protocol Evaluation 425 The SLAPP protocol defines a set of capability, configuration, 426 statistics, status and event elements that can be used to monitor and 427 exchange the system-wide resource state. SLAPP supports an extensive 428 set of statistics (6.1.3.1.30, 6.1.3.1.31, 6.1.3.1.32, and 429 6.1.3.1.33) that can be used by the AC to request specific class of 430 statistics. In addition to the aggregate statistics, the status 431 (6.1.3.1.34) element defined in SLAPP can be used to obtain the 432 instantaneous status. 434 The event mechanism (See 6.1.3.1.35-39) defined in SLAPP allows the 435 AC to configure specific events at the WTP for notification. The AC 436 may choose to re-configure or re-adjust system-wide parameters based 437 on statistics, status or events received from a WTP, using one of the 438 configuration elements. Additional capability, configuration, 439 statistics, status or event elements can be easily added to the SLAPP 440 protocol, if required. 442 3.1.6.3 Compliance 444 SLAPP satisfies this requirement. 446 3.1.7 Resource Control Objective 448 Classification: Operations 450 3.1.7.1 Protocol Requirement 452 "The CAPWAP protocol must maintain IEEE 802.11e mappings across the 453 switching and the wireless segment." 455 802.11e is one of the first wireless standards to support QoS. While 456 802.16 supports QoS over wireless, we also anticipate other emerging 457 standards such as 802.15x and 802.20 to have specific QoS 458 requirements. We interpret this objective as allowing all sub- 459 protocols to handle QoS information. In addition, this objective 460 requires the protocol to support emerging 802.11x standards such as 461 802.11k, 802.11v and 802.11u. While 802.11k is well-defined, both 462 802.11v and 802.11u are at early stages of standards development. 464 3.1.7.2 Protocol Evaluation 466 The SLAPP protocol defines the capability element that is used by the 467 WTP to indicate its support for various 802.11 standards extensions. 468 For example, the 802.11e and WiFi Alliance defined interoperability 469 subsets of 802.11e such as WMM, WMM-SA and U-APSD are leveraged using 470 indications in the element (6.1.3.1.10). The future standards such 471 as 802.11k and 802.11v may be added to this element as and when they 472 are available and supported by the WTPs. 474 The IEEE 802.11e element (6.1.3.1.29) defines a mechanism for the AC 475 to configure these functions at the WTP, if they are supported. The 476 internal parameters of the 802.11e functions such as the window size, 477 back-off and AIFS are well defined in the standard (e.g., IEEE 478 802.11e, WMM and WMM-SA). An WTP claiming a specific 802.11e 479 capability is expected to implement the same as specified in the 480 standard or specification. 482 The transmit and receive frame statistics can also be specified per 483 Access Category, if the WTP is 802.11e capable. The WMM 484 specification also defines the mapping between 802.11e traffic 485 identifier/access category and DSCP or 802.1d tags. The AC and WTP 486 are expected to follow these standard mappings to enforce QoS over 487 the wired and wireless links. If overriding of these default or 488 standard behaviors is desired by CAPWAP working group, the existing 489 SLAPP configuration elements can be modified to support these 490 functions. 492 For 802.11k and other emerging IEEE 802.11 amendments such as 802.11v 493 and 802.11u, the raw 802.11 frame option (6.1.3.1.39) defined in 494 SLAPP can be used to forward any 802.11 frame such as a management 495 frame or action frame to the AC. This allows SLAPP to support future 496 802.11 extensions, without having to re-define existing elements. 497 However, the capability, configuration, statistics, status and event 498 elements can be easily extend future IEEE 802.11 amendments. 500 3.1.7.3 Compliance 502 SLAPP satisfies this requirement. 504 3.1.8 CAPWAP Protocol Security 506 Classification: Security 508 3.1.8.1 Protocol Requirement 510 "The CAPWAP protocol must support mutual authentication of WTPs and 511 the centralized controller. It must also ensure that information 512 exchanges between them are secured." 514 This requirement specifies a minimum support for security. The key 515 exchange and authentication protocol must support authentication of 516 the AC to the WTP and of the WTP to the AC. The resulting key(s) 517 must be used to secure messages sent between the two. Implied in 518 this requirement is that it is not possible for a third party to 519 forge SLAPP messages between the authenticated AC and WTP nor is it 520 possible to replay valid messages sent between the AC and WTP. 522 3.1.8.2 Protocol Evaluation 524 SLAPP uses DTLS for authentication, key management, and bulk data 525 protection. The DTLS protocol provides for mutual authentication as 526 well as asymmetric authentication. Keys are derived from the DTLS 527 exchange and are used to protect bulk data, in this case SLAPP 528 messages. DTLS provides data integrity protection, confidentiality, 529 and anti-replay protection to SLAPP messages. 531 DTLS is a connection-less (datagram) version of the TLS protocol 532 whose security has been reviewed by competent and professional 533 cryptographers and is believed to be secure. Using DTLS lessens the 534 need for the CAPWAP WG to go through additional reviews of the 535 security aspects of the protocol. 537 3.1.8.3 Compliance 539 SLAPP satisfies this requirement. 541 3.1.9 System-Wide Security 543 Classification: Security 545 3.1.9.1 Protocol Requirement 547 "The design of the CAPWAP protocol should not allow for any 548 compromises to the WLAN system by external entities." 550 This requirement generally states that the CAPWAP protocol should not 551 introduce any new points of attack for a network. 553 3.1.9.2 Protocol Evaluation 555 SLAPP uses DTLS to protect its communication. There are no known 556 ways to forge, alter, or replay SLAPP messages protected by DTLS. 557 The SLAPP protocol does not introduce any new vulnerabilities to a 558 system. 560 The Security Considerations of SLAPP note that state is created on 561 the AC upon receipt of Discovery Requests from a WTP. SLAPP 562 recommends a technique to prevent a denial of service attacks from 563 being launched because of this. Other techniques to foil such an 564 attack are possible but SLAPP does recommend one. 566 From a system-wide perspective though SLAPP is only as secure as the 567 system that speaks it. 569 This section of in CAPWAP Objectives memo mentions PMK sharing and 570 that rogue clients should not be able to take advantage of a shared 571 PMK (how that could happen is not mentioned). With SLAPP the PMK 572 resides on the authenticator. There is no defined message to allow 573 the PMK to be sent to any other entity. Therefore SLAPP does not 574 provide for a way to share a PMK. 576 3.1.9.3 Compliance 578 SLAPP satisfies this requirement. 580 3.1.10 802.11i Considerations 582 Classification: Security 584 3.1.10.1 Protocol Requirement 586 "The CAPWAP protocol must determine the exact structure of the 587 centralized WLAN architecture in which authentication needs to be 588 supported, i.e. the location of major authentication components." 590 This may be achieved during WTP initialization where major 591 capabilities are distinguished. 593 The protocol must allow for the exchange of key information when 594 authenticator and encryption roles are located in distinct entities. 596 This requirement highlights the fact that different architectures 597 were defined in the CAPWAP taxonomy memo and that major components of 598 a WLAN architecture can reside in different places. It is necessary 599 for SLAPP to allow an AC and WTP to identify their capabilities and 600 come to an agreement on where architectural components-- e.g. the 601 802.11i authenticator and 802.11i data encryption/decryption points-- 602 will reside once the WTP is controlled and provisioned by the AC. 604 3.1.10.2 Protocol Evaluation 606 As noted in section 6.1.1 of the SLAPP memo both local MAC and split 607 MAC architectures are supported. These are further refined in SLAPP 608 to allow for a bridged and tunneled version of the local MAC 609 architecture, and a distinction between L2 crypto being handled at 610 the WTP versus L2 crypto being handled at the AC for the split MAC 611 architecture. 613 During the registration phase of SLAPP the WTP and AC agree on what 614 architecture and what specific refinement of that architecture will 615 be provisioned. 617 SLAPP provides for tunneling encrypted 802.11 frames to the AC when 618 L2 crypto is performed at the AC. It also provides the ability to 619 tunnel decrypted 802.3 frames when L2 crypto is performed at the WTP. 620 When the 802.1x authenticator is located on the AC and L2 crypto is 621 performed by the WTP, it is necessary for the AC to send PTKs and 622 GTKs to the WTP. SLAPP includes a control message to do just that. 623 This message is, like all SLAPP control messages, protected by DTLS. 625 3.1.10.3 Compliance 627 SLAPP satisfies this requirement. 629 3.1.11 Interoperability Objective 631 Classification: General 633 3.1.11.1 Protocol Requirement 635 "The CAPWAP protocol must include sufficient capabilities 636 negotiations to distinguish between major types of WTPs." 638 3.1.11.2 Protocol Evaluation 640 SLAPP supports both the split-MAC and local-MAC architecture. The 641 protocol also defines a set of sub-modes for each of these 642 architectures and appropriate split of AP functions between the AC 643 and the WTP for each of these sub-modes. 645 Even though there are more possibilities for splitting functions 646 between an AC and a WTP, the authors used market data and their own 647 experience in large WLAN deployments to narrow down the choices to 5 648 major CAPWAP modes. 650 During the SLAPP registration phase, a WTP announces its support for 651 one or more of the CAPWAP modes defined in SLAPP. If the set of 652 modes supported by the AC overlaps with the set announced by the WTP, 653 then the AC selects a CAPWAP mode that the AC and the WTP will 654 operate in. If these two sets do not intersect, then the AC rejects 655 the registration request from the WTP. 657 3.1.11.3 Compliance 659 SLAPP satisfies this requirement. 661 3.1.12 Protocol Specifications 663 Classification : General 665 3.1.12.1 Protocol Requirement 667 "Any WTP or AC vendor or any person can implement the CAPWAP protocol 668 from the specification itself and by that it is required that all 669 such implementations do interoperate." 671 3.1.12.2 Protocol Evaluation 673 SLAPP does not require any a priori exchange of technical information 674 between AC and WTP vendors. SLAPP requires that the individual 675 vendors simply implement the protocol. Interoperability is achieved 676 as long as the set of CAPWAP modes implemented by a WTP overlaps with 677 the set supported by an AC. If the two sets do not overlap (i.e., a 678 WTP that only supports the split MAC modes attempts to register with 679 an AC that only supports the local MAC modes), then the AC will be 680 unable to configure and manage the WTP. 682 3.1.12.3 Compliance 684 SLAPP satisfies this requirement. 686 3.1.13 Vendor Independence 688 Classification: General 690 3.1.13.1 Protocol Requirement 692 "A WTP vendor can make modifications to hardware without any AC 693 vendor involvement." 695 The SLAPP authors feel that this requirement is already covered by 696 the requirement in Section 3.1.12 and is redundant. Any protocol 697 satisfies the "Vendor Independence" requirement if it satisfies the 698 "Protocol Specifications" requirement in Section 3.1.12. 700 3.1.13.2 Protocol Evaluation 702 Since SLAPP satisfies the requirement in Section 3.1.12, it also 703 satisfies the requirement in this section. 705 3.1.13.3 Compliance 707 SLAPP satisfies this requirement. 709 3.1.14 Vendor Flexibility 711 Classification: General 713 3.1.14.1 Protocol Requirement 715 "WTP Vendors must not be bound to a specific MAC." 717 This requirement is a bit ambiguous since the objectives draft [7] 718 states that the CAPWAP protocol should satisfy both local-MAC and 719 split-MAC architectures. First, this is already covered by the 720 requirement in Section 3.1.11. Second, if this is the motivation 721 behind this requirement then it is not clear if it is complete when 722 required only of the WTP. 724 3.1.14.2 Protocol Evaluation 726 SLAPP provides support for both local-MAC and split-MAC 727 architectures, including a short list of submodes for each of these 728 architectures. During the SLAPP registration phase, the WTP signals 729 its list of supported CAPWAP modes and the AC selects an operating 730 mode for the WTP assuming there is a common mode supported both by 731 the WTP and the AC. 733 3.1.14.3 Compliance 735 SLAPP satisfies this requirement. 737 3.2 Desirable Objectives 739 3.2.1 Multiple Authentication Mechanisms 741 Classification: Architecture 743 3.2.1.1 Protocol Requirement 745 "The CAPWAP protocol must support different authentication mechanisms 746 in addition to IEEE 802.11i." 748 This is a desired but not mandatory objective. This requirement 749 states that the CAPWAP protocol must be flexible in supporting not 750 only 802.11i but other existing techniques such as web 751 authentication. 753 3.2.1.2 Protocol Evaluation 755 SLAPP allows for but does not require 802.11i to be configured. It 756 does not constrain other authentication techniques from being 757 deployed. Typically this is done by using separate SSIDs to denote 758 the different techniques. SLAPP supports the configuration of 759 multiple SSIDs on a WTP. How a particular authentication is 760 performed-- MAC address lookup in a local database, directing a 761 client to a captive portal, etc-- is outside the scope of SLAPP. 763 3.2.1.3 Compliance 765 SLAPP satisfies this requirement. 767 3.2.2 Support for Future Technologies 769 Classification: Architecture 771 3.2.2.1 Protocol Requirement 773 "The CAPWAP protocol messages must be designed to be extensible for 774 specific layer 2 wireless technologies. It should not be limited to 775 the transport of elements relation to 802.11." 777 3.2.2.2 Protocol Evaluation 779 SLAPP strongly supports this by providing a common technology- 780 independent framework that can be used to negotiate a control 781 protocol which may contain a technology dependent component (See 782 Figure 1 of the SLAPP draft). Since it is not practical to define a 783 control protocol that can be used with any future wireless 784 technology, the SLAPP framework provides a mechanism to negotiate a 785 technology specific control protocol after initial discovery. 787 3.2.2.3 Compliance 789 SLAPP satisfies this requirement. 791 3.2.3 Support for New IEEE Requirements 793 Classification: Architecture 795 3.2.3.1 Protocol Requirement 797 "The CAPWAP protocol must be openly designed to support new IEEE 798 extensions." 800 3.2.3.2 Protocol Evaluation 802 The raw 802.11 frame support defined in SLAPP (See 6.1.3.1.39) allows 803 any 802.11 frame (e.g., management, action or control) to be 804 transported to the AC, irrespective of the MAC split (i.e., local MAC 805 vs. split MAC). The authors believe that this simple mechanism 806 allows SLAPP to support all the IEEE 802.11 standards currently under 807 development, though many frame formats are not yet known. 809 In the event of a significantly different IEEE 802.11 amendment that 810 requires fundamental changes to the configuration and management 811 model, an additional technology dependent protocol (Figure 1 in the 812 SLAPP draft) can be defined and negotiated between AC and WTP. 814 3.2.3.3 Compliance 816 SLAPP satisfies this requirement. 818 3.2.4 Interconnection Objective 820 Classification: Architecture 822 3.2.4.1 Protocol Requirement 824 "The CAPWAP protocol must not be constrained to specific underlying 825 transport mechanisms." 827 3.2.4.2 Protocol Evaluation 829 SLAPP has been designed to operate over IPv4. It is independent of 830 the underlying L2 interconnection technologies as long as IPv4 is at 831 L3. The authors of the SLAPP draft believe that SLAPP will work over 832 IPv6 too, but they intend to update the draft to include an analysis 833 of SLAPP over IPv6 in the next version. TLS has been known to work 834 over IPv6 and, hence, DTLS will too. 836 The authors of the SLAPP draft did not see a need to define 837 mechanisms in the protocol to transport SLAPP control messages and 838 tunneled data frames over a L2 link. 840 3.2.4.3 Compliance 842 SLAPP satisfies this requirement. 844 3.2.5 WTP Access Control 846 Classification: Operations 848 3.2.5.1 Protocol Requirement 850 "The CAPWAP protocol must be capable of exchanging information 851 required for access control of WTPs and wireless terminals." 853 3.2.5.2 Protocol Evaluation 855 The SLAPP protocol supports multiple WTP authentication models as 856 described in Section 3.2.1.2. The AC has full control over 857 restricting WTPs that are capable of a specific type(s) of 858 authorization based on the defined access control policies at the AC. 860 The access control functions for the wireless terminal consist of 861 multiple components. The cryptographic and associated authentication 862 requirements can be configured per-logical group, which can be used 863 to control access to specific logical groups. The ESSID announcement 864 policy, as defined in the SLAPP draft, can also be used to restrict 865 association of wireless terminals by controlling beacons and probe 866 responses. 868 In addition, when the selected CAPWAP mode requires tunneling of 869 802.3 or 802.11 frames to the AC, additional access control policies 870 may be enforced at the AC per-wireless terminal. 872 3.2.5.3 Compliance 874 SLAPP satisfies this requirement. 876 3.3 Rejected Objectives 878 3.3.1 Support for Non-CAPWAP WTPs 880 Classification: Architectures 882 3.3.1.1 Protocol Requirement 884 "The CAPWAP protocol should be capable of recognizing legacy WTPs and 885 existing network management systems." 887 3.3.1.2 Protocol Evaluation 889 SLAPP includes an image download option and a control and 890 provisioning protocol. Using the image download option it is 891 possible for an image, which supports legacy or proprietary network 892 management systems, to be downloaded to a WTP. The WTP would boot 893 that image and communicate in the legacy or proprietary protocol with 894 the AC. 896 SLAPP's image download protocol uniquely qualifies it for support of 897 this requirement. 899 3.3.1.3 Compliance 901 SLAPP satisfies this requirement. 903 3.4 Operator Requirements 905 3.4.1 AP Fast Handoff 907 Classification: Operators 909 3.4.1.1 Protocol Requirement 911 "The CAPWAP protocol operations must not impede or obstruct the 912 efficiency of AP fast handoff procedures." 913 There is nothing in CAPWAP that governs AP fast handoffs. It is 914 desirable that CAPWAP not preclude it from happening or impose any 915 constraints on solutions that provide it. 917 3.4.1.2 Protocol Evaluation 919 SLAPP is a secure discovery and control protocol. There is nothing 920 in SLAPP that would impede or obstruct fast handoffs between APs. 922 Architectures in which the 802.1x authenticator resides on a central 923 controller - e.g. split MAC architectures - may be more conducive to 924 AP fast handoffs because they can take advantage of the PMK caching 925 support currently in 802.11i. While other architectures - e.g. local 926 MAC - may not be able to take advantage of this, it is not due to 927 SLAPP, it is due to the location of the 802.1x authenticator and the 928 prohibition of sharing a PMK among 802.1x authenticators. 930 The 802.11r task group is currently working on fast handoff 931 techniques. SLAPP is congruent with the requirement of, 932 architectures in, and the terminology used by 802.11r. 934 3.4.1.3 Compliance 936 SLAPP satisfies this requirement. 938 3.5 Compliance table 940 Compliance Rating 941 Logical Groups S 942 Support for Traffic Separation S 943 Wireless Terminal Transparency S 944 Configuration Consistency S 945 Firmware Trigger P 946 Monitoring and Exchange of 947 System-wide Resource state S 948 Resource Control objective S 949 IEEE 802.11i Considerations S 950 Interoperability Objective S 951 Protocol Specifications S 952 Vendor independence S 953 Vendor Flexibility S 954 Multiple Authentication Mechanisms S 955 Support for Future Wireless 956 Technologies S 957 Support for new IEEE Requirements S 958 Interconnection Objective S 959 Access Control S 960 Support for Non-CAPWAP WTPs S 961 AP Fast Handoff S 963 4. Security Considerations 965 This document simply lists how SLAPP protocol conforms to the 966 requirements listed in the CAPWAP objectives document. The SLAPP 967 specification utilizes the DTLS protocol. 969 5. IANA considerations 971 This document requires no action by IANA. 973 6. Acknowledgments 975 The authors wish to acknowledge the comments and input received from 976 Merwyn Andrade. 978 7. References 980 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 981 Levels", March 1997, . 983 [2] "SLAPP : Simple Light Access Point Protocol", May 2005, . 987 [3] "Architecture Taxonomy for Control and Provisioning of Wireless 988 Access Points(CAPWAP)", August 2004, . 991 [4] "Configuration and Provisioning for Wireless Access Points 992 (CAPWAP) Problem Statement", February 2005, 993 . 995 [5] "Generic Routing Encapsulation", March 2000, 996 . 998 [6] "Requirements for Internet Hosts - Communication Layers", 999 October 1989, . 1001 [7] Govindan, S., "Objectives for Control and Provisioning of 1002 Wireless Access Points (CAPWAP)", November 2004, . 1006 [8] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1007 Security", April 2004, . 1010 [9] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 1011 RFC 2246, January 1999, 1012 . 1014 [10] Modadugu, N. and E. Rescorla, "The Design and Implementation of 1015 Datagram TLS", 1016 . 1018 [11] Cheswick, W. and S. Bellovin, "Firewalls and Internet 1019 Security". 1021 [12] Krishna, P. and D. Husak, "Simple Lightweight RFID Reader 1022 Protocol", March 2005, . 1025 Authors' Addresses 1027 Partha Narasimhan 1028 Aruba Networks 1029 1322 Crossman Ave 1030 Sunnyvale, CA 94089 1032 Phone: +1 408-480-4716 1033 Email: partha@arubanetworks.com 1035 Dan Harkins 1036 Trapeze Networks 1037 5753 W. Las Positas Blvd 1038 Pleasanton, CA 94588 1040 Phone: +1-925-474-2212 1041 Email: dharkins@trpz.com 1043 Subbu Ponnuswamy 1044 Aruba Networks 1045 1322 Crossman Ave 1046 Sunnyvale, CA 94089 1048 Phone: +1 408-754-1213 1049 Email: subbu@arubanetworks.com 1050 Susan Hares 1051 NextHop 1052 825 Victors Way 1053 Ann Arbor, MI 48108 1055 Phone: +1 734 222 1610 1056 Email: shares@nexthop.com 1058 Intellectual Property Statement 1060 The IETF takes no position regarding the validity or scope of any 1061 Intellectual Property Rights or other rights that might be claimed to 1062 pertain to the implementation or use of the technology described in 1063 this document or the extent to which any license under such rights 1064 might or might not be available; nor does it represent that it has 1065 made any independent effort to identify any such rights. Information 1066 on the procedures with respect to rights in RFC documents can be 1067 found in BCP 78 and BCP 79. 1069 Copies of IPR disclosures made to the IETF Secretariat and any 1070 assurances of licenses to be made available, or the result of an 1071 attempt made to obtain a general license or permission for the use of 1072 such proprietary rights by implementers or users of this 1073 specification can be obtained from the IETF on-line IPR repository at 1074 http://www.ietf.org/ipr. 1076 The IETF invites any interested party to bring to its attention any 1077 copyrights, patents or patent applications, or other proprietary 1078 rights that may cover technology that may be required to implement 1079 this standard. Please address the information to the IETF at 1080 ietf-ipr@ietf.org. 1082 Disclaimer of Validity 1084 This document and the information contained herein are provided on an 1085 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1086 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1087 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1088 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1089 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1090 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1092 Copyright Statement 1094 Copyright (C) The Internet Society (2005). This document is subject 1095 to the rights, licenses and restrictions contained in BCP 78, and 1096 except as set forth therein, the authors retain all their rights. 1098 Acknowledgment 1100 Funding for the RFC Editor function is currently provided by the 1101 Internet Society.