CAPWAP Working Group P. Narasimhan Internet-Draft Aruba Networks Expires: October 2, 2005 D. Harkins Trapeze Networks March 31, 2005 SLAPP : Secure Light Access Point Protocol draft-narasimhan-ietf-slapp-00 Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with RFC 3668. 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 October 2, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract The CAPWAP problem statement [3] describes a problem that needs to be addressed before a wireless LAN (WLAN) network designer can construct a solution composed of Wireless Termination Points (WTP) and Access Controllers (AC) from multiple, different vendors. One of the primary goals is to find a solution that solves the interoperability Narasimhan & Harkins Expires October 2, 2005 [Page 1] Internet-Draft SLAPP March 2005 between the two classes of devices (WTPs and ACs) which then enables an AC from one vendor to control and manage a WTP from another. The interoperability problem is more general than as stated in the CAPWAP problem statement [3] because it can arise out of other networks that do not necessarily involve WLAN or any wireless devices. A similar problem exists in any network that is composed of network elements that are managed by a centralized controller where these two classes of devices are from different vendors and need to interoperate with each other such that the network elements can be controlled and managed by the controller. A possible solution to this problem is to split it into two parts - one that is technology or application independent which serves as a common framework across multiple underlying technologies, and another that is dependent on the underlying technology that is being used in the network. For example, methods and parameters used by an 802.11 AC to configure and manage a network of 802.11 WTPs are expected to be quite different than that used by an equivalent 802.16 controller to manage a network of 802.16 base stations. The architectural choices for these two underlying technologies may also be significantly different. In this draft, we present a protocol that forms the common technology-independent framework and the ability to add, on top of this framework, extensions that contain a technology-dependent component to arrive at a complete solution. We have also presented one such extension, the image download protocol, in this draft. Even though the text in this draft is written to specifically address the problem stated in [3], the solution can be applied to any problem that has a controller (equivalent to the AC) managing one or more network elements (equivalent to the WTP). Narasimhan & Harkins Expires October 2, 2005 [Page 2] Internet-Draft SLAPP March 2005 Table of Contents 1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1 Conventions used in this document . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1 Protocol Description . . . . . . . . . . . . . . . . . . . 9 4.1.1 State Machine Explanation . . . . . . . . . . . . . . 9 4.2 Format of a SLAPP Header . . . . . . . . . . . . . . . . . 10 4.3 Version . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.4 Retransmission . . . . . . . . . . . . . . . . . . . . . . 12 4.5 Discovery . . . . . . . . . . . . . . . . . . . . . . . . 12 4.5.1 SLAPP Discover Request . . . . . . . . . . . . . . . . 13 4.5.2 SLAPP Discover Response . . . . . . . . . . . . . . . 15 4.6 SLAPP Discovery Process . . . . . . . . . . . . . . . . . 17 4.6.1 WTP . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.6.2 AC . . . . . . . . . . . . . . . . . . . . . . . . . . 19 5. Security Association . . . . . . . . . . . . . . . . . . . . . 20 5.1 Example Authentication Models (Informative) . . . . . . . 20 5.1.1 Mutual Authentication . . . . . . . . . . . . . . . . 21 5.1.2 WTP-only Authentication . . . . . . . . . . . . . . . 21 5.1.3 Anonymous Authentication . . . . . . . . . . . . . . . 21 6. Image Download Protocol . . . . . . . . . . . . . . . . . . . 22 6.1 Image Download Packet . . . . . . . . . . . . . . . . . . 22 6.2 Image Download Request . . . . . . . . . . . . . . . . . . 23 6.3 Image Download Process . . . . . . . . . . . . . . . . . . 23 6.4 Image Download State Machine . . . . . . . . . . . . . . . 24 6.4.1 AC . . . . . . . . . . . . . . . . . . . . . . . . . . 24 6.4.2 WTP . . . . . . . . . . . . . . . . . . . . . . . . . 26 7. Security Considerations . . . . . . . . . . . . . . . . . . . 29 8. Extensibility to other technologies . . . . . . . . . . . . . 30 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 31 Intellectual Property and Copyright Statements . . . . . . . . 32 Narasimhan & Harkins Expires October 2, 2005 [Page 3] Internet-Draft SLAPP March 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]. Narasimhan & Harkins Expires October 2, 2005 [Page 4] Internet-Draft SLAPP March 2005 2. Introduction The need for a protocol by which wireless LAN (WLAN) Access Controllers (AC) can control and manage Wireless Termination Points (WTP) from a different vendor has been presented in the CAPWAP problem statement [3]. We believe that this problem is more general than as stated in [3] and can be found in any application, including non-wireless ones, that requires a central controller to control and manage one or more network elements from a different vendor. One way to solve the CAPWAP problem is to define a complete control protocol that enables an AC from one vendor to control and manage a WTP from a different vendor. But a solution that is primarily focused towards solving the problem for one particular underlying technology (IEEE 802.11, in this case) may find it difficult to address other underlying technologies. Different underlying technologies may differ on the set of configuratble options, and different architectural choices that are specific to that underlying technology (similar to the local MAC vs. split MAC architectures in 802.11). The architectural choices that are good for one underlying technology may not necessarily work for another. Not to forget that there may be multiple architectural choices [2] even for the same underlying technology. A monolithic control protocol that strives to solve this problem for multiple technologies runs the risk of adding too much complexity and not realizing the desired goals, or it runs the risk of being too rigid and hampering technological innovation. A different way to solve this problem is to split the solution space into two components - one that is technology agnostic or independent, and another that is specific to the underlying technology or even different approaches for the same underlying technology. The technology-independent component would be a common framework that would be an important component of the solution to this class of problems without any dependency on the underlying technology (i.e. 802.11, 802.16, etc.) being used. The technology-specific component would be an extension over this common framework and can be easily defined to be relevant to that technology without the need for having any dependency on other underlying technologies. This approach also lends itself easily to extend the protocol as new technologies arise or as new innovative methods to solve the same problem for an existing technology present themselves later in the future. In this draft, we present secure light access point protocol (SLAPP), a technology-independent protocol by which network elements that are meant to be centrally managed by a controller can discover one or more controllers, perform a security association with one of them, and negotiate an extension that they would use to perform the technology-specific components of the control and provisioning Narasimhan & Harkins Expires October 2, 2005 [Page 5] Internet-Draft SLAPP March 2005 protocol. We have also presented one possible extension that is very generic and can be applied to any underlying technology. Figure 1 shows the model by which extensions can be added to SLAPP to complete a solution for a certain underlying technology. The figure shows an extension each for 802.11 and 802.16 technology components, but the SLAPP model does not preclude multiple extensions within a certain technology segment. For example, a certain SLAPP extension may choose to support only the local MAC architecture [2] while deciding not to support the split MAC architecture [2]. While the image download protocol is presented in this draft, a SLAPP implementation MUST NOT assume that this extension is supported by other SLAPP implementations. +-----------+ +------------+ +------------+ | | | | | | | Image | | 802.11 | | 802.16 | | Download | | control | | control | ........ | Extension | | extension | | extension | | | | | | | +-----+-----+ +------+-----+ +------+-----+ | | | | | | +-------+-------------------+------------------+---------+ | | | SLAPP (technology-independent framework) | | | +--------------------------------------------------------+ Figure 1 Recently, there was a significant amount of interest in a similar problem in the RFID space that has led to the definition of a simple lightweight RFID reader protocol (SLRRP) [7]. It is quite possible that SLRRP could be a technology-specific (RFID, in this case) extension over a common technology-independent framework. All of the text in the draft would seem to be written with a WLAN problem in mind. Please note that while the letter of the draft does position the solution to solve a CAPWAP-specific problem, the spirit of the draft is to address the more general problem. Narasimhan & Harkins Expires October 2, 2005 [Page 6] Internet-Draft SLAPP March 2005 3. Topology The SLAPP protocol supports multiple topologies for interconnecting WTPs and ACs as indicated in Figure 2. In Figure 2, we have captured four different interconnection topologies. 1. The WTP is directly connected to the AC without any intermediate nodes. Many WTPs are deployed in the plenum of buildings and are required to be powered over the Ethernet cable that is connecting it to the network. Many ACs in the marketplace can supply power over etherent and in the case where the AC is the one powering the WTP, the WTP is directly connected to the AC. 2. The WTP is not directly connected to the AC, but both the AC and the WTP are in the same L2 (broadcast) domain. 3. The WTP is not directly connected to the AC, and they are not present in the same L2 (broadcast) domain. They are on two different broadcast domains and have a node on the path that routes between two or more subnets. 4. The fourth case is a subset of the third one with the exception that the intermediate nodes on the path from the WTP to the AC may not necessarily be in the same administrative domain. The intermediate network may also span one or more WAN links that may have lower capacity than if both the AC and the WTP are within the same building or campus. Narasimhan & Harkins Expires October 2, 2005 [Page 7] Internet-Draft SLAPP March 2005 +-----------------+ +-------+ | | (1) | | | AC +------------+ WTP | | | | | +--------+--------+ +-------+ | | | +---+---+ (2) | | +------+ L2 +--------+ | | | | | +---+---+ | | | | | +-----+-----+ +---+---+ +-------+ | | | | (3)| | | WTP | | L3 +----+ WTP | | | | | | | +-----------+ +---+---+ +-------+ | | | +---+----+ +-------+ | | (4)| | |Internet+----+ WTP | | | | | +--------+ +-------+ Figure 2 Narasimhan & Harkins Expires October 2, 2005 [Page 8] Internet-Draft SLAPP March 2005 4. Protocol 4.1 Protocol Description The SLAPP state machine for both the WTP and AC is shown in Figure 3. Both the WTP and the AC discover each other, negotiate a control protocol, perform a secure handshake to establish a secure channel between them, and then use that secure channel to protect a negotiated control protocol. The WTP maintains the following variable for its state machine: abandon: a timer which sets the maximum amount of time the WTP will wait for an acquired AC to begin the DTLS handshake. /--------\ /-----------\ | | | | | v v | | +-------------+ | | C| discovering |<-\ | | +-------------+ | | | | | | | v | | | +-----------+ | | \--| acquiring | | | +-----------+ | | | | | v | | +----------+ | | C| securing |-----/ | +----------+ | | | v | +----------------+ | | negotiated | | C| control |-----/ | protocol | +----------------+ Figure 3 4.1.1 State Machine Explanation Note: the symbol "C" indicates an event which results in the state remaining the same. Narasimhan & Harkins Expires October 2, 2005 [Page 9] Internet-Draft SLAPP March 2005 Discovering AC: this is a quiescent state for the AC in which it waits for WTPs to request its acquisition. When a request is received the AC transitions to Acquiring. WTP: the WTP is actively discovering an AC. When the WTP receives a response to its discovery request it transitions to Acquiring. Acquiring AC: a discover request from a WTP has been received. If the request is invalid or the AC wishes to not acquire the WTP it drops the packet and transitions back to Discovering. Otherwise a discovery response is sent and the AC transitions to Securing. WTP: a discover response from an AC has been received. If the response is not valid the WTP transitions to Discovering, otherwise it sets the abandon timer to a suitable value to await a DTLS exchange. If the timer fires in Acquiring the WTP transitions back to Discovering. If a DTLS "client hello" is received the WTP transitions to Securing and cancels the abandon timer. Securing AC: The AC performs the "client end" of the DTLS exchange. Any error in the DTLS exchange results in the AC transitioning to Discovering. When the DTLS exchange finishes the AC transitions to Negotiated Control Protocol. WTP: The WTP performs the "server end" of the DTLS exchange. Any error in the DTLS exchange results in the WTP transitioning to Discovering. When the DTLS exchange finishes the WTP transitions to the Negotiated Control Protocol. Negotiated Control Protocol AC: the AC performs its side of the protocol agreed to during the discovery process. (For the Image Download Protocol example see section Section 6). WTP: the WTP performs its side of the protocol agreed to during the discovery process. (For the Image Download Protocol example see section Section 6). 4.2 Format of a SLAPP Header All SLAPP packets begin with the same header as shown in Figure 4. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Maj | Min | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4 Narasimhan & Harkins Expires October 2, 2005 [Page 10] Internet-Draft SLAPP March 2005 Where: Maj (4 bits): the major number of the SLAPP version Min (4 bits): the minor number of the SLAPP version Type (1 octet): the type of SLAPP message Length (two octets): the length of the SLAPP message, including the entire SLAPP header The following types of SLAPP messages have been defined: name type ------ ------ discovery request 1 discovery response 2 image download control 3 reserved 4-255 4.3 Version SLAPP messages include a version in the form of major.minor. This document describes the 1.0 version of SLAPP, that is the major version is one (1) and the minor version is zero (0). Major versions are incremented when the format of a SLAPP message changes or the meaning of a SLAPP message changes such that it would not be properly parsed by an older, existing version of SLAPP. Minor versions are incremented when some incremental additions have been made to SLAPP that enhance its capabilities or convey additional information in a way that does not change the format or meaning of the SLAPP message. Future versions of SLAPP MAY NOT mandate support for earlier major versions of SLAPP so an implementation MUST NOT assume that a peer that supports version "n" will therefore support version "n - i" (where both "n" and "i" are non-zero integers and "n" is greater than "i"). A SLAPP implementation that receives a SLAPP message with a higher major version number MUST drop that message. A SLAPP implementation that receives a SLAPP message with a lower major version SHOULD drop down to the version of SLAPP the peer supports. If that version of SLAPP is not supported the message MUST be dropped. There may be valid reasons for which a peer wishes to drop a SLAPP message with a supported major version though. A SLAPP implementation that receives a SLAPP message with a higher minor version number MUST NOT drop that message. It MUST respond with the minor version number that it supports and will necessarily Narasimhan & Harkins Expires October 2, 2005 [Page 11] Internet-Draft SLAPP March 2005 not support whatever incremental capabilities were added that justified the bump in the minor version. A SLAPP implementation that receives a SLAPP message with a lower minor version MUST NOT drop that message. It SHOULD revert back to the minor version which the peer supports and not include any incremental capabilities that were added which justified the bump in the minor version. 4.4 Retransmission SLAPP is a request response protocol. Discovery and security handshake requests are made by the WTP and responses to them are made by the AC. Image download packets are initiated by the AC and acknowledged by the WTP (in a negative fashion, see Section 6). Retransmissions are handled solely by the initiator of the packet. After each packet for which a response is required is transmitted, the sender MUST set a retransmission timer and resend the packet upon its expiry. The receiver MUST be capable of either regenerating a previous response upon receipt of a retransmitted packet or caching a previous response and resending upon receipt of a retransmitted packet. The retransmission timer MUST be configurable and default to one (1) second. No maximum or minimum for the timer is specified by this version of SLAPP. Each time a retransmission is made a counter SHOULD be incremented and the number of retransmissions attempted by a sender before giving up and declaring a SLAPP failure SHOULD be four (4)-- that is, the number of attempts made for each packet before declaring failure is five (5). The exception to this rule is Image Download packets which are not individually acknowledged by the WTP (see Section 6). The final packet is acknowledged and lost packets are indicated through Image Download Requests. 4.5 Discovery When a WTP boots up and wants to interoperate with an Access Controller so that it can be configured by the AC, one of the first things it needs to do is to discover one or more ACs in its network neighborhood. This section contains the details of this discovery mechanism. As described in Section 3, an AC and a WTP could reside in the same layer 2 domain, or be separated by a layer 3 cloud including intermediate clouds that are not under the same administrative domain Narasimhan & Harkins Expires October 2, 2005 [Page 12] Internet-Draft SLAPP March 2005 (for example, an AC and a WTP separated by a wide-area public network). So any proposed discovery mechanism should have provisions to enable a WTP to discover an AC across all these topologies. We assume that a WTP prior to starting the discovery process has already obtained an IP address on its wired segment. 4.5.1 SLAPP Discover Request The SLAPP discovery process is initiated by sending a SLAPP discover request packet. The packet can be addressed to the broadcast IP address, a well known multicast address, or (if the IP address of an AC is either configured prior to the WTP booting up or is learned during the boot-up sequence) addressed to a unicast IP address. Lack of a response to one method of discovery SHOULD result in the WTP trying another method of discovery. The SLAPP discover request packet is a UDP packet addressed to port [TBD] designated as the SLAPP discovery port. The source port can be any random port. The payload of the SLAPP discover request packet is shown in Figure 5. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Maj | Min | Type = 1 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transaction ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | WTP Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | WTP Identifier (continued) | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | WTP Vendor ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | WTP HW Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | WTP SW Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | n controltypes| control type | . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5 4.5.1.1 Transaction ID The transaction ID is a randomly generated 32-bit number that is maintained during one phase of the SLAPP discovery process. It is Narasimhan & Harkins Expires October 2, 2005 [Page 13] Internet-Draft SLAPP March 2005 generated by a WTP starting a discovery process. When one discovery method fails to find an AC and the WTP attempts another discovery method it MUST NOT reuse the Transaction ID. All ACs that intend to respond to a SLAPP discover request must use the same value for this field as in the request frame. 4.5.1.2 WTP Identifier This field allows the WTP to specify a unique identifier for itself. This MAY be, for instance, its 48-bit MAC address or it could be any other string such as a serial number. 4.5.1.3 Flags The flags field is used to indicate certain things about the discover request. For example, bit 0 in the flags field indicates whether the discover request packet is being sent to the AC, if unicast, based on a configuration at the WTP or based on some other means of discovery. This bit should always be set to the discover mode if the SLAPP discover request packet is being sent to either a broadcast or multicast address. Here are the valid values for various bits in the Flags field. Bit 0: 0 - Configuration mode 1 - Discover mode Bits 1-15: Must always be set to 0 by the transmitter Must be ignored by the receiver 4.5.1.4 WTP Vendor ID This 32-bit field is the WTP vendor's SMI enterprise code in network octet order (these enterprise codes can be obtained from, and registered with, IANA). 4.5.1.5 WTP HW Version This 32-bit field indicates the version of hardware present in the WTP. This is a number that is totally left to the WTP vendor to choose. 4.5.1.6 WTP SW Version This 32-bit field indicates the version of software present in the WTP. This is a number that is totally left to the WTP vendor to Narasimhan & Harkins Expires October 2, 2005 [Page 14] Internet-Draft SLAPP March 2005 choose. 4.5.1.7 number of control types This 8-bit field indicates the number of 8-bit control protocol indicators that follow it and therefore implicitly indicates the number of different control protocols the the WTP is capable of supporting. This number MUST be at least one (1). 4.5.1.8 control types This 8-bit field indicates the type of control protocol the WTP supports and is willing to use when communicating with an AC. There MAY be multiple "control type" indicators in a single SLAPP Discover Request. Valid control types ------------------- 0 - RESERVED (MUST not be used) 1 - Image Download Control Protocol 2-255 - RESERVED (to IANA) 4.5.2 SLAPP Discover Response An AC that receives a SLAPP discover request packet from a WTP can choose to respond with a SLAPP discover response packet. The format of the SLAPP discover response packet is shown in Figure 6. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Maj | Min | Type = 2 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transaction ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | WTP Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | WTP Identifier (continued) | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AC HW Vendor ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AC HW Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AC SW Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | control type | +-+-+-+-+-+-+-+-+ Narasimhan & Harkins Expires October 2, 2005 [Page 15] Internet-Draft SLAPP March 2005 Figure 6 The SLAPP discover response packet is a UDP packet. It is always unicast to the WTP's IP address. The source IP address is that of the AC sending the response. The source port is the SLAPP discover port [TBD] and the destination port is the same as the source port used in the SLAPP discover request. The WTP's MAC address and the transaction ID must be identical to the values contained in the SLAPP discover request. The Status field indicates to the WTP whether the AC is either accepting the discover request and is willing to allow the WTP to proceed to the next stage (ACK) or whether it is denying the WTP's earlier request (NACK). The AC includes its own vendor ID, hardware and software versions in the response. 4.5.2.1 Transaction ID The value of the Transaction ID field should be identical to its value in the SLAPP discover request packet sent by the WTP. 4.5.2.2 WTP Identifier The WTP Identifier that was sent in the corresponding SLAPP discover request frame. 4.5.2.3 Flags This field is unused by this version of SLAPP. It MUST be set to zero (0) on transmission and ignored upon receipt. 4.5.2.4 AC Vendor ID If the value of the status field is a 1, indicating that the AC is sending a successful response, then the values in this field and the following two are valid. The 32-bit AC Vendor ID points to the vendor ID of the AC. If the value of the status field is not 1, then this field should be set to 0 by the AC and ignored by the WTP. 4.5.2.5 AC HW Version If the value of the status field is 1, then this 32-bit field contains the value of the AC's hardware version. This value is chosen by the AC vendor. If the value of the status field is not a 1, then this field should be set to 0 by the AC and ignored by the WTP. 4.5.2.6 AC SW Version If the value of the status field is 1, then this 32-bit field Narasimhan & Harkins Expires October 2, 2005 [Page 16] Internet-Draft SLAPP March 2005 contains the value of the AC's software version. This value is chosen by the AC vendor. If the value of the status field is not a 1, then this field should be set to 0 by the AC and ignored by the WTP. 4.5.2.7 Control Type The control type the AC will use to communicate with the WTP. This value MUST match one of the control types passed in the corresponding SLAPP Discover Request. 4.6 SLAPP Discovery Process 4.6.1 WTP There are multiple ways in which a WTP can discover an AC. 1. Static configuration: An administrator, prior to deploying a WTP, can configure an IP address of an AC on the WTP's non-volatile memory. If this is the case, then the SLAPP discover request packet is addressed to the configured IP address. 2. DHCP options: As part of the DHCP response, the DHCP server could be configured to use option 43 to deliver the IP address of an AC to which the WTP should address the SLAPP discover request packet. If the IP address of an AC is handed to the WTP as part of the DHCP response, then the WTP should address the SLAPP discover request packet to this IP address. 3. DNS configuration: Instead of configuring a static IP address on the WTP's non-volatile memory, an administrator can configure a FQDN of an AC. If the FQDN of an AC is configured, then the WTP queries its configured DNS server for the IP address associated with the configured FQDN of the AC. If the DNS query is successful and the WTP acquires the IP address of an AC from the DNS server, then the above discover request packet is addressed to the unicast address of the AC. 4. Broadcast: The WTP sends a discover request packet addressed to the broadcast IP address with the WTP's IP address as the source. A network administrator, if necessary, could configure the default router for the subnet that the WTP is on with a helper address and unicast it to any address on a different subnet. 5. IP Multicast: A WTP can send the above payload to a SLAPP IP multicast address [TBD]. 6. DNS: If there is no DNS FQDN configured on the WTP, and the WTP is unable to discover an AC by any of the above methods, then it should attempt to query the DNS server for a well known FQDN of an AC [TBD]. If this DNS query succeeds, then the WTP should address the SLAPP discover request packet to the unicast address of the AC. Narasimhan & Harkins Expires October 2, 2005 [Page 17] Internet-Draft SLAPP March 2005 The above process is summarized in the sequence shown in Figure 7. SLAPP discovery start: Static IP address config option: Is a static IP address for an AC configured? If yes, send SLAPP discover request to that unicast IP address SLAPP discover response within discovery_timer? If yes, go to "done" If not, go to "Static FQDN config option" If not, go to "Static FQDN config option" Static FQDN config option: Is a static FQDN configured? If yes, send a DNS query for the IP address for the FQDN. Is DNS query successful? If yes, send SLAPP discover request to that IP address SLAPP discover response within discovery timer? If yes, go to "done" If not, go to "DHCP options option" If not, go to "DHCP options option" DHCP options option: Is the IP address of an AC present in the DHCP response? If yes, send SLAPP discover request to the AC's IP addr SLAPP discover response within discovery timer? If yes, go to "done" If not, go to "Broadcast option" If not, go to "Broadcast option" Broadcast option: Send SLAPP discover packet to the broadcast address SLAPP discover response within discovery timer? If yes, go to "done" If not, go to "Multicast option" Multicast option: Send SLAPP discover packet to the SLAPP multicast address SLAPP discover response within discovery timer? If yes, go to "done" If not, go to "DNS discovery option" DNS discovery option: Query the DNS server for a well known DNS name Is the DNS discovery successful? If yes, send SLAPP discover request to that IP addr SLAPP discover response within discovery timer? If yes, go to "done" If not, go to "SLAPP discovery restart" If not, go to "SLAPP discovery restart" SLAPP discovery restart: Set timer for SLAPP discovery idle timer When timer expires, go to "SLAPP discovery start" Narasimhan & Harkins Expires October 2, 2005 [Page 18] Internet-Draft SLAPP March 2005 done: go to the next step Figure 7 4.6.2 AC When an AC receives a SLAPP discover request it must determine whether it wishes to acquire the WTP or not. An AC MAY only agree to acquire those WTPs whose WTP Identifiers are statically configured in its configuration. Or an AC that is willing to gratuitously acquire WTPs MAY accept any request pending authentication. An AC MUST only choose to acquire WTPs that speak a common Negotiated Control protocol but other factors may influence its decision. For instance, if the Negotiated Control Protocol is the Image Download protocol defined in this memo the AC MUST NOT acquire a WTP for which it does not have a compatible image to download as determined by the WTP's HW Vendor ID, HW Version and Software Version. Whatever its decision, the AC MUST respond one of two ways. 1. The AC sends a SLAPP discover response indicating its agreement to acquire the WTP. 2. The AC silently drops the SLAPP discover request and does not respond at all. Narasimhan & Harkins Expires October 2, 2005 [Page 19] Internet-Draft SLAPP March 2005 5. Security Association Once an AC has been discovered by a WTP and agreed to acquire it (by sending a Discovery Response) it will initiate a DTLS [5] exchange with the WTP by assuming the role of the "client". The WTP assumes the role of the "server". The port used by both the WTP and AC for this exchange will be [TBD]. An obvious question is "why is the AC acting as a client?" The reason is to allow for non-mutual authentication in which the WTP is authenticated by the AC (see Section 5.1.2). Informational note: DTLS is used because it provides a secure and connectionless channel using a widely accepted and analyzed protocol. In addition, 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 and certificate based; asymmetric or non-mutual authentication; anonymous authentication; etc. Furthermore, DTLS defines its own fragmentation and reassembly techniques as well as ways in which peers agree on an effective MTU. Using DTLS obviates the need to redefine these aspects of a protocol and therefore lessens code bloat as the same problem doesn't need to be solved yet again in another place. Failure of the DTLS handshake protocol will cause both parties to abandon the exchange. The AC SHOULD blacklist this WTP for a period of time to prevent a misconfigured WTP from repeatedly discovering and failing authentication. The WTP MUST return to the discovery state of SLAPP to locate another suitable AC with which it will initiate a DTLS exchange. Once the DTLS handshake has succeeded the WTP and AP transition into "image download state" and protect all further SLAPP messages with the DTLS-negotiated cipher suite. 5.1 Example Authentication Models (Informative) Any valid cipher suite in [6] can be used to authenticate the WTP and/or the AC. Different scenarios require different authentication models. The following examples are illustrative only and not meant to be exhaustive. Since neither side typically involves a human being a username/password based authentication is not possible. Zero-config requirements on certain WTP deployments can predicate certain authentication options and eliminate others. Narasimhan & Harkins Expires October 2, 2005 [Page 20] Internet-Draft SLAPP March 2005 5.1.1 Mutual Authentication When mutually authenticating, the WTP authenticates the AC, thereby ensuring that the AC to which it is connecting is a trusted AC, and the AC authenticates the WTP, thereby ensuring that the WTP that is connecting is a trusted WTP. Mutual authentication is typically achieved by using certificates on the WTP and AC which ensure public keys each party owns. These certificates are digitally signed by a Certification Authority, a trusted third party. Enrolling each WTP in a Certification Authority is outside the scope of this document but it should be noted that a manufacturing Certification Authority does not necessarily provide the level of assurance necessary as it will only guarantee that a WTP or AC was manufactured by a particular company and cannot distinguish between a trusted WTP and a WTP which is not trusted but was purchased from the same manufacturer as the AC. 5.1.2 WTP-only Authentication Some deployments may only require the WTP to authenticate to the AC and not the other way around. In this case the WTP has a keypair which can uniquely identify it (for example, using a certificate) and that keypair is used in a "server-side authentication" [6] exchange. This authentication model does not authenticate the AC and a rogue AC could assert control of a valid WTP. It should be noted, though, that this will only allow the WTP to provide service for networks made available by the rogue AC. No unauthorized network access is possible. 5.1.3 Anonymous Authentication In some deployments it MAY just be necessary to foil the casual snooping of packets. In this case an unauthenticated, but encrypted, connection can suffice. Typically a Diffie-Hellman exchange is performed between the AC and WTP and the resulting unauthenticated key is used to encrypt traffic between the AC and WTP. Narasimhan & Harkins Expires October 2, 2005 [Page 21] Internet-Draft SLAPP March 2005 6. Image Download Protocol The Image Download protocol is an extension to SLAPP that is generic enough that it is agnostic to the underlying technology. In the image download protocol, the WTP obtains a bootable image from the AC by receiving a series of image transfer packets. Missed image data packets are re-requested by the WTP by sending image data request packets indicating the missing packets. The image to download is divided into slices of equal size (except for the last slice which can be less than the slice size provided it is also greater than zero). The size of each slice depends on the MTU determined by the DTLS exchange and SHOULD be the realized MTU minus the size of an Image Download Request (Figure 9). Note that the image download packet and download image request is encapsulated in a DTLS header which secures the image download. 6.1 Image Download Packet The format of an image download packet is shown in Figure 8. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Maj | Min | Type = 3 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RESERVED |M|R| packet sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ image data slice ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8 where: length: variable RESERVED: unused in this version of SLAPP, MUST be zero (0) on transmission and ignored upon receipt M: the "More" bit indicating that the current packet is not the final one R: the "Request" bit. This bit MUST be set to one (1) when the packet is the response to a request and zero (0) otherwise. packet sequence number: a monotonically increasing counter which assigns a unique number to each slice of the image Narasimhan & Harkins Expires October 2, 2005 [Page 22] Internet-Draft SLAPP March 2005 image data slice: a portion of the bootable image. 6.2 Image Download Request The format of an image download request is show in Figure 9. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Maj | Min | Type = 3 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RESERVED |M|R| packet sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9 where: length: eight (8) octets RESERVED: unused in this version of SLAPP, MUST be zero on transmission and ignored upon receipt M: the "More" bit. This MUST be equal to the one (1) when negatively acknowledging a missed packet and set to zero (0) when indicating the end of the Image Download protocol. R: the "Request" bit. This MUST be one in an Image Download Request. packet sequence number: the packet sequence number of the missing image data slice. 6.3 Image Download Process The AC will divides the bootable image into a series of slices and sends each slice as an Image Download packet. The size of each image data slice (and therefore the size of each image download packet) depends on the MTU of the connection determined during the DTLS handshake. With the transmission of each slice the AC MUST increment the packet sequence number. Image Download packets are negatively ack'd. An AC MUST NOT assume anything about the reception of packets it sends based upon negative acks. One could naively assume that since the packets are sent sequentially that all packets with a sequence number of "n - 1" are implicitly ack'd by the receipt of a request for the packet with sequence number "n" to be retransmitted. Such an assumption would be incorrect since previous requests could, themselves, have been dropped. The image download process is initiated by the WTP requesting a packet with the packet sequence number of zero (0). The AC sets the packet sequence counter for this WTP to one (1) and sends the first Narasimhan & Harkins Expires October 2, 2005 [Page 23] Internet-Draft SLAPP March 2005 slice. The "Request" bit for the first slice sent by the AC MUST be set to zero (0) since the first slice was technically not requested. The WTP sets a periodic timer that, when it fires, causes the WTP to sends Image Download requests for slices that have been missed since the last periodic timer had fired. Since individual Image Download packets are not ack'd the AC MUST NOT set a timer when each one is sent. If a WTP notices missed image transfer packets-- when the difference between the packet sequence number of a received image transfer packet and the packet sequence number of the last image transfer packet previously received is greater than one-- it will note that fact in a bitmask. When the periodic timer fires the WTP will request the slices that are absent from that bitmask. Each slice will be requested by sending a Download Request with a length of eight (8) and indicating the sequence number of the packet requested. The AC MUST interleave these retransmissions with packets in the sequence. Since both sides implicitly agree upon the MTU of the link the WTP will know the slice size that the AC will use during the Image Download process. A dropped packet will therefore result in an internal buffer pointer on the WTP being incremented by the slice size and the lost packet requested. When the lost packet is received it can be inserted into the buffer in the space provided by the pointer increment when its loss was first detected. That is, loss of packet will result in packet being re-requested and when received inserted into the buffer at an offset of * from the start of the buffer. The final packet sent by the AC will not have the "more" bit set and this indicates to the WTP that the end of the image has been received. This final packet is acknowledged by the WTP indicating the end of the Image Download process. A lost final packet will result in the AC resending the final packet again (see Section 4.4). 6.4 Image Download State Machine The Image Download protocol is a negotiated control protocol defined for SLAPP. Transitions to it come from the "secure" state and transitions out of it go to "acquire". See Figure 3. 6.4.1 AC The AC's state machine for the Image Download protocol is shown in Narasimhan & Harkins Expires October 2, 2005 [Page 24] Internet-Draft SLAPP March 2005 Figure 10. The AC maintains the following variables for its state machine: seq_num: the current slice that is being sent nslices: the total number of slices in the image req_num: the number of the slice that was requested more: whether the "More bit" in the packet should be set starved: a timer which sets the maximum amount of time in which an AC will attempt to download an image. Note: the symbol "C" indicates an event in a state which results in the state remaining the same. | v +----------+ | waiting | +----------+ | | seq_num = 1, more = 1, | nslices = x, starved = t M bit v +----------+ is 0 +-------------+ | finished |<-------| received |<------\ +----------+ | |<----\ | +-------------+ | | req_num = requested | | | packet | M bit is 1 | | V | | +----------+ | | seq_num++, C| sending |------/ | req_num=0 +----------+ | | | | | | +-------------+ | | | | discovering |<----/ | | | |<----\ | | +-------------+ | | | | v v +--------+ | | idle |---------/ +--------+ Figure 10 The following states are defined: Narasimhan & Harkins Expires October 2, 2005 [Page 25] Internet-Draft SLAPP March 2005 Waiting: When the AC leaves the SLAPP state of "Secure" it enters the "Waiting" state of the Image Download protocol. seq_num is set to one (1), more is set to one (1), and nslices is set to the number of slices in the particular image to download, and starved is set to the maximum amount of time the AC will devote to downloading a particular image. Received: The AC enters this state when it has received an Image Download request. If the sequence number of the packet is zero (0) it sets seq_num to one (1) and transitions to Sending, else if the M bit is set it sets req_num to the sequence number of the request and transitions to Sending else (if the M bit is clear) it transitions to Finished. Sending: The AC is sending a slice to the WTP. If req_num is equal to zero (0) it sends the slice indicated by seq_num and increments seq_num. If req_num is greater than zero (0) it sends the slice indicated by req_num and sets req_num to zero (0). The "More" bit in either case is set depending on the value of more. As long as no request packets are received Sending transitions to Sending. When seq_num equals nslices "More" is set to zero (0) and the state transitions to Idle. If the starved timer expires the AC transitions to the SLAPP state of Discovering. Idle: The AC has sent all the slices in the image and is just waiting for requests. If the starved timer expires the AC transitions to the SLAPP state of Discovering. Finished: The Image Download protocol has terminated. The starved timer is canceled. 6.4.2 WTP The WTP's state machine for the Image Download protocol is shown in Figure 11. The WTP maintains the following variables for its state machine: recv_num: the sequence number of the last received slice req: a bitmask whose length equals the number of slices in the image retry: a timer giveup: a timer final: the sequence number of the last slice Note: the symbol "C" indicates an event in a state which results in the state remaining the same. Narasimhan & Harkins Expires October 2, 2005 [Page 26] Internet-Draft SLAPP March 2005 | v +----------+ | init | recv_num = 0, +----------+ final = 0, req = 0, | giveup = t v +----------+ +-----------+ | finished |<------- | sending |<-------\ +----------+ +-----------+ | | | retry fires v | +--------------+ | bit in req = C| receiving |------/ seq_num in packet +--------------+ is set | | giveup fires v +-------------+ | discovering | +-------------+ Figure 11 The following states are defined: Init: When the WTP leaves the SLAPP state of "Secure" it enters the "Init" state of the Image Download Protocol. recv_num, final, and the req bitmask are set to zero (0), and the giveup timer is set to a suitably large number. The WTP transitions directly to Sending. Sending: If recv_num is zero (0) the WTP sends a request for a packet with sequence number of zero (0) and the "More" bit set to one (1). Otherwise for every unset bit in req between one (1) and recv_num a request packet is sent with the sequence number corresponding to the unset bit in req and the "More" bit set to more. If there are no unset bits in req and final is non-zero a request packet is sent for the sequence number represented by final with the "More" bit cleared, giveup is cleared and the state machine transitions to Finished. Otherwise retry is set to a suitable value and the WTP transitions to Receiving. Receiving: In this state the WTP receives Image Download packets. The bit in req corresponding to the sequence number in the received packet is set indicating this packet has been received. If the sequence number of the received packet has already been received the packet is silently dropped, otherwise the data in the packet is stored as Narasimhan & Harkins Expires October 2, 2005 [Page 27] Internet-Draft SLAPP March 2005 the indicated slice in a file which represents the downloaded image. If the received packet has the "More" bit cleared final is set to the sequence number in that packet. When the retry timer fires the WTP transitions to Sending. If the giveup timer fires the WTP transitions to the SLAPP state of Discovering. Finished: The image download protocol has finished. Narasimhan & Harkins Expires October 2, 2005 [Page 28] Internet-Draft SLAPP March 2005 7. Security Considerations This document describes a protocol, SLAPP, which uses a different protocol, DTLS, to provide for authentication, key exchange, and bulk data encryption of a negotiated control protocol. It's security considerations are therefore those of DTLS. The AC creates state upon receipt of an acceptable Discovery Request. AC implementations of SLAPP SHOULD therefore take measures to protect themselves from denial of service attacks which attempt to exhaust resources on target machines. These measures could take the form of randomly dropping connections when the number of open connections reaches a certain threshold. The WTP exposes information about itself during the discovery phase. Some of this information could not be gleaned by other means. Narasimhan & Harkins Expires October 2, 2005 [Page 29] Internet-Draft SLAPP March 2005 8. Extensibility to other technologies The SLAPP protocol can be considered to be a technology-independent protocol that can be extended with technology-specific components to solve an interoperability problem where a central controller from one vendor is expected to control and manage network elements from a different vendor. While the description of the SLAPP protocol in this draft assumes that it is meant to solve the multi-vendor interoperability problem as defined in the CAPWAP problem statement [3], splitting the solution to two components where technology-dependent extensions are combined with a technology-independent framework enables the use of SLAPP as the common framework for multiple underlying technologies that are vastly different from one another. 9. References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", March 1997, . [2] "Architecture Taxonomy for Control and Provisioning of Wireless Access Points(CAPWAP)", August 2004, . [3] "Configuration and Provisioning for Wireless Access Points (CAPWAP) Problem Statement", February 2005, . [4] Govindan, S., "Objectives for Control and Provisioning of Wireless Access Points (CAPWAP)", November 2004, . [5] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", February 2004, . [6] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999, . [7] Krishna, P. and D. Husak, "Simple Lightweight RFID Reader Protocol", March 2005, . Narasimhan & Harkins Expires October 2, 2005 [Page 30] Internet-Draft SLAPP 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 Narasimhan & Harkins Expires October 2, 2005 [Page 31] Internet-Draft SLAPP March 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 & Harkins Expires October 2, 2005 [Page 32]