RFC 5413
SLAPP: Secure Light Access Point Protocol
Pages: 75
Historic
Historic
Part 1 of 3 – Pages 1 to 21
Independent Submission P. Narasimhan Request for Comments: 5413 D. Harkins Category: Historic S. Ponnuswamy ISSN: 2070-1721 Aruba Networks February 2010 SLAPP: Secure Light Access Point ProtocolAbstract
The Control and Provisioning of Wireless Access Points (CAPWAP) problem statement 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 between the two classes of devices (WTPs and ACs) that then enables an AC from one vendor to control and manage a WTP from another. In this document, we present a protocol that forms the common technology-independent framework and the ability to negotiate and add, on top of this framework, a control protocol that contains a technology-dependent component to arrive at a complete solution. We have also presented two such control protocols -- an 802.11 Control protocol, and another, more generic image download protocol, in this document. Even though the text in this document is written to specifically address the problem stated in RFC 3990, 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). Status of This Memo This document is not an Internet Standards Track specification; it is published for the historical record. This document defines a Historic Document for the Internet community. This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5413. IESG Note This RFC documents the SLAPP protocol as it was when submitted to the IETF as a basis for further work in the CAPWAP Working Group, and therefore it may resemble the CAPWAP protocol specification in RFC 5415 as well as other IETF work. This RFC is being published solely for the historical record. The protocol described in this RFC has not been thoroughly reviewed and may contain errors and omissions. RFC 5415 documents the standards track solution for the CAPWAP Working Group and obsoletes any and all mechanisms defined in this RFC. This RFC is not a candidate for any level of Internet Standard and should not be used as a basis for any sort of Internet deployment. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http//:trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
Table of Contents
1. Introduction ....................................................4 2. Definitions .....................................................7 2.1. Conventions Used in This Document ..........................7 3. Topology ........................................................7 4. Protocol ........................................................8 4.1. Protocol Description .......................................8 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 ...........................................19 5.1. Example Authentication Models (Informative) ...............20 5.1.1. Mutual Authentication ..............................20 5.1.2. WTP-Only Authentication ............................21 5.1.3. Anonymous Authentication ...........................21 6. SLAPP Control Protocols ........................................21 6.1. 802.11 Control Protocol for SLAPP .........................21 6.1.1. Supported CAPWAP Architectures .....................21 6.1.2. Transport ..........................................24 6.1.3. Provisioning and Configuration of WTP ..............26 6.1.4. Protocol Operation .................................60 6.2. Image Download Protocol ...................................66 6.2.1. Image Download Packet ..............................66 6.2.2. Image Download Request .............................67 6.2.3. Image Download Process .............................68 6.2.4. Image Download State Machine .......................69 7. Security Considerations ........................................73 8. Extensibility to Other Technologies ............................73 9. Informative References .........................................74
1. Introduction
The need for a protocol by which wireless LAN (WLAN) Access Controllers (ACs) can control and manage Wireless Termination Points (WTPs) 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 configurable options, and different architectural choices that are specific to that underlying technology (similar to the Local Medium Access Control (MAC) versus 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 to 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 a control protocol that would be negotiated using 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 solution as new technologies arise or as new innovative methods to solve the same problem for an existing technology present themselves in the future. In this document, 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 a control protocol that they would use to perform the technology-specific components of the control and provisioning protocol. We have also presented two control protocols in this document -- an 802.11 control protocol for provisioning and managing a set of 802.11 WTPs, and an image download protocol that is very generic and can be applied to any underlying technology. Figure 1 shows the model by which a technology-specific control protocol can be negotiated using SLAPP to complete a solution for a certain underlying technology. The figure shows a control protocol for 802.11 and 802.16 technology components, but the SLAPP model does not preclude multiple control protocols within a certain technology segment. For example, a certain technology-specific control protocol 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 document, a SLAPP implementation MUST NOT assume that this control protocol is supported by other SLAPP implementations.
Negotiated SLAPP Control Protocol +-------------------------+ +------------+ | | | | | SLAPP | | Image | | (technology-independent +-------+----->| Download | | framework) | | | protocol | | | | | | | negotiate one control | | +------------+ | protocol here | | +-------------------------+ | | +------------+ | | | | | 802.11 | +----->| control | | | protocol | | | | | +------------+ | | | +------------+ | | | | | 802.16 | +----->| control | | | protocol | | | | | +------------+ | | ....... Figure 1: SLAPP Protocol Model The control protocols that are negotiable using SLAPP are expected to be published ones that have gone through a review process in standards bodies such as the IETF. The control protocols can either re-use the security association created during SLAPP or have the option of clearing all SLAPP state and restarting with whatever mechanisms are defined in the control protocol. Recently, there was a significant amount of interest in a similar problem in the Radio Frequency Identification (RFID) space that has led to the definition of a simple lightweight RFID reader protocol (SLRRP) [9]. It is quite possible that SLRRP could be a technology-specific (RFID, in this case) control protocol negotiated during a common technology-independent framework.
All of the text in the document would seem to be written with a WLAN problem in mind. Please note that while the letter of the document does position the solution to solve a CAPWAP-specific problem, the spirit of the document is to address the more general problem.2. Definitions
2.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].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 Ethernet, 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 Layer 2 (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.
+-----------------+ +-------+ | | (1) | | | AC +------------+ WTP | | | | | +--------+--------+ +-------+ | | | +---+---+ (2) | | +------+ L2 +--------+ | | | | | +---+---+ | | | | | +-----+-----+ +---+---+ +-------+ | | | | (3)| | | WTP | | L3 +----+ WTP | | | | | | | +-----------+ +---+---+ +-------+ | | | +---+----+ +-------+ | | (4)| | |Internet+----+ WTP | | | | | +--------+ +-------+ Figure 2: SLAPP Topology4. 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 that sets the maximum amount of time the WTP will wait for an acquired AC to begin the Datagram Transport Layer Security (DTLS) handshake.
/--------\ /-----------\ | | | | | v v | | +-------------+ | | C| discovering |<-\ | | +-------------+ | | | | | | | v | | | +-----------+ | | \--| acquiring | | | +-----------+ | | | | | v | | +----------+ | | C| securing |-----/ | +----------+ | | | v | +----------------+ | | negotiated | | C| control |-----/ | protocol | +----------------+ Figure 3: SLAPP State Machine4.1.1. State Machine Explanation
Note: The symbol "C" indicates an event that results in the state remaining the same. 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 Discover 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 Discover 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 the 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. Please refer to Section 6.1 for the SLAPP
802.11 Control Protocol. For the Image Download Protocol
example, see Section 6.2.
WTP: The WTP performs its side of the protocol agreed to during the
discovery process. Please refer to Section 6.1 for the SLAPP
802.11 Control Protocol. For the Image Download Protocol
example, see Section 6.2.
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: SLAPP Header
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
----- ------
discover request 1
discover response 2
image download control 3
control protocol packet 4
reserved 5-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. However, there
may be valid reasons for which a peer wishes to drop a SLAPP message
with a supported major version.
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
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 that the peer supports and not include any incremental capabilities that were added that 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.2). 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.2). 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
(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: SLAPP Discover Request4.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 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 re-use 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 receiver4.5.1.4. WTP Vendor ID
This 32-bit field is the WTP vendor's Structure of Management Information (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 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 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 - 802.11 SLAPP Control Protocol 3-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 | +-+-+-+-+-+-+-+-+ Figure 6: SLAPP Discover Response
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 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 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 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 that 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 Fully-Qualified Domain Name (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.
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 address 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 address 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" done: Go to the next step Figure 74.6.2. AC
When an AC receives a SLAPP discover request, it must determine whether or not it wishes to acquire the WTP. 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.5. Security Association
Once an AC has been discovered by a WTP and agreed to acquire it (by sending a Discover Response), it will initiate a DTLS [6] [8] 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 [7] 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.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 that 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 that can uniquely identify it (for example, using a certificate) and, that keypair is used in a "server-side authentication" [7] 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.
(page 21 continued on part 2)