CAPWAP Working Group P. Narasimhan Internet-Draft Aruba Networks Expires: December 8, 2005 D. Harkins Trapeze Networks S. Ponnuswamy Aruba Networks S. Hares NextHop June 6, 2005 SLAPP Evaluation draft-narasimhan-capwap-slapp-evaluation-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 8, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract The CAPWAP Working Group (WG) is currently looking into defining a protocol that would enable interoperability in an IEEE 802.11 based wireless local area network (WLAN) comprised of Wireless Termination Narasimhan, et al. Expires December 8, 2005 [Page 1] Internet-Draft SLAPP Evaluation June 2005 Points (WTP) and Access Controllers (AC) belonging to different vendors. This document presents a self-review of Simple Light Access Point Protocol (SLAPP), one of the candidate protocol proposals submitted to the CAPWAP WG for consideration as a CAPWAP protocol. The WG has requested that the authors of all candidate proposals to provide a document which evaluates how their submission meets the objectives, taxonomy, and problem statement. Narasimhan, et al. Expires December 8, 2005 [Page 2] Internet-Draft SLAPP Evaluation June 2005 Table of Contents 1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1 Conventions used in this document . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1 SLAPP Highlights . . . . . . . . . . . . . . . . . . . . . 4 2.1.1 Extensible Architecture . . . . . . . . . . . . . . . 4 2.1.2 Reuse Existing Standards and Protocols . . . . . . . . 5 2.1.3 Simple Control Protocol for 802.11 . . . . . . . . . . 5 3. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1 Mandatory Objectives . . . . . . . . . . . . . . . . . . . 6 3.1.1 Logical Groups . . . . . . . . . . . . . . . . . . . . 6 3.1.2 Support for Traffic Separation . . . . . . . . . . . . 7 3.1.3 Wireless Terminal Transparency . . . . . . . . . . . . 7 3.1.4 Configuration Consistency . . . . . . . . . . . . . . 8 3.1.5 Firmware Trigger . . . . . . . . . . . . . . . . . . . 9 3.1.6 Monitoring and Exchange of System-Wide Resource State . . . . . . . . . . . . . . . . . . . . . . . . 10 3.1.7 Resource Control Objective . . . . . . . . . . . . . . 11 3.1.8 CAPWAP Protocol Security . . . . . . . . . . . . . . . 12 3.1.9 System-Wide Security . . . . . . . . . . . . . . . . . 13 3.1.10 802.11i Considerations . . . . . . . . . . . . . . . 14 3.1.11 Interoperability Objective . . . . . . . . . . . . . 15 3.1.12 Protocol Specifications . . . . . . . . . . . . . . 15 3.1.13 Vendor Independence . . . . . . . . . . . . . . . . 16 3.1.14 Vendor Flexibility . . . . . . . . . . . . . . . . . 16 3.2 Desirable Objectives . . . . . . . . . . . . . . . . . . . 17 3.2.1 Multiple Authentication Mechanisms . . . . . . . . . . 17 3.2.2 Support for Future Technologies . . . . . . . . . . . 17 3.2.3 Support for New IEEE Requirements . . . . . . . . . . 18 3.2.4 Interconnection Objective . . . . . . . . . . . . . . 19 3.2.5 WTP Access Control . . . . . . . . . . . . . . . . . . 19 3.3 Rejected Objectives . . . . . . . . . . . . . . . . . . . 20 3.3.1 Support for Non-CAPWAP WTPs . . . . . . . . . . . . . 20 3.4 Operator Requirements . . . . . . . . . . . . . . . . . . 20 3.4.1 AP Fast Handoff . . . . . . . . . . . . . . . . . . . 20 3.5 Compliance table . . . . . . . . . . . . . . . . . . . . . 21 4. Security Considerations . . . . . . . . . . . . . . . . . . 22 5. IANA considerations . . . . . . . . . . . . . . . . . . . . 22 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 22 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 23 Intellectual Property and Copyright Statements . . . . . . . 25 Narasimhan, et al. Expires December 8, 2005 [Page 3] Internet-Draft SLAPP Evaluation June 2005 1. Definitions 1.1 Conventions used in this document 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 [1]. 2. Introduction The IETF CAPWAP Working Group is working towards defining a protocol aimed at addressing the interoperability between IEEE 802.11 Wireless Termination Points (WTP) and Access Controllers (AC) belonging to different vendors as stated in the CAPWAP problem statement [4]. The CAPWAP architecture taxonomy document [3] documents the multiple architectural choices present in the industry based on inputs from WLAN vendors and others. The CAPWAP objectives draft [7] documents the list of requirements that a CAPWAP protocol must satisfy in order to enable multi-vendor interoperability between WTPs and ACs. The CAPWAP WG invited proposals for a candidate CAPWAP protocol and requested that the authors of each candidate proposal submit another draft evaluating their submission against the requirements in the CAPWAP objectives draft [7]. The SLAPP protocol draft [2] was submitted to the CAPWAP WG for consideration as a candidate proposal for a CAPWAP protocol. This document is a self-evaluation by the authors of the SLAPP draft of their submission. 2.1 SLAPP Highlights The highlights of the SLAPP protocol draft as presented below. 2.1.1 Extensible Architecture SLAPP provides a solution to the CAPWAP problem that is explicitly separated into two components - a technology-independent component to enable a WTP to discover and authenticate an AC, and to negotiate a technology-dependent control protocol during the discovery phase. This decoupling of the technology-dependent components from the technology-independent base provides us with extensibility to other technologies as they mature without having to explicitly build it in today. The interoperability issues within WLANs using IEEE 802.11 are reasonably well understood today. So the CAPWAP WG can focus on Narasimhan, et al. Expires December 8, 2005 [Page 4] Internet-Draft SLAPP Evaluation June 2005 solving these issues of today while not worrying about similar issues facing technologies that could mature in the future. The base SLAPP protocol is also useful for secure discovery and authentication for more generic applications, including non-wireless ones, that require a central controller to control and manage one or more network elements from a different vendor. For example, the base SLAPP protocol could be used for secure discovery and authentication in SLRRP [12]. 2.1.2 Reuse Existing Standards and Protocols The authors of the SLAPP draft strongly believe that a CAPWAP protocol should use existing methods, wherever such methods are readily available, without re-inventing the wheel on what are major components of a 802.11 control protocol. As a result of this, SLAPP inherits the benefits of public reviews and implementations of these existing methods over a period of time enhancing the robustness of the protocol and the reusability of existing implementations. For example, the security component of SLAPP uses DTLS [8], which is a connection-less (datagram) version of the TLS protocol [9] whose security has been reviewed by competent and professional cryptographers and is believed to be secure [11]. DTLS, as TLS, can operate over IPv4 or IPv6. The myriad of authentication options in DTLS allows for a wide array of options with which to secure the channel between the WTP and the AC -- mutual or certificate based, symmetric, asymmetric, or non-mutual, anonymous, etc. Using DTLS lessens the need for the CAPWAP WG to go through additional reviews of the security aspects of the protocol, thus speeding up the work of the WG. For the tunneling of frames between a WTP and an AC, SLAPP uses Generic Routing Encapsulation (GRE) [5] which has been extensively deployed. This removes the need to define a new tunneling mechanism for a CAPWAP protocol. Both TLS and GRE have been used extensively over the last decade or so. Given the tight schedule that the CAPWAP WG is operating under, sparing the group the additional chore of reviews on security and tunneling mechanisms is a highly desirable goal. The authors of the SLAPP draft believe that their submission achieves this goal. 2.1.3 Simple Control Protocol for 802.11 The SLAPP control protocol for 802.11 defines a simple state machine and a list of operating modes that have been chosen based on the architectural choices prevalent in the market place today. The Narasimhan, et al. Expires December 8, 2005 [Page 5] Internet-Draft SLAPP Evaluation June 2005 control protocol closely aligns itself with the specifications present in the IEEE 802.11 standard while avoiding extraneous operating modes not currently defined by 802.11. The SLAPP proposal reflects the collective experience of the authors in deploying large WLANs covering all the architectural variants described in the submission. 3. Objectives SLAPP is a simple light-weight protocol that supports communication between Wireless Termination Points and Access Controllers. The communication between the Wireless Termination points and the Access Controllers occurs over a DTLS connection. 3.1 Mandatory Objectives This section contains all of the objectives that have been considered as being mandatory in order for a protocol to be consider. 3.1.1 Logical Groups Classification: Architecture 3.1.1.1 Protocol Requirement "WLAN deployment trends require CAPWAP protocol to be capable of controlling and managing physical WTPS in terms of logical groups." This is being interpreted as stating that a protocol must allow for the WTP to provide service for multiple SSIDs (or WLANs), each with a distinct BSSID. 3.1.1.2 Protocol Evaluation In SLAPP, the WTPs may support one or more BSSIDS. The WTPs indicate the number of BSSIDs supported to the AC using a specific message (Section 6.1.3.1.12). This in turn defines the number of logical groups supported by that specific WTP. The AC may choose to configure any number of logical groups per WTP, subject to the maximum number indicated by the WTPs. The BSSID index element defined in SLAPP (Section 6.1.3.1.13) is used to configure all BSSID- specific parameters. The WTPs may use the same element to convey BSSID-specific status to the AC. The SLAPP protocol allows the AC to create a logical group by defining a WLAN with a specific BSSID, ESSID and associated parameters. Each logical group can have a separate set of security Narasimhan, et al. Expires December 8, 2005 [Page 6] Internet-Draft SLAPP Evaluation June 2005 policies, QoS policies and any other policies that can be defined using the configuration parameters specified in Section 6.1.3.2.6 of the SLAPP draft. The data between AC and WTP or between an 802.11 STA and WTP can also be identified per logical group, based on the BSSID and associated identifiers. 3.1.1.3 Compliance SLAPP satisfies this requirement. 3.1.2 Support for Traffic Separation Classification: Operations 3.1.2.1 Protocol Requirement "In order to maintain the separation of control and data traffic, the CAPWAP protocol is required to define control messages such that they do not involve piggybacking or other combination with data traffic." This requirement specifies that a strict separation between control and data traffic must be established and maintained and that it is not possible to mix the two or somehow carry traffic for one in the other. 3.1.2.2 Protocol Evaluation SLAPP has an 802.11 Control Protocol as an option decided upon during WTP and AC discovery. This protocol has two components, one for sending control and provisioning messages between the WTP and AC, and another for tunneling data traffic between the WTP and AC. Control traffic has its own SLAPP Control Protocol header and is sent as UDP traffic to the AC. Data traffic is tunneled via GRE. Control and data are uniquely identified and separation between the two is maintained by SLAPP. It is not possible to send a data frame as a Control message and vice versa. 3.1.2.3 Compliance SLAPP satisfies this requirement. 3.1.3 Wireless Terminal Transparency Classification: Operations Narasimhan, et al. Expires December 8, 2005 [Page 7] Internet-Draft SLAPP Evaluation June 2005 3.1.3.1 Protocol Requirement "Wireless Terminals should not be required to recognize or be aware of the CAPWAP protocol." The use of SLAPP between the WTPs and ACs should be transparent to the 802.11 stations. 3.1.3.2 Protocol Evaluation SLAPP is a protocol defined between ACs and WTPs that enable an AC to configure and manage one or more WTPs. SLAPP messages are addressed between ACs and WTPs. They do not extend to the 802.11 wireless link and hence are transparent to the 802.11 stations. Once a BSS is configured by an AC on a WTP, the 802.11 stations do not see a difference between an WTP managed using SLAPP (using any of the CAPWAP modes defined in Section 6.1.3 of the SLAPP draft) and an autonomous WTP (as defined in the CAPWAP architecture taxonomy document [3]). 3.1.3.3 Compliance SLAPP satisfies this requirement. 3.1.4 Configuration Consistency Classification: Operations 3.1.4.1 Protocol Requirement "The CAPWAP protocol must allow for regular exchange of state information between WTPs and WLAN controller. Examples of State information include WTP processing load and memory utilization." Our interpretation of this requirement is that the CAPWAP protocol must support a mechanism to transport WTP capability information so that an AC can make consistent configuration decisions for the WTPs under its control. In addition, we interpret that the WTP must be capable of sending periodic status information to the AC so that the AC can perform dynamic and run-time re-configuration to optimize the overall WLAN performance. We also enhanced this understanding to allow different configurations based on the type of sub-protocol. 3.1.4.2 Protocol Evaluation SLAPP requires that the WTPs communicate their capabilities during Narasimhan, et al. Expires December 8, 2005 [Page 8] Internet-Draft SLAPP Evaluation June 2005 the initialization process. The capability of a WTP may be limited by the regulatory domain as well as by the WTP hardware and software. The capability exchange mechanism allows AC to have a consistent picture of the capabilities of the WTPs. After the capability exchange, the AC is responsible for sending configuration information to the WTPs. Some configuration parameters have default values and need not be explicitly configured. The defaults can be overridden by the AC with an explicit configuration message. SLAPP also defines a set of mandatory configuration parameters that MUST be explicitly configured by an AC for the WLAN to be operational. This ensures consistency across WTPs, where certain parameters have to be configured and optimized globally (across WTPs). The event mechanism defined in SLAPP (6.1.3.1.27) allows the AC to configure events at the WTP with different importance levels. Specific events such as radar detection and excessive retry and a generic 802.11 management and action event are currently defined in SLAPP. Additional events can be easily added. The event mechanism provides the AC with instantaneous report of specific events so that the AC can make corrective actions if necessary. The WTP statistics and status may be obtained by an AC at any time by sending a request to the WTP. If desired, the AC may periodically send statistics or status requests such as those related to load (e.g., transmit, receive and association statistics) and instantaneous status such as Noise Floor. The AC may also configure the WTP to generate an event for Noise Floor, when the Noise Floor exceeds a specific value. The capability, configuration, statistics, status and event mechanisms defined in SLAPP are fully extensible and additional elements can be easily added, if desired, as the IEEE standards evolve. 3.1.4.3 Compliance SLAPP satisfies this requirement. 3.1.5 Firmware Trigger Classification: Operations Protocol Evaluation: The CAPWAP protocol must support a trigger for delivery of firmware updates. Narasimhan, et al. Expires December 8, 2005 [Page 9] Internet-Draft SLAPP Evaluation June 2005 3.1.5.1 Protocol Evaluation SLAPP has an firmware download mechanism defined in the form of an Image Download protocol. The image download process uses the security context negotiated between an AC and a WTP using DTLS. Other mechanisms such as TFTP would be outside the context of the DTLS session and hence would not be secure for downloading firmware to the WTPs. During SLAPP discovery phase, a WTP identifies its hardware and current software version numbers. If the AC determines that a new image is available for this WTP, then it selects the Image Download protocol so that the new version of the firmware can be transferred to the WTP. The authors of the SLAPP draft recognize that a simpler trigger is possible to include in the 802.11 control protocol state machine to initiate the image download protocol. This will be added in the next version of the SLAPP draft to fully satisfy the requirement. 3.1.5.2 Compliance SLAPP partially satisfies this requirement 3.1.6 Monitoring and Exchange of System-Wide Resource State Classification: Operations 3.1.6.1 Protocol Requirement "The CAPWAP protocol must allow for the exchange of statistics, congestion and other WLAN state information." Our interpretation of this requirement includes statistics for any type of media define: 802.11, 802.15, or 802.16. 3.1.6.2 Protocol Evaluation The SLAPP protocol defines a set of capability, configuration, statistics, status and event elements that can be used to monitor and exchange the system-wide resource state. SLAPP supports an extensive set of statistics (6.1.3.1.30, 6.1.3.1.31, 6.1.3.1.32, and 6.1.3.1.33) that can be used by the AC to request specific class of statistics. In addition to the aggregate statistics, the status (6.1.3.1.34) element defined in SLAPP can be used to obtain the instantaneous status. The event mechanism (See 6.1.3.1.35-39) defined in SLAPP allows the Narasimhan, et al. Expires December 8, 2005 [Page 10] Internet-Draft SLAPP Evaluation June 2005 AC to configure specific events at the WTP for notification. The AC may choose to re-configure or re-adjust system-wide parameters based on statistics, status or events received from a WTP, using one of the configuration elements. Additional capability, configuration, statistics, status or event elements can be easily added to the SLAPP protocol, if required. 3.1.6.3 Compliance SLAPP satisfies this requirement. 3.1.7 Resource Control Objective Classification: Operations 3.1.7.1 Protocol Requirement "The CAPWAP protocol must maintain IEEE 802.11e mappings across the switching and the wireless segment." 802.11e is one of the first wireless standards to support QoS. While 802.16 supports QoS over wireless, we also anticipate other emerging standards such as 802.15x and 802.20 to have specific QoS requirements. We interpret this objective as allowing all sub- protocols to handle QoS information. In addition, this objective requires the protocol to support emerging 802.11x standards such as 802.11k, 802.11v and 802.11u. While 802.11k is well-defined, both 802.11v and 802.11u are at early stages of standards development. 3.1.7.2 Protocol Evaluation The SLAPP protocol defines the capability element that is used by the WTP to indicate its support for various 802.11 standards extensions. For example, the 802.11e and WiFi Alliance defined interoperability subsets of 802.11e such as WMM, WMM-SA and U-APSD are leveraged using indications in the element (6.1.3.1.10). The future standards such as 802.11k and 802.11v may be added to this element as and when they are available and supported by the WTPs. The IEEE 802.11e element (6.1.3.1.29) defines a mechanism for the AC to configure these functions at the WTP, if they are supported. The internal parameters of the 802.11e functions such as the window size, back-off and AIFS are well defined in the standard (e.g., IEEE 802.11e, WMM and WMM-SA). An WTP claiming a specific 802.11e capability is expected to implement the same as specified in the standard or specification. The transmit and receive frame statistics can also be specified per Narasimhan, et al. Expires December 8, 2005 [Page 11] Internet-Draft SLAPP Evaluation June 2005 Access Category, if the WTP is 802.11e capable. The WMM specification also defines the mapping between 802.11e traffic identifier/access category and DSCP or 802.1d tags. The AC and WTP are expected to follow these standard mappings to enforce QoS over the wired and wireless links. If overriding of these default or standard behaviors is desired by CAPWAP working group, the existing SLAPP configuration elements can be modified to support these functions. For 802.11k and other emerging IEEE 802.11 amendments such as 802.11v and 802.11u, the raw 802.11 frame option (6.1.3.1.39) defined in SLAPP can be used to forward any 802.11 frame such as a management frame or action frame to the AC. This allows SLAPP to support future 802.11 extensions, without having to re-define existing elements. However, the capability, configuration, statistics, status and event elements can be easily extend future IEEE 802.11 amendments. 3.1.7.3 Compliance SLAPP satisfies this requirement. 3.1.8 CAPWAP Protocol Security Classification: Security 3.1.8.1 Protocol Requirement "The CAPWAP protocol must support mutual authentication of WTPs and the centralized controller. It must also ensure that information exchanges between them are secured." This requirement specifies a minimum support for security. The key exchange and authentication protocol must support authentication of the AC to the WTP and of the WTP to the AC. The resulting key(s) must be used to secure messages sent between the two. Implied in this requirement is that it is not possible for a third party to forge SLAPP messages between the authenticated AC and WTP nor is it possible to replay valid messages sent between the AC and WTP. 3.1.8.2 Protocol Evaluation SLAPP uses DTLS for authentication, key management, and bulk data protection. The DTLS protocol provides for mutual authentication as well as asymmetric authentication. Keys are derived from the DTLS exchange and are used to protect bulk data, in this case SLAPP messages. DTLS provides data integrity protection, confidentiality, and anti-replay protection to SLAPP messages. Narasimhan, et al. Expires December 8, 2005 [Page 12] Internet-Draft SLAPP Evaluation June 2005 DTLS is a connection-less (datagram) version of the TLS protocol whose security has been reviewed by competent and professional cryptographers and is believed to be secure. Using DTLS lessens the need for the CAPWAP WG to go through additional reviews of the security aspects of the protocol. 3.1.8.3 Compliance SLAPP satisfies this requirement. 3.1.9 System-Wide Security Classification: Security 3.1.9.1 Protocol Requirement "The design of the CAPWAP protocol should not allow for any compromises to the WLAN system by external entities." This requirement generally states that the CAPWAP protocol should not introduce any new points of attack for a network. 3.1.9.2 Protocol Evaluation SLAPP uses DTLS to protect its communication. There are no known ways to forge, alter, or replay SLAPP messages protected by DTLS. The SLAPP protocol does not introduce any new vulnerabilities to a system. The Security Considerations of SLAPP note that state is created on the AC upon receipt of Discovery Requests from a WTP. SLAPP recommends a technique to prevent a denial of service attacks from being launched because of this. Other techniques to foil such an attack are possible but SLAPP does recommend one. From a system-wide perspective though SLAPP is only as secure as the system that speaks it. This section of in CAPWAP Objectives memo mentions PMK sharing and that rogue clients should not be able to take advantage of a shared PMK (how that could happen is not mentioned). With SLAPP the PMK resides on the authenticator. There is no defined message to allow the PMK to be sent to any other entity. Therefore SLAPP does not provide for a way to share a PMK. 3.1.9.3 Compliance SLAPP satisfies this requirement. Narasimhan, et al. Expires December 8, 2005 [Page 13] Internet-Draft SLAPP Evaluation June 2005 3.1.10 802.11i Considerations Classification: Security 3.1.10.1 Protocol Requirement "The CAPWAP protocol must determine the exact structure of the centralized WLAN architecture in which authentication needs to be supported, i.e. the location of major authentication components." This may be achieved during WTP initialization where major capabilities are distinguished. The protocol must allow for the exchange of key information when authenticator and encryption roles are located in distinct entities. This requirement highlights the fact that different architectures were defined in the CAPWAP taxonomy memo and that major components of a WLAN architecture can reside in different places. It is necessary for SLAPP to allow an AC and WTP to identify their capabilities and come to an agreement on where architectural components-- e.g. the 802.11i authenticator and 802.11i data encryption/decryption points-- will reside once the WTP is controlled and provisioned by the AC. 3.1.10.2 Protocol Evaluation As noted in section 6.1.1 of the SLAPP memo both local MAC and split MAC architectures are supported. These are further refined in SLAPP to allow for a bridged and tunneled version of the local MAC architecture, and a distinction between L2 crypto being handled at the WTP versus L2 crypto being handled at the AC for the split MAC architecture. During the registration phase of SLAPP the WTP and AC agree on what architecture and what specific refinement of that architecture will be provisioned. SLAPP provides for tunneling encrypted 802.11 frames to the AC when L2 crypto is performed at the AC. It also provides the ability to tunnel decrypted 802.3 frames when L2 crypto is performed at the WTP. When the 802.1x authenticator is located on the AC and L2 crypto is performed by the WTP, it is necessary for the AC to send PTKs and GTKs to the WTP. SLAPP includes a control message to do just that. This message is, like all SLAPP control messages, protected by DTLS. 3.1.10.3 Compliance SLAPP satisfies this requirement. Narasimhan, et al. Expires December 8, 2005 [Page 14] Internet-Draft SLAPP Evaluation June 2005 3.1.11 Interoperability Objective Classification: General 3.1.11.1 Protocol Requirement "The CAPWAP protocol must include sufficient capabilities negotiations to distinguish between major types of WTPs." 3.1.11.2 Protocol Evaluation SLAPP supports both the split-MAC and local-MAC architecture. The protocol also defines a set of sub-modes for each of these architectures and appropriate split of AP functions between the AC and the WTP for each of these sub-modes. Even though there are more possibilities for splitting functions between an AC and a WTP, the authors used market data and their own experience in large WLAN deployments to narrow down the choices to 5 major CAPWAP modes. During the SLAPP registration phase, a WTP announces its support for one or more of the CAPWAP modes defined in SLAPP. If the set of modes supported by the AC overlaps with the set announced by the WTP, then the AC selects a CAPWAP mode that the AC and the WTP will operate in. If these two sets do not intersect, then the AC rejects the registration request from the WTP. 3.1.11.3 Compliance SLAPP satisfies this requirement. 3.1.12 Protocol Specifications Classification : General 3.1.12.1 Protocol Requirement "Any WTP or AC vendor or any person can implement the CAPWAP protocol from the specification itself and by that it is required that all such implementations do interoperate." 3.1.12.2 Protocol Evaluation SLAPP does not require any a priori exchange of technical information between AC and WTP vendors. SLAPP requires that the individual vendors simply implement the protocol. Interoperability is achieved as long as the set of CAPWAP modes implemented by a WTP overlaps with Narasimhan, et al. Expires December 8, 2005 [Page 15] Internet-Draft SLAPP Evaluation June 2005 the set supported by an AC. If the two sets do not overlap (i.e., a WTP that only supports the split MAC modes attempts to register with an AC that only supports the local MAC modes), then the AC will be unable to configure and manage the WTP. 3.1.12.3 Compliance SLAPP satisfies this requirement. 3.1.13 Vendor Independence Classification: General 3.1.13.1 Protocol Requirement "A WTP vendor can make modifications to hardware without any AC vendor involvement." The SLAPP authors feel that this requirement is already covered by the requirement in Section 3.1.12 and is redundant. Any protocol satisfies the "Vendor Independence" requirement if it satisfies the "Protocol Specifications" requirement in Section 3.1.12. 3.1.13.2 Protocol Evaluation Since SLAPP satisfies the requirement in Section 3.1.12, it also satisfies the requirement in this section. 3.1.13.3 Compliance SLAPP satisfies this requirement. 3.1.14 Vendor Flexibility Classification: General 3.1.14.1 Protocol Requirement "WTP Vendors must not be bound to a specific MAC." This requirement is a bit ambiguous since the objectives draft [7] states that the CAPWAP protocol should satisfy both local-MAC and split-MAC architectures. First, this is already covered by the requirement in Section 3.1.11. Second, if this is the motivation behind this requirement then it is not clear if it is complete when required only of the WTP. Narasimhan, et al. Expires December 8, 2005 [Page 16] Internet-Draft SLAPP Evaluation June 2005 3.1.14.2 Protocol Evaluation SLAPP provides support for both local-MAC and split-MAC architectures, including a short list of submodes for each of these architectures. During the SLAPP registration phase, the WTP signals its list of supported CAPWAP modes and the AC selects an operating mode for the WTP assuming there is a common mode supported both by the WTP and the AC. 3.1.14.3 Compliance SLAPP satisfies this requirement. 3.2 Desirable Objectives 3.2.1 Multiple Authentication Mechanisms Classification: Architecture 3.2.1.1 Protocol Requirement "The CAPWAP protocol must support different authentication mechanisms in addition to IEEE 802.11i." This is a desired but not mandatory objective. This requirement states that the CAPWAP protocol must be flexible in supporting not only 802.11i but other existing techniques such as web authentication. 3.2.1.2 Protocol Evaluation SLAPP allows for but does not require 802.11i to be configured. It does not constrain other authentication techniques from being deployed. Typically this is done by using separate SSIDs to denote the different techniques. SLAPP supports the configuration of multiple SSIDs on a WTP. How a particular authentication is performed-- MAC address lookup in a local database, directing a client to a captive portal, etc-- is outside the scope of SLAPP. 3.2.1.3 Compliance SLAPP satisfies this requirement. 3.2.2 Support for Future Technologies Classification: Architecture Narasimhan, et al. Expires December 8, 2005 [Page 17] Internet-Draft SLAPP Evaluation June 2005 3.2.2.1 Protocol Requirement "The CAPWAP protocol messages must be designed to be extensible for specific layer 2 wireless technologies. It should not be limited to the transport of elements relation to 802.11." 3.2.2.2 Protocol Evaluation SLAPP strongly supports this by providing a common technology- independent framework that can be used to negotiate a control protocol which may contain a technology dependent component (See Figure 1 of the SLAPP draft). Since it is not practical to define a control protocol that can be used with any future wireless technology, the SLAPP framework provides a mechanism to negotiate a technology specific control protocol after initial discovery. 3.2.2.3 Compliance SLAPP satisfies this requirement. 3.2.3 Support for New IEEE Requirements Classification: Architecture 3.2.3.1 Protocol Requirement "The CAPWAP protocol must be openly designed to support new IEEE extensions." 3.2.3.2 Protocol Evaluation The raw 802.11 frame support defined in SLAPP (See 6.1.3.1.39) allows any 802.11 frame (e.g., management, action or control) to be transported to the AC, irrespective of the MAC split (i.e., local MAC vs. split MAC). The authors believe that this simple mechanism allows SLAPP to support all the IEEE 802.11 standards currently under development, though many frame formats are not yet known. In the event of a significantly different IEEE 802.11 amendment that requires fundamental changes to the configuration and management model, an additional technology dependent protocol (Figure 1 in the SLAPP draft) can be defined and negotiated between AC and WTP. 3.2.3.3 Compliance SLAPP satisfies this requirement. Narasimhan, et al. Expires December 8, 2005 [Page 18] Internet-Draft SLAPP Evaluation June 2005 3.2.4 Interconnection Objective Classification: Architecture 3.2.4.1 Protocol Requirement "The CAPWAP protocol must not be constrained to specific underlying transport mechanisms." 3.2.4.2 Protocol Evaluation SLAPP has been designed to operate over IPv4. It is independent of the underlying L2 interconnection technologies as long as IPv4 is at L3. The authors of the SLAPP draft believe that SLAPP will work over IPv6 too, but they intend to update the draft to include an analysis of SLAPP over IPv6 in the next version. TLS has been known to work over IPv6 and, hence, DTLS will too. The authors of the SLAPP draft did not see a need to define mechanisms in the protocol to transport SLAPP control messages and tunneled data frames over a L2 link. 3.2.4.3 Compliance SLAPP satisfies this requirement. 3.2.5 WTP Access Control Classification: Operations 3.2.5.1 Protocol Requirement "The CAPWAP protocol must be capable of exchanging information required for access control of WTPs and wireless terminals." 3.2.5.2 Protocol Evaluation The SLAPP protocol supports multiple WTP authentication models as described in Section 3.2.1.2. The AC has full control over restricting WTPs that are capable of a specific type(s) of authorization based on the defined access control policies at the AC. The access control functions for the wireless terminal consist of multiple components. The cryptographic and associated authentication requirements can be configured per-logical group, which can be used to control access to specific logical groups. The ESSID announcement policy, as defined in the SLAPP draft, can also be used to restrict association of wireless terminals by controlling beacons and probe Narasimhan, et al. Expires December 8, 2005 [Page 19] Internet-Draft SLAPP Evaluation June 2005 responses. In addition, when the selected CAPWAP mode requires tunneling of 802.3 or 802.11 frames to the AC, additional access control policies may be enforced at the AC per-wireless terminal. 3.2.5.3 Compliance SLAPP satisfies this requirement. 3.3 Rejected Objectives 3.3.1 Support for Non-CAPWAP WTPs Classification: Architectures 3.3.1.1 Protocol Requirement "The CAPWAP protocol should be capable of recognizing legacy WTPs and existing network management systems." 3.3.1.2 Protocol Evaluation SLAPP includes an image download option and a control and provisioning protocol. Using the image download option it is possible for an image, which supports legacy or proprietary network management systems, to be downloaded to a WTP. The WTP would boot that image and communicate in the legacy or proprietary protocol with the AC. SLAPP's image download protocol uniquely qualifies it for support of this requirement. 3.3.1.3 Compliance SLAPP satisfies this requirement. 3.4 Operator Requirements 3.4.1 AP Fast Handoff Classification: Operators 3.4.1.1 Protocol Requirement "The CAPWAP protocol operations must not impede or obstruct the efficiency of AP fast handoff procedures." Narasimhan, et al. Expires December 8, 2005 [Page 20] Internet-Draft SLAPP Evaluation June 2005 There is nothing in CAPWAP that governs AP fast handoffs. It is desirable that CAPWAP not preclude it from happening or impose any constraints on solutions that provide it. 3.4.1.2 Protocol Evaluation SLAPP is a secure discovery and control protocol. There is nothing in SLAPP that would impede or obstruct fast handoffs between APs. Architectures in which the 802.1x authenticator resides on a central controller - e.g. split MAC architectures - may be more conducive to AP fast handoffs because they can take advantage of the PMK caching support currently in 802.11i. While other architectures - e.g. local MAC - may not be able to take advantage of this, it is not due to SLAPP, it is due to the location of the 802.1x authenticator and the prohibition of sharing a PMK among 802.1x authenticators. The 802.11r task group is currently working on fast handoff techniques. SLAPP is congruent with the requirement of, architectures in, and the terminology used by 802.11r. 3.4.1.3 Compliance SLAPP satisfies this requirement. 3.5 Compliance table Compliance Rating Logical Groups S Support for Traffic Separation S Wireless Terminal Transparency S Configuration Consistency S Firmware Trigger P Monitoring and Exchange of System-wide Resource state S Resource Control objective S IEEE 802.11i Considerations S Interoperability Objective S Protocol Specifications S Vendor independence S Vendor Flexibility S Multiple Authentication Mechanisms S Support for Future Wireless Technologies S Support for new IEEE Requirements S Interconnection Objective S Narasimhan, et al. Expires December 8, 2005 [Page 21] Internet-Draft SLAPP Evaluation June 2005 Access Control S Support for Non-CAPWAP WTPs S AP Fast Handoff S 4. Security Considerations This document simply lists how SLAPP protocol conforms to the requirements listed in the CAPWAP objectives document. The SLAPP specification utilizes the DTLS protocol. 5. IANA considerations This document requires no action by IANA. 6. Acknowledgments The authors wish to acknowledge the comments and input received from Merwyn Andrade. 7. References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", March 1997, . [2] "SLAPP : Simple Light Access Point Protocol", May 2005, . [3] "Architecture Taxonomy for Control and Provisioning of Wireless Access Points(CAPWAP)", August 2004, . [4] "Configuration and Provisioning for Wireless Access Points (CAPWAP) Problem Statement", February 2005, . [5] "Generic Routing Encapsulation", March 2000, . [6] "Requirements for Internet Hosts - Communication Layers", October 1989, . [7] Govindan, S., "Objectives for Control and Provisioning of Wireless Access Points (CAPWAP)", November 2004, . [8] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Narasimhan, et al. Expires December 8, 2005 [Page 22] Internet-Draft SLAPP Evaluation June 2005 Security", April 2004, . [9] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999, . [10] Modadugu, N. and E. Rescorla, "The Design and Implementation of Datagram TLS", . [11] Cheswick, W. and S. Bellovin, "Firewalls and Internet Security". [12] Krishna, P. and D. Husak, "Simple Lightweight RFID Reader Protocol", March 2005, . Authors' Addresses Partha Narasimhan Aruba Networks 1322 Crossman Ave Sunnyvale, CA 94089 Phone: +1 408-480-4716 Email: partha@arubanetworks.com Dan Harkins Trapeze Networks 5753 W. Las Positas Blvd Pleasanton, CA 94588 Phone: +1-925-474-2212 Email: dharkins@trpz.com Subbu Ponnuswamy Aruba Networks 1322 Crossman Ave Sunnyvale, CA 94089 Phone: +1 408-754-1213 Email: subbu@arubanetworks.com Narasimhan, et al. Expires December 8, 2005 [Page 23] Internet-Draft SLAPP Evaluation June 2005 Susan Hares NextHop 825 Victors Way Ann Arbor, MI 48108 Phone: +1 734 222 1610 Email: shares@nexthop.com Narasimhan, et al. Expires December 8, 2005 [Page 24] Internet-Draft SLAPP Evaluation June 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Narasimhan, et al. Expires December 8, 2005 [Page 25]