Network Working Group P. Calhoun Internet-Draft B. O'Hara Expires: December 2, 2005 Cisco Systems, Inc. M. Williams Nokia, Inc. S. Hares Nexthop Technologies, Inc. May 31, 2005 LWAPP Self Evaluation draft-calhoun-capwap-lwapp-objectives-comparison-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 2, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract The IETF's CAPWAP working group has requested that all candidate protocols submitted must provide a document which evaluates how each Calhoun, et al. Expires December 2, 2005 [Page 1] Internet-Draft LWAPP Self Evaluation May 2005 protocol meets the objectives. This document describes in detail how the LWAPP protocol meets the CAPWAP objectives. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Conventions used in this document . . . . . . . . . . . . 3 2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1 Mandatory Objectives . . . . . . . . . . . . . . . . . . . 4 2.1.1 Logical Groups . . . . . . . . . . . . . . . . . . . . 4 2.1.2 Support for Traffic Separation . . . . . . . . . . . . 5 2.1.3 Wireless Terminal Transparency . . . . . . . . . . . . 5 2.1.4 Configuration Consistency . . . . . . . . . . . . . . 6 2.1.5 Firmware Trigger . . . . . . . . . . . . . . . . . . . 8 2.1.6 Monitoring and Exchange of System-wide Resource State . . . . . . . . . . . . . . . . . . . . . . . . 9 2.1.7 Resource Control Objective . . . . . . . . . . . . . . 9 2.1.8 CAPWAP Protocol Security . . . . . . . . . . . . . . . 11 2.1.9 System-wide Security . . . . . . . . . . . . . . . . . 13 2.1.10 IEEE 802.11i Considerations . . . . . . . . . . . . 14 2.1.11 Interoperability Objective . . . . . . . . . . . . . 15 2.1.12 Protocol Specifications . . . . . . . . . . . . . . 16 2.1.13 Vendor Independence . . . . . . . . . . . . . . . . 16 2.1.14 Vendor Flexibility . . . . . . . . . . . . . . . . . 16 2.2 Desirable Objectives . . . . . . . . . . . . . . . . . . . 17 2.2.1 Multiple Authentication Mechanisms . . . . . . . . . . 17 2.2.2 Support for Future Wireless Technologies . . . . . . . 17 2.2.3 Support for New IEEE Requirements . . . . . . . . . . 18 2.2.4 Interconnection Objective . . . . . . . . . . . . . . 19 2.2.5 Access Control . . . . . . . . . . . . . . . . . . . . 20 2.3 Rejected Objectives . . . . . . . . . . . . . . . . . . . 20 2.3.1 Support for Non-CAPWAP WTPs . . . . . . . . . . . . . 20 2.3.2 Technical Specifications . . . . . . . . . . . . . . . 20 2.4 Operator Requirements . . . . . . . . . . . . . . . . . . 21 2.4.1 AP Fast Handoff . . . . . . . . . . . . . . . . . . . 21 3. Compliance Table . . . . . . . . . . . . . . . . . . . . . . 22 4. Security Considerations . . . . . . . . . . . . . . . . . . 23 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 24 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 7. IPR Statement . . . . . . . . . . . . . . . . . . . . . . . 26 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 8.1 Normative References . . . . . . . . . . . . . . . . . . . 27 8.2 Informational References . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 28 Intellectual Property and Copyright Statements . . . . . . . 29 Calhoun, et al. Expires December 2, 2005 [Page 2] Internet-Draft LWAPP Self Evaluation May 2005 1. Introduction The CAPWAP working group has identified a set of objectives [2] that must be met for a protocol to be considered for standardization. The LWAPP protocol has been submitted to CAPWAP for consideration. The authors of the LWAPP specification [4] feel that the working group should consider two important facts about LWAPP. The protocol has been available as a personal contribution for well over 18 months, during which time many comments have been received and accepted. As a consequence, the authors believe that although the LWAPP specification is not complete, we believe that using it as a starting point by the Working Group would allow for much faster progress. Second, products that support the LWAPP protocol have been available for nearly 24 months, and therefore has significant operational experience in very large networks. The authors of the LWAPP specification feel that providing a strong security solution to the CAPWAP list is of the utmost importance, and as a consequence recently requested a third party security review [7]. The result of the security review was that the pre-shared key mode was cryptographically secure. However, although the review did find that the certificate based approach was practically secure, it did provide a couple of recommendations in order to also make it cryptographic secure. It is important to note that the review did clearly state that the vulnerabilities found would not compromise the data, but only opened the possiblity for DoS attacks on the cryptographic algorithms themselves. The authors of the LWAPP specification are in the process of making the recommended changes to the draft. There are a couple of areas in this evaluation draft where these changes are most relevant. In these sections we have specifically stated where we are making changes to the LWAPP protocol, and as a consequence did not state that the protocol was in complete compliance with the requirement. This document describes how the LWAPP protocol complies to the objectives. 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]. Calhoun, et al. Expires December 2, 2005 [Page 3] Internet-Draft LWAPP Self Evaluation May 2005 2. Objectives LWAPP is a generic protocol defining how Wireless Termination Points communicate with Access Controllers. Wireless Termination Points and Access Controllers may communicate either by means of Layer 2 protocols or by means of a Layer 3 routed IP network. 2.1 Mandatory Objectives This section contains all of the objectives that have been considered as being mandatory in order for a protocol to be considered. 2.1.1 Logical Groups WLAN deployment trends require the 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. 2.1.1.1 Protocol Evaluation The LWAPP protocol was designed to allow individual WTPs to support multiple BSSID/SSIDs, which allows for logical groups. From the AC's perspective, a logical group is created through the creation of a WLAN. A WLAN is a logical wireless network that is identified through the SSID and is advertised through the Beacon and Probe Response. Each WLAN can have a separate security policy, and has a unique BSSID, enabling the 802.11 stations to identify every WLAN as a separate network. In order to create a WLAN, the LWAPP protocol defines a primitive called the IEEE 802.11 Add WLAN (section 11.5.1.1 of the LWAPP specification), which is used by the AC to create an SSID on the WTP. In the WLAN creation process, the AC selects an unused WLAN Identifier, which is used to refer to the WLAN in future commands. An AC could use the same WLAN Identifier to refer to a single WLAN on all of its WTPs, ensuring a consistent interface across all WTPs. When user data is sent from the AC to the WTP, the BSSID field in the 802.11 header is used to identify the logical network which the packet is to be sent through. The same is true for packets received by the WTP from a station, where the BSSID would be used by the AC to recognize which logical network the packet was received on. It is expected that the AC and the WTP perform policing to ensure that a station only send packets on the correct BSSID. Calhoun, et al. Expires December 2, 2005 [Page 4] Internet-Draft LWAPP Self Evaluation May 2005 Furthermore, the 802.11 binding LWAPP section defines the WLANS field of the LWAPP header (in section 11.2.1 of the LWAPP specification). In this section, the specification states that data packets sent from the AC to the WTP include the WLAN Identifier that was used during the creation of the WLAN. 2.1.1.2 Compliance The LWAPP protocol satisfies this CAPWAP objective. 2.1.2 Support for Traffic Separation 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. Our personal interpretation of this objective is that there are two separate requirements. First, the data and control component of the protocol must be uniquely identified. Second, the protocol should allow for the control and data traffic to terminate on separate infrastructure devices, meaning that an AC may be split into two separate devices, one that handles the control and one that handles data. 2.1.2.1 Protocol Evaluation The LWAPP header, described in section 3.1 of the LWAPP specification, defines the 'C' bit, which when set indicates that the LWAPP frame contains a control frame. When the bit is cleared, the payload contains an LWAPP data frame. During the join phase, the AC may optionally include the WTP Manager Data IP Address (in section 6.2.5 of the LWAPP Specification), which is used to inform the WTP of the IP address to which it is to forward the LWAPP data frames. 2.1.2.2 Compliance The LWAPP protocol satisfies this CAPWAP objective. 2.1.3 Wireless Terminal Transparency Wireless terminals should not be required to recognize or be aware of the CAPWAP protocol. Our interpretation is that the introduction of the protocol, and therefore the new architecture, MUST be transparent to the 802.11 stations. Calhoun, et al. Expires December 2, 2005 [Page 5] Internet-Draft LWAPP Self Evaluation May 2005 2.1.3.1 Protocol Evaluation The LWAPP protocol was designed specifically to allow for centralized control and management of WTPs without any impact on the stations. Once a WTP has joined an AC, the latter will push down 802.11 and antenna configuration to the WTP, allowing it to provide service. Section 11.1 of the LWAPP specification defines the distribution of 802.11 functions, ensuring that all of the functions currently provided by an autonomous access point is preserved. Lastly, the proof is in the pudding. There are hundreds of thousands of LWAPP enabled WTPs, and tens of thousands of LWAPP enabled ACs, deployed in the field today, and these have been proven to work seamlessly with all 802.11 stations on the market. Furthermore, LWAPP AC and WTPs have been certified by the WiFi Alliance as being interoperable for 802.11b, 802.11a, 802.11g, WPA and WPA2 [9]. Certification testing performed by the WiFi Alliance is focused primarily on protocol compliance and interoperability between 802.11 stations and infrastructure (APs). 2.1.3.2 Compliance The LWAPP protocol satisfies this CAPWAP objective. 2.1.4 Configuration Consistency The CAPWAP protocol must allow for regular exchanges of state information between WTPs and WLAN controller. Examples of state information include WTP processing load and memory utilization. Our interpretation of this requirements is that there are two separate underlying requirements. First, there must be a mechanism by which the AC can propagate configuration information to the WTP, ensuring an AC is capable of easily maintaining the consistent configuration of every WTP associated with it. Second, there is a requirement stating that the WTP MUST periodically send utilization information to the AC, allowing the latter to make real-time configuration decisions to optimize the WLANs performance. 2.1.4.1 Protocol Evaluation The LWAPP protocol state machine defines the "configure" state, which is used during the initial binding WTP-AC phase, which allows for configuration exchange. During this period, the WTP sends its current configuration overrides to the AC. A configuration override is a parameter that is non-default. One example is that in the LWAPP protocol the default antenna configuration is internal omni antenna. Calhoun, et al. Expires December 2, 2005 [Page 6] Internet-Draft LWAPP Self Evaluation May 2005 However, a WTP that either has no internal antennas, or has been explicitely configured by the AC to use external antennas, would send its antenna configuration during the configure phase, allowing the AC to become aware of the WTP's current configuration. Once the WTP has provided its configuration to the AC, the AC sends down its own configuration. This allows the WTP to inherit the configuration and policies on the AC. An LWAPP AC maintains a copy of each active WTP's configuration. There is no versioning or other means to identify configuration changes. If a WTP becomes inactive, the AC MAY delete the configuration associated with it. If a WTP were to fail, and connect to a new AC, it would provide its overriden configuration parameters, allowing the new AC to be aware of the WTP's configuraion. Once the LWAPP protocol enters the Run state, the WTPs begin to provide service. However, it is quite common for administrators to require that configuration changes be made while the network is operational. Therefore, the Configuration Update Request is sent by the AC to the WTP in order to make these changes at run-time. The LWAPP protocol defines various commands that allow a WTP to inform the AC of real-time events. Including: Decryption Errors: When encryption is performed in the WTP, there is a configurable timer sent to the WTP requesting a periodic decryption error report. When sent by the WTP, the decryption error report includes the MAC address(es) of the offending stations. Duplicate IP Address: Given that WTPs are commonly installed in hard to reach places, it is necessary to know when the WTP detects network related errors without access to a console. Therefore, the LWAPP protocol defines a primitive that allows the WTP to report when it detects another host that has a duplicate IP address. Statistics: During the configuration phase, the AC transmits the statistics interval period, which is used by the WTP to send statistics reports to the AC. The LWAPP protocol defines an 802.11 binding specific statistics report message (see section 11.4.2.1 in the LWAPP specification), which is used to communicate load information to the AC. It is important to note that since all valid 802.11 data frames are tunneled to the AC, the AC may also calculate load statistics. New wireless technologies wishing to make use of LWAPP will need to define a technology binding statistics report format. Calhoun, et al. Expires December 2, 2005 [Page 7] Internet-Draft LWAPP Self Evaluation May 2005 802.11 MIC Countermeasures: The 802.11i specification [6] describes countermeasures that must be taken when a MIC error is detected. This event is sent by the WTP to the AC when such an event occurs, allowing the AC to take appropriate action (e.g., disabling the WLAN for a period of 60 seconds). Radio Fail Indication: As previously mentioned, since the WTP is not within easy physical access, assuming that observing LEDs to ensure the health of the WTP is not sufficient. Therefore, when a WTP detects a radio error, it issues a radio fail indication error. WTP Failure: A WTP failure may require the AC to take some specific action, which is not defined in the LWAPP specification. However, the LWAPP protocol does define the Echo Request command, which is used to detect network failures. Should the working group define additional information elements they feel would be useful to send from the WTP to the AC, the LWAPP protocol defines extensible mechanisms to issue event related information. 2.1.4.2 Compliance The LWAPP protocol satisfies this CAPWAP objective. 2.1.5 Firmware Trigger The CAPWAP protocol must support a trigger for delivery of firmware updates. 2.1.5.1 Protocol Evaluation The LWAPP state machine states that during the join phase, the AC and WTP exchange version numbers, including the hardware type and configuration. This information is used by the WTP to detect whether a firmware upgrade is required. Note that the LWAPP protocol also defines the actual primitives required to download the firmware to the WTP. It is not clear whether the working group has decided whether this function of the protocol is in or out of scope, but the authors feel that being able to piggyback off the security association already established with the AC provides for secure firmware download, minimizing vulneratibilities and possible confusion or errors that could occur by attempting to integrate multiple protocols within a single state machine in a secure fashion. Calhoun, et al. Expires December 2, 2005 [Page 8] Internet-Draft LWAPP Self Evaluation May 2005 2.1.5.2 Compliance The LWAPP protocol satisfies this CAPWAP objective. 2.1.6 Monitoring and Exchange of System-wide Resource State The CAPWAP protocol must allow for the exchange of statistics, congestion and other WLAN state information. 2.1.6.1 Protocol Evaluation The objective describes two separate set of segments; switched and wireless. On the switched segment, the LWAPP protocol provides a rich set of message elements to allow for the WTP and AC to exchange information, including, but not limited to, the WTP's firmware version and number of radios (see WTP Descriptor in section 5.1.2), radio failures (see IEEE 802.11 WTP Radio Fail Alarm Indication in section 11.5.3.2) and duplicate IP Address detection (see Duplicate IP Address in section 8.5.2). The WTP also has the ability to provide the reboot statistics, and the reason for a previous failure (see WTP Reboot Statistics in section 7.1.7). On the wireless side, the WTP will sent statistics to the AC based on the AC's policy, which is dictated through the Statistics Timer (see section 7.1.5). There are various tools available in the LWAPP protocol to allow for either the AC to request information from the WTP, or for the WTP to send unsolicited statistics (of various form) to the AC. The authors feel that if the working group has identified additional information they would like the AC to gain access to, we believe this can be done within the confines of the protocol. 2.1.6.2 Compliance The LWAPP protocol satisfies this CAPWAP objective. 2.1.7 Resource Control Objective The CAPWAP protocol must maintain IEEE 802.11e QoS mappings across the switching and wireless medium segments. Author comment: There are several requirements defined in the Resource Control Objective such as the ability to provide quality of service based on the 802.11e standard, as well as allow for the use of 802.11k or 802.11v. The objective also mentions 802.11u, which Calhoun, et al. Expires December 2, 2005 [Page 9] Internet-Draft LWAPP Self Evaluation May 2005 deals with inter-technology roaming, and since the authors do not understand how 802.11u relates to resource control, this specific standard will not be mentioned in this section. 2.1.7.1 Protocol Evaluation The LWAPP protocol defines the IEEE 802.11 WTP Quality of Service message element in section 11.6.14, which is used by the AC to push global 802.11e policies to the WTPs, ensuring that they are providing consistent service to the stations. This message element contains policies for the WTP for every access class defined in the 802.11e specification. It contains the CwMin, CwMax and AIFS fields which dictate how the individual transmit queues are to behave. The data structure also includes a CBR fields, which when present, dictates the amount of air time the access class is allowed to have, per beacon period (in %). The message element also specifies whether data packets are to be tagged, and if so, the tagging method, in terms of 802.1P or DSCP. When tagging is to be performed, there is a separate 802.1P and/or DSCP value for every access class. Note that although one could conceive there being a single QoS policy for a given network, there are no restrictions on having an AC sending a separate configuration to a given WTP. When the AC creates a WLAN on the WTP, through the IEEE 802.11 Add WLAN command, defined in section 11.5.1.1, the AC may set a default policy for all users assigned to the WLAN. In this case, the AC may include the WMM [8] and 802.11e Information Elements that are to be included in the Beacon and Probe Requests, as well as the default QoS value. The default value is to be used in determining the access class queue to use for all packets for the given user, unless a specific override was received when the user's context was created on the WTP. When an AC pushes a mobile's policy to the WTP, through the Add Mobile command, which is defined in section 11.4.1.1, it can specify the QoS policy for the station. For instance, the AC specifies whether the station supports either the WMM or the 802.11e protocol. The Add Mobile command also allows the AC to dictate how the user's data packets are to be treated from a QoS perspective. For instance, if the AC determines that a given station is to be provided either WMM or 802.11e service, it would set the appropriate bits, and ensure that the 802.11e UP field is set accordingly within the encapsulated 802.11 data packet to the user. The quality of service field is to be used by the WTP on any packets sent over the air for which no UP information is available (default value for non QoS marked packets). The QoS Profile defined in section 11.4.1.3 of the LWAPP specification is included in an Add Mobile command and is used by the Calhoun, et al. Expires December 2, 2005 [Page 10] Internet-Draft LWAPP Self Evaluation May 2005 AC to set the upper limit for incoming WMM or 802.11e packets from a given user. The 802.1P precedence value is to be considered to be the maximum value allowed by the station. The WTP is expected to perform policing of incoming data from the station, and remark any packets as it deems necessary. The IEEE 802.11 Update Mobile QoS message element may be sent at any time by the AC to the WTP in order to modify the quality of service properties associated with the station. The 802.1P and DSCP fields have two purposes. For WMM or 802.11e stations, this value is intended to be the maximum value that can be set for a given station. However, for non-WMM or non-802.11e stations, these values are intended to be the default value for all packets received from the station. Although not related to QoS per-se, if the VLAN identifier field in the message element is intended to represents the VLAN on which the station is to be assigned when the LWAPP protocol is used in the local MAC mode. In terms of support of 802.11e (or 802.11k), the WTP is expected to forward any received Action frames received on behalf of the station. This allows the AC to set the QoS policy for the user, including admission control. For 802.11k, the various Radio Management messages would be exchanged transparently through the WTP. Unfortunately, the 802.11u task group is still to early in its infancy to determine what functionality it will provide, but should standard management frames be used, the LWAPP protocol could tunnel them transparently through the WTP. 2.1.7.2 Compliance The LWAPP protocol satisfies this CAPWAP objective. 2.1.8 CAPWAP Protocol Security The CAPWAP protocol must support mutual authentication of WTPs and the centralized controller. It must also ensure that information exchanges between them are secured. Our interpretation of this objective is that it states that some cryptographic exchange must be defined in the specification in order to protect the contents of the control protocol. Further, this requires state that mutual authentication is required. The requirement states the key exchange protocol must be designed in such a way where once a security association has been established, there is no possible compromises. Lastly, while the requirements do not specifically state how the WTP and the AC are to authenticate each other, it does state that the protocol should allow for either symmetric or asymmetric cryptography. Calhoun, et al. Expires December 2, 2005 [Page 11] Internet-Draft LWAPP Self Evaluation May 2005 2.1.8.1 Protocol Evaluation The LWAPP protocol defines two different types of method by which a session key is distributed from the AC to the WTP. The assumptions used in the creation of the security protocol used by LWAPP can be found in section 10.1 of the LWAPP specification. The first method is based on asymmetric cryptography and relies on the presence of X.509 certificates on both the AC and the WTP, and is defined in section 10.3.1 of the LWAPP specification. The second method is symmetric in nature and relies on pre-shared keys, which must be configured apriori on both the AC and the WTP, and is described in section 10.3.2. There is a difference in the LWAPP state machine when either the X.509 certificate mode is used vs. the pre-shared key mode. When the pre-shared key mode is used, there is explicit key confirmation phase that is provided through the use of the Join-Ack/Join-Confirm messages. As recommended by the security review, the state machine will be modified such that the X.509 mode makes use of this new key confirmation phase. There is a distinct difference in the key distribution protocol used by either the X.509 certificate mode vs. the pre-shared key mode. In the X.509 mode, the session keys are created randomly by the AC, while the pre-shared key mode the session keys are mutually derived. As a result of the security evaluation performed on the LWAPP protocol, the X.509 certificate mode will be modified to make use of the mutually derived session key method. Once session keys have been exchanged between the WTP and the AC, the LWAPP protocol defines how the control frames are to be encrypted in section 10.2. The encryption algorithm used is AES-CCM, and this section also discussed how the initialization vectors are derived. The LWAPP state machine defines a rekey mechanism, which allows for the session keys to be refreshed over time, minimizing the amount of data that is encrypted with the same session key. The Security Considerations section of the LWAPP protocol suggest that the AC provide some form of authorization when a WTP attempts to connect. This would disallow for unauthorized WTPs to connect. Further, when the certificate based approach is used, the AC should validate the identity of the WTP within the certificate itself. 2.1.8.2 Compliance The LWAPP protocol partially satisfies this CAPWAP objective. Calhoun, et al. Expires December 2, 2005 [Page 12] Internet-Draft LWAPP Self Evaluation May 2005 2.1.9 System-wide Security The design of the CAPWAP protocol should not allow for any compromises to the WLAN system by external entities. 2.1.9.1 Protocol Evaluation An Access Controller and Wireless Termination Point that support the LWAPP protocol are no more vulnerable than any off the shelf access point, meaning that the LWAPP protocol itself does not in any way add to the compromise of the system. As previously mentioned, the control protocol is secured through a key exchange that is protected either through a pre-shared key or via an X.509 certificate. There is one specific issue that is mentioned in the objectives draft, which states that PMK sharing shall not be permitted. It is important to note that the PMK is held at the AC, whether or not the PMK is shared across multiple WTPs is implementation specific and completely outside the scope of the LWAPP protocol. It is assumed that LWAPP enabled ACs comply with the 802.11i protocol, which has strict guidelines on key usage. One advantage of the centralized policy enforcement architecture that is inherited from the LWAPP protocol is the fact that the AC is capable of detecting and correlating attacks across multiple WTPs, and allow the administrator to take some action. However, these types of actions are not specified in the LWAPP protocol. If rogue clients attempt to send improperly encrypted frames, either through an SSID that mandates a static WEP key, or by creating a MIC attack, the AC will be notified of the failure, including the offending station's MAC address, as well as the WTP on which the attack was detected. This could allow the system to take action, such as countermeasures in the case of a MIC attack. Although not specified in the LWAPP protocol specification, it is assumed that AC manufacturers build proper defenses into their implementation to detect and report malicious behavior, such as excessive failed authentication attampts or associations, etc. Note that these types of protections are required in any good 802.11 AP implementation, regardless of whether the infrastructure is of the autonomous form, or uses a hierarchical architecture. The LWAPP protocol as currently specified does not provide enough text to guide the implementor into making the proper decisions in how to deal with hand-offs when 802.11i is used. As the LWAPP security review recommends, the LWAPP protocol will include new text to make it clear that sending a Delete-Mobile to a station's old AP, as well Calhoun, et al. Expires December 2, 2005 [Page 13] Internet-Draft LWAPP Self Evaluation May 2005 as redirecting the user's traffic through the new AP, through the use of the Add-Mobile, MUST only occur once the user has either successfully authenticated and key exchange was completed, or in the event that an 802.11i key cache entry exist, only a successful key exchange is necessary. The LWAPP protocol does not currently include any text to restrict the use of WEP over the air, but such text could be added should the working group deems it necessary. 2.1.9.2 Compliance The LWAPP protocol partially satisfies this CAPWAP objective. 2.1.10 IEEE 802.11i Considerations 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. 2.1.10.1 Protocol Evaluation The LWAPP protocol is capable of supporting both local and split MAC approaches, but the current specification only defines the division of labor for the split MAC mode. In section 11.1, which defines where the functions reside in the split MAC mode, it specifies that the 802.1X authenticator resides in the Access Controller. As a consequence, a station's PMK is only maintained in the AC. During the LWAPP join phase, which creates the binding between the WTP and the AC, the WTP specifies its encryption capabilities, through the WTP Descriptor message element (described in section 5.1.2). This message element allows the WTP to specify whether it is capable of providing encryption capabilities, and if so, which algorithms are supported. Ultimately, it is the AC's policy that dictates where encryption will be provided, through the encrypt policy field of the Add Mobile message element. When a WLAN has been configured for 802.1X authentication, once a station has associated, the AC would send down an Add Mobile message element that specifies that the policy requires that only 802.1X frames are to be permitted. Optionally, the AC may specify a session Calhoun, et al. Expires December 2, 2005 [Page 14] Internet-Draft LWAPP Self Evaluation May 2005 key should the EAP frames require encryption. The WTP then simply forwards all 802.1X frames either to the station or the AC (depending upon the direction of the frame). The WTP does not participate in the 802.1X authentication exchange. Once the 802.11i process is completed, and the AC has computed the PTK, if the AC's policy states that encryption is to be performed on the WTP, it would issue a new Add Mobile message element, but this time without the 802.1X only bit set, and the PTK in the session key field and the encrypt policy field set to an appropriate value. If the AC's policy states that encryption is to be performed at the AC, then it would ommit the session key, and set the encrypt policy field to "Clear Text". For Local MAC WTPs, the encryption would have to occur in the WTP since in this mode of operation, the WTP bridges user data frames locally. 2.1.10.2 Compliance The LWAPP protocol satisfies this CAPWAP objective. 2.1.11 Interoperability Objective The CAPWAP protocol must include sufficient capabilities negotiations to distinguish between major types of WTPs. 2.1.11.1 Protocol Evaluation The LWAPP protocol is capable of supporting both local and split MAC approaches, but the current specification only defines the division of labor for the split MAC mode. The justification behind stating that the protocol is capable of supporting local MAC is the fact that LWAPP products are available today that run in local MAC mode. The co-authors did not want to add the necessary text required to support local MAC without significant review, and unfortunately time did not permit us to do so. The method by which a WTP advertises its mode of operation is through the WTP Mode and Type message element, which may be found in section 11.6.12. When set to zero, the mode of operation is Split MAC, while when set to two it is Local MAC. In order to fully support the Local MAC mode, the LWAPP specification will need to include the necessary text in section 11.1.2, which simply specifies the division of labor across the WTP and the AC. Calhoun, et al. Expires December 2, 2005 [Page 15] Internet-Draft LWAPP Self Evaluation May 2005 2.1.11.2 Compliance The LWAPP protocol partially satisfies this CAPWAP objective. 2.1.12 Protocol Specifications 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. 2.1.12.1 Protocol Evaluation The LWAPP protocol is a fully specified protocol that is capable of ensuring that any WTP or AC vendor can gain guaranteed interoperability. Note that the authors realize that some changes will be required during the standardization phase, and that some of these changes will increase the level of interoperability by addressing areas that may be underspecified. However, the LWAPP protocol has been publicly available for well over 18 months, and has undergone many external recommendations that help interoperability. 2.1.12.2 Compliance The LWAPP protocol satisfies this CAPWAP objective. 2.1.13 Vendor Independence A WTP vendor can make modifications to hardware without any AC vendor involvement. 2.1.13.1 Protocol Evaluation Because the LWAPP protocol is fully specified, it is assumed that the WTP vendors will do the actual implementation of the protocol on their hardware, providing them with the ability to make any necessary changes as they see fit without the involvement of a third party AC vendor. 2.1.13.2 Compliance The LWAPP protocol satisfies this CAPWAP objective. 2.1.14 Vendor Flexibility WTP vendors must not be bound to a specific MAC. Calhoun, et al. Expires December 2, 2005 [Page 16] Internet-Draft LWAPP Self Evaluation May 2005 2.1.14.1 Protocol Evaluation The authors of the LWAPP protocol have had discussions with the most popular MAC vendors to ensure that the assumptions behind the split MAC approach would work on any chipset, and have yet to find a vendor that could not support LWAPP. Since the LWAPP protocol is fully specified, and the fact that the assumption behind having a specification that any WTP vendor may implement without the aid of any AC vendors, allows for innovation by these third party WTP vendors without requiring that they disclose any confidential information about their chip. 2.1.14.2 Compliance The LWAPP protocol satisfies this CAPWAP objective. 2.2 Desirable Objectives 2.2.1 Multiple Authentication Mechanisms The CAPWAP protocol must support different authentication mechanisms in addition to IEEE 802.11i. 2.2.1.1 Protocol Evaluation The LWAPP protocol allows for multiple SSIDs be to created on a WTP, and for every one of these WLANs, a separate security policy may exist. For instance, the Encryption Policy field of the IEEE 802.11 Add WLAN message element, described in section 11.5.1.1, defines static and Dynamic WEP encryption, as well as TKIP and AES. Further, the Encryption Policy may be set to Clear Text, which would be used in the case where a captive portal were to be used. 2.2.1.2 Compliance The LWAPP protocol satisfies this CAPWAP objective. 2.2.2 Support for Future Wireless Technologies 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 relating to IEEE 802.11. 2.2.2.1 Protocol Evaluation Section 2.1 of the LWAPP specification describes the process that must be followed in order to define a wireless technology binding for Calhoun, et al. Expires December 2, 2005 [Page 17] Internet-Draft LWAPP Self Evaluation May 2005 LWAPP. Further, section 11 defines the IEEE 802.11 binding. While no other technology bindings have been defined yet, the authors feel very confident that this can be done with relative ease. One of the reasons why it is felt that the LWAPP protocol is sufficiently flexible is the fact that the protocol simply states that all "access related" wireless control frames (e.g., Association Request for 802.11) are tunneled to the AC. While this does impose the requirement that the AC must understand the individual wireless technologies, the authors would argue that this would be required regardless in order for the AC to be able to provide additional services, such as centralized authentication and key distribution, quality of service access control, etc. One alternative to the LWAPP approach would be to attempt to map individual information elements found within a wireless protocol frame to a generic protocol data set, and hide the underlying technology from the AC. However, every wireless technology have objects that are very specific and unique, and cannot be easily mapped to a generic information element. Some of these information elements could also be items that the AC would need to have access to in order to make policy decisions. The authors of the LWAPP specification therefore feel that simply tunneling the wireless technology frames to the AC allows for the most flexibility and extensibility. 2.2.2.2 Compliance The LWAPP protocol satisfies this CAPWAP objective. 2.2.3 Support for New IEEE Requirements The CAPWAP protocol must be openly designed to support new IEEE extensions. 2.2.3.1 Protocol Evaluation The LWAPP protocol was designed to be able to accomodate new IEEE extensions defined, and the authors of the specification have been involved in the 802.11 IEEE process for as many as 14 years. Therefore, we feel that there is significant expertise in the group to be justify our statement. One example of extensibility is support for 802.11k. Given that the management frames are tunneled from the WTP to the AC, in order for the AC to support 802.11k, all that is needed is for the WTP to forward the related action frames. The AC may initiate an 802.11k radio measurement simply by sending a tunneled 802.11 management Calhoun, et al. Expires December 2, 2005 [Page 18] Internet-Draft LWAPP Self Evaluation May 2005 frame to the appropriate station, through its WTP. Another example of extensibility is the ability to support other wireless technologies. This requirement was addressed in section Section 2.2.2. That said, the CAPWAP WG and the authors cannot predict all of the future work that will be done by the IEEE. So it is possible that some future extensions will require some additional IETF CAPWAP standardization work. It is therefore necessary to make sure that the WG puts in place a set of guidelines for IANA numbering assignment and a process for protocol extensibility. The authors expect to create an extensive IANA considerations section to the LWAPP spec if it is selected as the basis for the working group. 2.2.3.2 Compliance The LWAPP protocol satisfies this CAPWAP objective. 2.2.4 Interconnection Objective The CAPWAP protocol must not be constrained to specific underlying transport mechanisms. 2.2.4.1 Protocol Evaluation The LWAPP protocol was designed to be able to be transported over any link layer. The current specification defines the use of either Ethernet or UDP/IP as transports. Much of the dependences on transport capabilities have been removed by including support for these within the LWAPP protocol itself (for instance fragmentation/ reassembly). As a consequence, it is felt that the protocol is sufficiently flexible to handle a variety of underlying transports, with the understanding that certain guidelines would have to be specified for new transports. The authors of the LWAPP protocol realize that the current specification does not have enough flexibility to accomodate IPv6, and are currently working on a new revision that will include support for both IPv4 and IPv6. The number of areas where this is problematic is very small, since it is mostly concentrated in the areas where IP addresses are included as part of protocol payloads. This will be included in the next version of the LWAPP specification. 2.2.4.2 Compliance The LWAPP protocol partially satisfies this CAPWAP objective. Calhoun, et al. Expires December 2, 2005 [Page 19] Internet-Draft LWAPP Self Evaluation May 2005 2.2.5 Access Control The CAPWAP protocol must be capable of exchanging information required for access control of WTPs and wireless terminals. 2.2.5.1 Protocol Evaluation Given the LWAPP protocol requires that the 802.11 MAC management frames be tunneled to the AC, the AC has complete control over the behavior of the network, and can implement certain strategies such as load balancing. Further, as previously described since 802.11e simply builds on top of management frames, these would be sent to the AC, which would then have the ability to perform admission control, etc. The security considerations section of the LWAPP specification states that an AC SHOULD perform authorization of WTPs prior to allowing them to join. This function is outside the scope of the LWAPP protocol, and could be performed through a function such as RADIUS or LDAP. However, the authors recognize that authorization of WTPs is necessary in order to eliminate the possibility of grey market APs from connecting to the CAPWAP infrastructure. 2.2.5.2 Compliance The LWAPP protocol satisfies this CAPWAP objective. 2.3 Rejected Objectives 2.3.1 Support for Non-CAPWAP WTPs The CAPWAP protocol should be capable of recognizing legacy WTPs and existing network management systems. 2.3.1.1 Protocol Evaluation As mentioned in the objectives document, whether an AC is capable of supporting non-CAPWAP WTPs is an implementation issue, and is not required as part of a candidate protocol. 2.3.1.2 Compliance The LWAPP protocol satisfies this CAPWAP objective. 2.3.2 Technical Specifications WTP vendors should not have to share technical specifications for hardware and software to AC vendors in order for interoperability to Calhoun, et al. Expires December 2, 2005 [Page 20] Internet-Draft LWAPP Self Evaluation May 2005 be achieved. 2.3.2.1 Protocol Evaluation Although the working group opted to reject this objective, the authors of the LWAPP specification wish to re-inforce that they believe that any specification adopted by the working group must be sufficiently specified to ensure that any third party WTP is capable of providing 802.11 access to stations in an interoperable manner. 2.3.2.2 Compliance The LWAPP protocol satisfies this CAPWAP objective. 2.4 Operator Requirements 2.4.1 AP Fast Handoff CAPWAP protocol operations must not impede or obstruct the efficacy of AP fast handoff procedures. 2.4.1.1 Protocol Evaluation The authors of the LWAPP specification believe that the protocol as specified is capable of handling fast AP handoffs. The fact that the WTP only needs to tunnel any management frames, as opposed to perform some packet manipulation significantly increases the ability for the WTPs to handle low latency handoffs, especially in the face of network load. Further, the centralization of the 802.1X function allows for an authenticator to have quick access to information which will could crucial for new initiatives such as the 802.11r fast roaming group. Using the terminology defined by 802.11r, whereby a handoff starts as of the last packet on the old AP to the first packet on the new AP. Existing LWAPP products shipping in the field are capable of performing this function in less than 30 ms. 2.4.1.2 Compliance The LWAPP protocol satisfies this CAPWAP objective. Calhoun, et al. Expires December 2, 2005 [Page 21] Internet-Draft LWAPP Self Evaluation May 2005 3. Compliance Table Compliance Rating Logical Groups S Support for Traffic Separation S Wireless Terminal Transparency S Configuration Consistency S Firmware Trigger S Monitoring and Exchange of System-wide Resource State S Resource Control Objective S CAPWAP Protocol Security P (1) System-wide Security P (1) IEEE 802.11i Considerations S Interoperability Objective P 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 P Access Control S Support for Non-CAPWAP WTPs S Technical Specifications S AP Fast Handoff S (1) The LWAPP protocol security review found that while the protocol is in itself technically secure, it is not cryptographically secure. The review also provided some recommendations, which the authors plan to introduce in the next version of the protocol. As a consequence, the authors feel that in the spirit of intellectual honesty the protocol is only partially in compliance with the requirements. Calhoun, et al. Expires December 2, 2005 [Page 22] Internet-Draft LWAPP Self Evaluation May 2005 4. Security Considerations This document simply lists how the LWAPP protocol conforms to the requirements listed in the CAPWAP objectives document. The LWAPP specification has an extensive security considerations section which applies to the protocol itself. There is nothing specific about this document that introduces new security considerations. Calhoun, et al. Expires December 2, 2005 [Page 23] Internet-Draft LWAPP Self Evaluation May 2005 5. IANA Considerations This document requires no action by IANA. Calhoun, et al. Expires December 2, 2005 [Page 24] Internet-Draft LWAPP Self Evaluation May 2005 6. Acknowledgements The authors would like to thanks Russ Housley and Charles Clancy for their assistance in provide a security review of the LWAPP specification. Calhoun, et al. Expires December 2, 2005 [Page 25] Internet-Draft LWAPP Self Evaluation May 2005 7. IPR Statement The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. Please refer to http://www.ietf.org/ietf/IPR for more information. Calhoun, et al. Expires December 2, 2005 [Page 26] Internet-Draft LWAPP Self Evaluation May 2005 8. References 8.1 Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Govindan, S., "Objectives for Control and Provisioning of Wireless Access Points (CAPWAP)", draft-ietf-capwap-objectives-02 (work in progress), April 2005. [3] Yang, L., Zerfos, P., and E. Sadot, "Architecture Taxonomy for Control and Provisioning of Wireless Access Points(CAPWAP)", draft-ietf-capwap-arch-06 (work in progress), November 2004. [4] Calhoun, P., "Light Weight Access Point Protocol (LWAPP)", draft-ohara-capwap-lwapp-02 (work in progress), April 2005. [5] "Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications", IEEE Standard 802.11, 1999, . [6] "Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications Amendment 6: Medium Access Control (MAC) Security Enhancements", IEEE Standard 802.11i, July 2004, . [7] Clancy, C., "Security Review of the Light Weight Access Point Protocol", May 2005, . [8] "Wi-Fi Certified for WMM - Support for Multimedia Applications with Quality of Service in WiFi Networks", September 2004, . [9] "Wi-Fi Protected Access (WPA)", March 2005, . Calhoun, et al. Expires December 2, 2005 [Page 27] Internet-Draft LWAPP Self Evaluation May 2005 8.2 Informational References Authors' Addresses Pat R. Calhoun Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 Phone: +1 408-853-xxxx Email: pcalhoun@cisco.com Bob O'Hara Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 Phone: +1 408-853-xxxx Email: bob.ohara@cisco.com Michael Glenn Williams Nokia, Inc. 313 Fairchild Drive Mountain View, CA 94043 Phone: +1 650-714-7758 Email: Michael.G.Williams@Nokia.com Sue Hares Nexthop Technologies, Inc. 825 Victors Way, Suite 100 Ann Arbor, MI 48108 Phone: +1 734 222 1610 Email: shares@nexthop.com Calhoun, et al. Expires December 2, 2005 [Page 28] Internet-Draft LWAPP Self Evaluation May 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. Calhoun, et al. Expires December 2, 2005 [Page 29]