draft-ietf-capwap-protocol-specification-09.txt   draft-ietf-capwap-protocol-specification-10.txt 
Network Working Group P. Calhoun, Editor Network Working Group P. Calhoun, Editor
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Expires: August 24, 2008 M. Montemurro, Editor Expires: September 14, 2008 M. Montemurro, Editor
Research In Motion Research In Motion
D. Stanley, Editor D. Stanley, Editor
Aruba Networks Aruba Networks
February 21, 2008 March 13, 2008
CAPWAP Protocol Specification CAPWAP Protocol Specification
draft-ietf-capwap-protocol-specification-09 draft-ietf-capwap-protocol-specification-10
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 37 skipping to change at page 1, line 37
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 24, 2008. This Internet-Draft will expire on September 14, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract Abstract
This specification defines the Control And Provisioning of Wireless This specification defines the Control And Provisioning of Wireless
Access Points (CAPWAP) Protocol. The CAPWAP protocol meets the IETF Access Points (CAPWAP) Protocol. The CAPWAP protocol meets the IETF
CAPWAP working group protocol requirements. The CAPWAP protocol is CAPWAP working group protocol requirements. The CAPWAP protocol is
designed to be flexible, allowing it to be used for a variety of designed to be flexible, allowing it to be used for a variety of
wireless technologies. This document describes the base CAPWAP wireless technologies. This document describes the base CAPWAP
protocol. The CAPWAP protocol binding which defines extensions for protocol. The CAPWAP protocol binding which defines extensions for
use with the IEEE 802.11 wireless LAN protocol is available in [16]. use with the IEEE 802.11 wireless LAN protocol is available in
Extensions are expected to be defined to enable use of the CAPWAP [I-D.ietf-capwap-protocol-binding-ieee80211]. Extensions are
protocol with additional wireless technologies. expected to be defined to enable use of the CAPWAP protocol with
additional wireless technologies.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7
1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.2. Conventions used in this document . . . . . . . . . . . . 8 1.2. Conventions used in this document . . . . . . . . . . . . 9
1.3. Contributing Authors . . . . . . . . . . . . . . . . . . 9 1.3. Contributing Authors . . . . . . . . . . . . . . . . . . 9
1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 10 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 10
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 12 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 12
2.1. Wireless Binding Definition . . . . . . . . . . . . . . . 13 2.1. Wireless Binding Definition . . . . . . . . . . . . . . . 13
2.2. CAPWAP Session Establishment Overview . . . . . . . . . . 14 2.2. CAPWAP Session Establishment Overview . . . . . . . . . . 14
2.3. CAPWAP State Machine Definition . . . . . . . . . . . . . 16 2.3. CAPWAP State Machine Definition . . . . . . . . . . . . . 16
2.3.1. CAPWAP Protocol State Transitions . . . . . . . . . . 18 2.3.1. CAPWAP Protocol State Transitions . . . . . . . . . . 18
2.3.2. CAPWAP/DTLS Interface . . . . . . . . . . . . . . . . 31 2.3.2. CAPWAP/DTLS Interface . . . . . . . . . . . . . . . . 31
2.4. Use of DTLS in the CAPWAP Protocol . . . . . . . . . . . 33 2.4. Use of DTLS in the CAPWAP Protocol . . . . . . . . . . . 33
2.4.1. DTLS Handshake Processing . . . . . . . . . . . . . . 33 2.4.1. DTLS Handshake Processing . . . . . . . . . . . . . . 33
skipping to change at page 5, line 47 skipping to change at page 5, line 48
12. Security Considerations . . . . . . . . . . . . . . . . . . . 131 12. Security Considerations . . . . . . . . . . . . . . . . . . . 131
12.1. CAPWAP Security . . . . . . . . . . . . . . . . . . . . . 131 12.1. CAPWAP Security . . . . . . . . . . . . . . . . . . . . . 131
12.1.1. Converting Protected Data into Unprotected Data . . . 132 12.1.1. Converting Protected Data into Unprotected Data . . . 132
12.1.2. Converting Unprotected Data into Protected Data 12.1.2. Converting Unprotected Data into Protected Data
(Insertion) . . . . . . . . . . . . . . . . . . . . . 132 (Insertion) . . . . . . . . . . . . . . . . . . . . . 132
12.1.3. Deletion of Protected Records . . . . . . . . . . . . 132 12.1.3. Deletion of Protected Records . . . . . . . . . . . . 132
12.1.4. Insertion of Unprotected Records . . . . . . . . . . 132 12.1.4. Insertion of Unprotected Records . . . . . . . . . . 132
12.2. Session ID Security . . . . . . . . . . . . . . . . . . . 132 12.2. Session ID Security . . . . . . . . . . . . . . . . . . . 132
12.3. Discovery or DTLS Setup Attacks . . . . . . . . . . . . . 133 12.3. Discovery or DTLS Setup Attacks . . . . . . . . . . . . . 133
12.4. Interference with a DTLS Session . . . . . . . . . . . . 134 12.4. Interference with a DTLS Session . . . . . . . . . . . . 134
12.5. Use of Preshared Keys in CAPWAP . . . . . . . . . . . . . 134 12.5. CAPWAP Pre-Provisioning . . . . . . . . . . . . . . . . . 134
12.6. Use of Certificates in CAPWAP . . . . . . . . . . . . . . 135 12.6. Use of Preshared Keys in CAPWAP . . . . . . . . . . . . . 135
12.7. AAA Security . . . . . . . . . . . . . . . . . . . . . . 136 12.7. Use of Certificates in CAPWAP . . . . . . . . . . . . . . 136
13. Management Considerations . . . . . . . . . . . . . . . . . . 137 12.8. AAA Security . . . . . . . . . . . . . . . . . . . . . . 137
14. Transport Considerations . . . . . . . . . . . . . . . . . . 138 13. Management Considerations . . . . . . . . . . . . . . . . . . 138
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 139 14. Transport Considerations . . . . . . . . . . . . . . . . . . 139
15.1. CAPWAP Message Types . . . . . . . . . . . . . . . . . . 139 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 140
15.2. Wireless Binding Identifiers . . . . . . . . . . . . . . 139 15.1. CAPWAP Message Types . . . . . . . . . . . . . . . . . . 140
16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 140 15.2. Wireless Binding Identifiers . . . . . . . . . . . . . . 140
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 141 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 141
17.1. Normative References . . . . . . . . . . . . . . . . . . 141 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 142
17.2. Informational References . . . . . . . . . . . . . . . . 142 17.1. Normative References . . . . . . . . . . . . . . . . . . 142
Editors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 143 17.2. Informational References . . . . . . . . . . . . . . . . 143
Intellectual Property and Copyright Statements . . . . . . . . . 144 Editors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 144
Intellectual Property and Copyright Statements . . . . . . . . . 145
1. Introduction 1. Introduction
This document describes the CAPWAP Protocol, a standard, This document describes the CAPWAP Protocol, a standard,
interoperable protocol which enables an Access Controller (AC) to interoperable protocol which enables an Access Controller (AC) to
manage a collection of Wireless Termination Points (WTPs). The manage a collection of Wireless Termination Points (WTPs). The
CAPWAP protocol is defined to be independent of layer 2 technology. CAPWAP protocol is defined to be independent of layer 2 technology.
The emergence of centralized IEEE 802.11 Wireless Local Area Network The emergence of centralized IEEE 802.11 Wireless Local Area Network
(WLAN) architectures, in which simple IEEE 802.11 WTPs are managed by (WLAN) architectures, in which simple IEEE 802.11 WTPs are managed by
an Access Controller (AC) suggested that a standards based, an Access Controller (AC) suggested that a standards based,
interoperable protocol could radically simplify the deployment and interoperable protocol could radically simplify the deployment and
management of wireless networks. WTPs require a set of dynamic management of wireless networks. WTPs require a set of dynamic
management and control functions related to their primary task of management and control functions related to their primary task of
connecting the wireless and wired mediums. Traditional protocols for connecting the wireless and wired mediums. Traditional protocols for
managing WTPs are either manual static configuration via HTTP, managing WTPs are either manual static configuration via HTTP,
proprietary Layer 2 specific or non-existent (if the WTPs are self- proprietary Layer 2 specific or non-existent (if the WTPs are self-
contained). An IEEE 802.11 binding is defined in [16] to support use contained). An IEEE 802.11 binding is defined in
of the CAPWAP protocol with IEEE 802.11 WLAN networks. [I-D.ietf-capwap-protocol-binding-ieee80211] to support use of the
CAPWAP protocol with IEEE 802.11 WLAN networks.
CAPWAP assumes a network configuration consisting of multiple WTPs CAPWAP assumes a network configuration consisting of multiple WTPs
communicating via the Internet Protocol (IP) to an AC. WTPs are communicating via the Internet Protocol (IP) to an AC. WTPs are
viewed as remote RF interfaces controlled by the AC. The CAPWAP viewed as remote RF interfaces controlled by the AC. The CAPWAP
protocol supports two modes of operation: Split and Local MAC. In protocol supports two modes of operation: Split and Local MAC. In
Split MAC mode all L2 wireless data and management frames are Split MAC mode all L2 wireless data and management frames are
encapsulated via the CAPWAP protocol and exchanged between the AC and encapsulated via the CAPWAP protocol and exchanged between the AC and
the WTP. As shown in Figure 1, the wireless frames received from a the WTP. As shown in Figure 1, the wireless frames received from a
mobile device, which is referred to in this specification as a mobile device, which is referred to in this specification as a
Station (STA), are directly encapsulated by the WTP and forwarded to Station (STA), are directly encapsulated by the WTP and forwarded to
skipping to change at page 7, line 48 skipping to change at page 7, line 49
| |--------------| |---------------| | | |--------------| |---------------| |
| |wireless PHY/ | | CAPWAP | | | |wireless PHY/ | | CAPWAP | |
| | MAC sublayer | | | | | | MAC sublayer | | | |
+-+ +-+ +-+ +-+ +-+ +-+
STA WTP AC STA WTP AC
Figure 1: Representative CAPWAP Architecture for Split MAC Figure 1: Representative CAPWAP Architecture for Split MAC
The Local MAC mode of operation allows for the data frames to be The Local MAC mode of operation allows for the data frames to be
either locally bridged, or tunneled as 802.3 frames. The latter either locally bridged, or tunneled as 802.3 frames. The latter
implies that the WTP performs the 802 bridging function. In either implies that the WTP performs the 802.11 Integration function. In
case the L2 wireless management frames are processed locally by the either case the L2 wireless management frames are processed locally
WTP, and then forwarded to the AC. Figure 2 shows the Local MAC by the WTP, and then forwarded to the AC. Figure 2 shows the Local
mode, in which a station transmits a wireless frame which is MAC mode, in which a station transmits a wireless frame which is
encapsulated in an 802.3 frame and forwarded to the AC. encapsulated in an 802.3 frame and forwarded to the AC.
+-+wireless frames +-+ 802.3 frames +-+ +-+wireless frames +-+ 802.3 frames +-+
| |----------------| |--------------| | | |----------------| |--------------| |
| | | | | | | | | | | |
| |----------------| |--------------| | | |----------------| |--------------| |
| |wireless PHY/ | | CAPWAP | | | |wireless PHY/ | | CAPWAP | |
| | MAC sublayer | | | | | | MAC sublayer | | | |
+-+ +-+ +-+ +-+ +-+ +-+
STA WTP AC STA WTP AC
skipping to change at page 8, line 52 skipping to change at page 9, line 9
types in the future, via a specific wireless binding. types in the future, via a specific wireless binding.
The CAPWAP protocol concerns itself solely with the interface between The CAPWAP protocol concerns itself solely with the interface between
the WTP and the AC. Inter-AC and station-to AC-communication are the WTP and the AC. Inter-AC and station-to AC-communication are
strictly outside the scope of this document. strictly outside the scope of this document.
1.2. Conventions used in this document 1.2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1]. document are to be interpreted as described in RFC 2119 [RFC2119].
1.3. Contributing Authors 1.3. Contributing Authors
This section lists and acknowledges the authors of significant text This section lists and acknowledges the authors of significant text
and concepts included in this specification. and concepts included in this specification.
The CAPWAP Working Group selected the Lightweight Access Point The CAPWAP Working Group selected the Lightweight Access Point
Protocol (LWAPP) [add reference, when available] to be used as the Protocol (LWAPP) [add reference, when available] to be used as the
basis of the CAPWAP protocol specification. The following people are basis of the CAPWAP protocol specification. The following people are
authors of the LWAPP document: authors of the LWAPP document:
skipping to change at page 11, line 10 skipping to change at page 11, line 17
transport-layer protocol (UDP or UDP-Lite) over which CAPWAP data transport-layer protocol (UDP or UDP-Lite) over which CAPWAP data
packets are sent and received. packets are sent and received.
Station (STA): A device that contains an interface to a wireless Station (STA): A device that contains an interface to a wireless
medium (WM). medium (WM).
Wireless Termination Point (WTP): The physical or network entity that Wireless Termination Point (WTP): The physical or network entity that
contains an RF antenna and wireless PHY to transmit and receive contains an RF antenna and wireless PHY to transmit and receive
station traffic for wireless access networks. station traffic for wireless access networks.
This document uses additional terminology defined in [19]. This document uses additional terminology defined in [RFC3753].
2. Protocol Overview 2. Protocol Overview
The CAPWAP protocol is a generic protocol defining AC and WTP control The CAPWAP protocol is a generic protocol defining AC and WTP control
and data plane communication via a CAPWAP protocol transport and data plane communication via a CAPWAP protocol transport
mechanism. CAPWAP control messages, and optionally CAPWAP data mechanism. CAPWAP control messages, and optionally CAPWAP data
messages, are secured using Datagram Transport Layer Security (DTLS) messages, are secured using Datagram Transport Layer Security (DTLS)
[7]. DTLS is a standards-track IETF protocol based upon TLS. The [RFC4346]. DTLS is a standards-track IETF protocol based upon TLS.
underlying security-related protocol mechanisms of TLS have been The underlying security-related protocol mechanisms of TLS have been
successfully deployed for many years. successfully deployed for many years.
The CAPWAP protocol Transport layer carries two types of payload, The CAPWAP protocol Transport layer carries two types of payload,
CAPWAP Data messages and CAPWAP Control messages. CAPWAP Data CAPWAP Data messages and CAPWAP Control messages. CAPWAP Data
messages encapsulate forwarded wireless frames. CAPWAP protocol messages encapsulate forwarded wireless frames. CAPWAP protocol
Control messages are management messages exchanged between a WTP and Control messages are management messages exchanged between a WTP and
an AC. The CAPWAP Data and Control packets are sent over separate an AC. The CAPWAP Data and Control packets are sent over separate
UDP ports. Since both data and control packets can exceed the UDP ports. Since both data and control packets can exceed the
Maximum Transmission Unit (MTU) length, the payload of a CAPWAP data Maximum Transmission Unit (MTU) length, the payload of a CAPWAP data
or control message can be fragmented. The fragmentation behavior is or control message can be fragmented. The fragmentation behavior is
skipping to change at page 13, line 43 skipping to change at page 13, line 43
Primary Discovery and Join Request and Response messages, Primary Discovery and Join Request and Response messages,
indicating the binding specific radio types supported at the WTP indicating the binding specific radio types supported at the WTP
and AC. and AC.
If technology specific message elements are required for any of the If technology specific message elements are required for any of the
existing CAPWAP messages defined in this specification, they MUST existing CAPWAP messages defined in this specification, they MUST
also be defined in the technology binding document. also be defined in the technology binding document.
The naming of binding-specific message elements MUST begin with the The naming of binding-specific message elements MUST begin with the
name of the technology type, e.g., the binding for IEEE 802.11, name of the technology type, e.g., the binding for IEEE 802.11,
provided in [16], begins with "IEEE 802.11". provided in [I-D.ietf-capwap-protocol-binding-ieee80211], begins with
"IEEE 802.11".
The CAPWAP binding concept MUST also be used in any future The CAPWAP binding concept MUST also be used in any future
specification that add functionality to either the base CAPWAP specification that add functionality to either the base CAPWAP
protocol specification, or any published CAPWAP binding protocol specification, or any published CAPWAP binding
specification. A separate WTP Radio Information message element MUST specification. A separate WTP Radio Information message element MUST
be created to properly advertise support for the specification. This be created to properly advertise support for the specification. This
mechanism allows for future protocol extensibility, while providing mechanism allows for future protocol extensibility, while providing
the necessary capabilities advertisement, through the WTP Radio the necessary capabilities advertisement, through the WTP Radio
Information message element, to ensure WTP/AC interoperability. Information message element, to ensure WTP/AC interoperability.
skipping to change at page 17, line 7 skipping to change at page 17, line 7
juxtaposition of two nominally separate yet tightly bound state juxtaposition of two nominally separate yet tightly bound state
machines. The DTLS and CAPWAP state machines are coupled through an machines. The DTLS and CAPWAP state machines are coupled through an
API consisting of commands (see Section 2.3.2.1) and notifications API consisting of commands (see Section 2.3.2.1) and notifications
(see Section 2.3.2.2). Certain transitions in the DTLS state machine (see Section 2.3.2.2). Certain transitions in the DTLS state machine
are triggered by commands from the CAPWAP state machine, while are triggered by commands from the CAPWAP state machine, while
certain transitions in the CAPWAP state machine are triggered by certain transitions in the CAPWAP state machine are triggered by
notifications from the DTLS state machine. notifications from the DTLS state machine.
/-------------------------------------\ /-------------------------------------\
| /-------------------------\| | /-------------------------\|
| w| || | p| ||
| x+----------+ y +------------+ || | q+----------+ r +------------+ ||
| | Run |-->| Reset |-\|| | | Run |-->| Reset |-\||
| +----------+ +------------+ ||| | +----------+ +------------+ |||
u| V ^ ^ ^ z||| n| o ^ ^ ^ s|||
+------------+--------/ | | ||| +------------+--------/ | | |||
| Data Check | /-------/ | ||| | Data Check | /-------/ | |||
+------------+<-------\ | | ||| +------------+<-------\ | | |||
| | | ||| | | | |||
/------------------+--------\ | ||| /------------------+--------\ | |||
m| t| o| q v r| ||| f| m| h| j v k| |||
+--------+ +-----------+ +--------------+||| +--------+ +-----------+ +--------------+|||
| Join |---->| Configure | | Image Data |||| | Join |---->| Configure | | Image Data ||||
+--------+ n +-----------+ +--------------+||| +--------+ n +-----------+ +--------------+|||
^ |l p| s| ||| ^ |g i| l| |||
| | \-------------------\ | ||| | | \-------------------\ | |||
| \--------------------------------------\| | ||| | \--------------------------------------\| | |||
\------------------------\ || | ||| \------------------------\ || | |||
/--------------<----------------+---------------\ || | ||| /--------------<----------------+---------------\ || | |||
| /------------<----------------+-------------\ | || | ||| | /------------<----------------+-------------\ | || | |||
| | i |k 8| | vv v vvv | | 4 |d t| | vv v vvv
| | +----------------+<--+--------------+ +-----------+ | | +----------------+ +--------------+ +-----------+
/---|-|---| DTLS Setup | | DTLS Connect |-->| DTLS TD | | | | DTLS Setup | | DTLS Connect |-->| DTLS TD |
| /-|-|---+----------------+e +--------------+ 7 +-----------+ /-|-|---+----------------+ +--------------+ e +-----------+
| | | | d |6 ^ ^ |f ^ j| ^ |~ | | | |$ ^ ^ |5 ^6 ^ ^ |w
v v v v | | | | | | | | v v v | | | | \-------\ | | |
| | | | | | | \-------\ | /----+------/ | | | | | | | \---------\ | | /-----------/ |
| | | | | | | | | | \---\ | | | | | | \--\ | | | | |
| | | | v c| 1 |5 2 v |g |h v v | | | | | | | | | | |
| | | \->+------+-->+------+ +-----------+ +--------+ | | | v 3| 1 |% # v | |a |b v
| | | | Idle | | Disc | | Authorize | | Dead | | | \->+------+-->+------+ +-----------+ +--------+
| | | +------+<--+------+ +-----------+ +--------+ | | | Idle | | Disc | | Authorize | | Dead |
| | | ^ 0 |3 ^ | | +------+<--+------+ +-----------+ +--------+
| | | | | |b | | ^ 0^ 2 |!
| | |9 |4 | | | | | | | +-------+
| | \->+---------+<------/ | *| |u | \---------+---| Start |
| \--->| Sulking | | | | |@ | +-------+
| +---------+a | | \->+---------+<------/
\---------------------------------------------------/ \--->| Sulking |
+---------+&
Figure 3: CAPWAP Integrated State Machine Figure 3: CAPWAP Integrated State Machine
The CAPWAP protocol state machine, depicted above, is used by both The CAPWAP protocol state machine, depicted above, is used by both
the AC and the WTP. In cases where states are not shared (i.e. not the AC and the WTP. In cases where states are not shared (i.e. not
implemented in one or the other of the AC or WTP), this is explicitly implemented in one or the other of the AC or WTP), this is explicitly
called out in the transition descriptions below. For every state called out in the transition descriptions below. For every state
defined, only certain messages are permitted to be sent and received. defined, only certain messages are permitted to be sent and received.
The CAPWAP control message definitions specify the state(s) in which The CAPWAP control message definitions specify the state(s) in which
each message is valid. each message is valid.
Since the WTP only communicates with a single AC, it only has a Since the WTP only communicates with a single AC, it only has a
single instance of the CAPWAP state machine. The state machine works single instance of the CAPWAP state machine. The state machine works
differently on the AC since it communicates with many WTPs. The AC differently on the AC since it communicates with many WTPs. The AC
uses the concept of two threads. Note that the term thread used here uses the concept of three threads. Note that the term thread used
does not necessarily imply that implementers must use threads, but it here does not necessarily imply that implementers must use threads,
is one possible way of implementing the AC's state machine. but it is one possible way of implementing the AC's state machine.
Listener Thread - The AC's Listener thread handles the shared Listener Thread: The AC's Listener thread handles inbound DTLS
services, which includes receiving and responding to Discovery session establishment requests, through the DTLSListen command.
Request messages. The Listener thread handles the common tasks, Upon creation, the Listener thread starts in the DTLS Setup state.
up to the DTLS Setup state. The state machine transitions in Once a DTLS session has been validated, which occurs when the
figure Figure 3are represented by numerals. It is necessary for state machine enters the "Authorize" state, the Listener thread
the AC to protect itself against various attacks that exist with creates a WTP session specific Service thread and state context.
non-authenticated frames. See Section 12 for more information. The state machine transitions in figure Figure 3 are represented
by numerals. It is necessary for the AC to protect itself against
various attacks that exist with non-authenticated frames. See
Section 12 for more information.
Service Thread - The AC's Service thread handles the per-WTP Discovery Thread: The AC's Discovery thread is responsible for
states, and one such thread exists per-WTP connection. This receiving, and responding to, Discovery Request messages. The
thread starts during the DTLS Setup state, which is when the state machine transitions in figure Figure 3 are represented by
DTLSListen command is invoked. When created, the Service thread numerals. Note that the Discovery thread does not maintain any
inherits a copy of the state machine context from the Listener per-WTP specific context information, and a single state context
thread. When communication with the WTP is complete, the Service exists. It is necessary for the AC to protect itself against
thread is terminated. The state machine transitions in the above various attacks that exist with non-authenticated frames. See
figure are represented by alphabetic characters (including Section 12 for more information.
symbols).
Service Thread: The AC's Service thread handles the per-WTP states,
and one such thread exists per-WTP connection. This thread is
created by the listener thread when the Authorize state is
reached. When created, the Service thread inherits a copy of the
state machine context from the Listener thread. When
communication with the WTP is complete, the Service thread is
terminated and all associated resources are released. The state
machine transitions in figure Figure 3 are represented by
alphabetic characters.
2.3.1. CAPWAP Protocol State Transitions 2.3.1. CAPWAP Protocol State Transitions
This section describes the various state transitions, and the events This section describes the various state transitions, and the events
that cause them. This section does not discuss interactions between that cause them. This section does not discuss interactions between
DTLS- and CAPWAP-specific states. Those interactions, and DTLS- DTLS- and CAPWAP-specific states. Those interactions, and DTLS-
specific states and transitions, are discussed in Section 2.3.2. specific states and transitions, are discussed in Section 2.3.2.
Idle to Discovery (1): This transition occurs once device Start to Idle (0): This transition occurs once device initialization
initialization is complete. is complete.
WTP: This state transition is used to start the WTP's CAPWAP
state machine.
AC: The AC creates the Discovery and Listener threads and starts
the CAPWAP state machine.
Idle to Discovery (1): This transition occurs to support the CAPWAP
discovery process .
WTP: The WTP enters the Discovery state prior to transmitting the WTP: The WTP enters the Discovery state prior to transmitting the
first Discovery Request message (see Section 5.1). Upon first Discovery Request message (see Section 5.1). Upon
entering this state, the WTP sets the DiscoveryInterval timer entering this state, the WTP sets the DiscoveryInterval timer
(see Section 4.7). The WTP resets the DiscoveryCount counter (see Section 4.7). The WTP resets the DiscoveryCount counter
to zero (0) (see Section 4.8). The WTP also clears all to zero (0) (see Section 4.8). The WTP also clears all
information from ACs it may have received during a previous information from ACs it may have received during a previous
Discovery phase. Discovery phase.
AC: This state transition is executed by the AC's Listener AC: This state transition is executed by the AC's Discovery
thread, and occurs when a Discovery Request message is thread, and occurs when a Discovery Request message is
received. The AC SHOULD respond with a Discovery Response received. The AC SHOULD respond with a Discovery Response
message (see Section 5.2). The AC SHOULD NOT maintain WTP message (see Section 5.2).
state at this point (see Section 12 for more information).
Discovery to Discovery (2): In the Discovery state, the WTP Discovery to Discovery (#): In the Discovery state, the WTP
determines which AC to connect to. determines which AC to connect to.
WTP: This transition occurs when the DiscoveryInterval timer WTP: This transition occurs when the DiscoveryInterval timer
expires. If the WTP is configured with a list of ACs, it expires. If the WTP is configured with a list of ACs, it
transmits a Discovery Request message to every AC from which it transmits a Discovery Request message to every AC from which it
has not received a Discovery Response message. For every has not received a Discovery Response message. For every
transition to this event, the WTP increments the DiscoveryCount transition to this event, the WTP increments the DiscoveryCount
counter. See Section 5.1 for more information on how the WTP counter. See Section 5.1 for more information on how the WTP
knows the ACs to which it should transmit the Discovery Request knows the ACs to which it should transmit the Discovery Request
messages. The WTP restarts the DiscoveryInterval timer messages. The WTP restarts the DiscoveryInterval timer
whenever it transmits Discovery Request messages. whenever it transmits Discovery Request messages.
AC: This is an invalid state transition for the AC. AC: This is an invalid state transition for the AC.
Discovery to Idle (0): This transition occurs on the AC's Listener Discovery to Idle (2): This transition occurs on the AC's Discovery
thread when the Discovery processing is complete. thread when the Discovery processing is complete.
WTP: This is an invalid state transition for the WTP. WTP: This is an invalid state transition for the WTP.
AC: This state transition is executed by the AC's Listener thread AC: This state transition is executed by the AC's Discovery
when it has transmitted the Discovery Response, in response to thread when it has transmitted the Discovery Response, in
a Discovery Request. response to a Discovery Request.
Discovery to Sulking (3): This transition occurs on a WTP when AC Discovery to Sulking (!): This transition occurs on a WTP when AC
Discovery fails. Discovery fails.
WTP: The WTP enters this state when the DiscoveryInterval timer WTP: The WTP enters this state when the DiscoveryInterval timer
expires and the DiscoveryCount variable is equal to the expires and the DiscoveryCount variable is equal to the
MaxDiscoveries variable (see Section 4.8). Upon entering this MaxDiscoveries variable (see Section 4.8). Upon entering this
state, the WTP MUST start the SilentInterval timer. While in state, the WTP MUST start the SilentInterval timer. While in
the Sulking state, all received CAPWAP protocol messages MUST the Sulking state, all received CAPWAP protocol messages MUST
be ignored. be ignored.
AC: This is an invalid state transition for the AC. AC: This is an invalid state transition for the AC.
Sulking to Idle (4): This transition occurs on a WTP when it must Sulking to Idle (@): This transition occurs on a WTP when it must
restart the discovery phase. restart the discovery phase.
WTP: The WTP enters this state when the SilentInterval timer (see WTP: The WTP enters this state when the SilentInterval timer (see
Section 4.7) expires. The FailedDTLSSessionCount, Section 4.7) expires. The FailedDTLSSessionCount,
DiscoveryCount and FailedDTLSAuthFailCount counters are reset DiscoveryCount and FailedDTLSAuthFailCount counters are reset
to zero. to zero.
AC: This is an invalid state transition for the AC. AC: This is an invalid state transition for the AC.
Sulking to Sulking (a): The Sulking state provides the silent Sulking to Sulking (&): The Sulking state provides the silent
period, minimizing the possibility for Denial of Service (DoS) period, minimizing the possibility for Denial of Service (DoS)
attacks. attacks.
WTP: All packets received from the AC while in the sulking state WTP: All packets received from the AC while in the sulking state
are ignored. are ignored.
AC: This is an invalid state transition for the AC. AC: This is an invalid state transition for the AC.
Idle to DTLS Setup (c): This transition occurs to establish a secure Idle to DTLS Setup (3): This transition occurs to establish a secure
DTLS session with the peer. DTLS session with the peer.
WTP: The WTP initiates this transition by invoking the DTLSStart WTP: The WTP initiates this transition by invoking the DTLSStart
command, which starts the DTLS session establishment with the command, which starts the DTLS session establishment with the
chosen AC. When the discovery phase is bypassed, it is assumed chosen AC. When the discovery phase is bypassed, it is assumed
the WTP has locally configured ACs. the WTP has locally configured ACs.
AC: The AC initiates this transition by invoking the DTLSListen AC: Upon entering the Idle state from the Start state, the newly
command (see Section 2.3.2.1), which informs the DTLS stack created Listener thread automatically transitions to the DTLS
that it is willing to listen for an incoming session. The AC's Setup and invokes the DTLSListen command (see Section 2.3.2.1).
Listener thread forks an instance of the Service thread, along
with a copy of the state context. If the AC had maintained WTP
state information during the Discovery exchange, or through
some other means that may include static configuration of WTPs,
the AC MAY provide optional qualifiers in the DTLSListen
command to only accept session requests a specific WTP. Note
that the AC SHOULD NOT maintain state information based on an
unsecured Discovery Request message, as this can lead to a
Denial of Service attack (see Section 12). However, in the
event that the AC does maintain state, it MUST ensure that the
state information is freed after a period, which is
implementation specific.
Discovery to DTLS Setup (5): This transition occurs to establish a Discovery to DTLS Setup (%): This transition occurs to establish a
secure DTLS session with the peer. secure DTLS session with the peer.
WTP: The WTP initiates this transition by invoking the DTLSStart WTP: The WTP initiates this transition by invoking the DTLSStart
command (see Section 2.3.2.1), which starts the DTLS session command (see Section 2.3.2.1), which starts the DTLS session
establishment with the chosen AC. The decision of which AC to establishment with the chosen AC. The decision of which AC to
connect to is the result of the discovery phase, which is connect to is the result of the discovery phase, which is
described in Section 3.3. described in Section 3.3.
AC: This is an invalid state transition for the AC. AC: This is an invalid state transition for the AC.
DTLS Setup to Idle (6): This transition occurs when the DTLS DTLS Setup to Idle ($): This transition occurs when the DTLS
connection setup fails. connection setup fails.
WTP: The WTP initiates this state transition when it receives a WTP: The WTP initiates this state transition when it receives a
DTLSEstablishFail notification from DTLS (see Section 2.3.2.2), DTLSEstablishFail notification from DTLS (see Section 2.3.2.2),
and the FailedDTLSSessionCount or the FailedDTLSAuthFailCount and the FailedDTLSSessionCount or the FailedDTLSAuthFailCount
counter have not reached the value of the counter have not reached the value of the
MaxFailedDTLSSessionRetry variable (see Section 4.8). This MaxFailedDTLSSessionRetry variable (see Section 4.8). This
error notification aborts the secure DTLS session error notification aborts the secure DTLS session
establishment. When this notification is received, the establishment. When this notification is received, the
FailedDTLSSessionCount counter is incremented. FailedDTLSSessionCount counter is incremented.
AC: This is an invalid state transition for the AC. AC: This is an invalid state transition for the AC.
DTLS Setup to Sulking (d): This transition occurs when repeated DTLS Setup to Sulking (*): This transition occurs when repeated
attempts to setup the DTLS connection have failed. attempts to setup the DTLS connection have failed.
WTP: The WTP enters this state when the FailedDTLSSessionCount or WTP: The WTP enters this state when the FailedDTLSSessionCount or
the FailedDTLSAuthFailCount counter reaches the value of the the FailedDTLSAuthFailCount counter reaches the value of the
MaxFailedDTLSSessionRetry variable (see Section 4.8). Upon MaxFailedDTLSSessionRetry variable (see Section 4.8). Upon
entering this state, the WTP MUST start the SilentInterval entering this state, the WTP MUST start the SilentInterval
timer. While in the Sulking state, all received CAPWAP and timer. While in the Sulking state, all received CAPWAP and
DTLS protocol messages received MUST be ignored. DTLS protocol messages received MUST be ignored.
AC: This is an invalid state transition for the AC. AC: This is an invalid state transition for the AC.
DTLS Setup to Dead (b): This transition occurs on the AC when the DTLS Setup to DTLS Setup (4): This transition occurs when the DTLS
DTLS connection setup fails.
WTP: This is an invalid state transition for the WTP.
AC: The AC initiates this state transition when it receives a
DTLSEstablishFail notification from DTLS (see Section 2.3.2.2).
This error notification aborts the secure DTLS session
establishment. When this notification is received, the
FailedDTLSSessionCount counter is incremented. The AC must
release all resources associated with the control plane DTLS
session. The data plane DTLS session is also shutdown, and all
resources released, if a DTLS session was established for the
data plane. Any timers set for the current instance of the
state machine are also cleared. The AC's Service thread is
terminated.
DTLS Setup to DTLS Setup (e): This transition occurs when the DTLS
Session failed to be established. Session failed to be established.
WTP: This is an invalid state transition for the WTP. WTP: This is an invalid state transition for the WTP.
AC: The AC initiates this state transition by the Service thread AC: The AC's Listener initiates this state transition when it
when it receives a DTLSEstablishFail notification from DTLS receives a DTLSEstablishFail notification from DTLS (see
(see Section 2.3.2.2). This error notification aborts the Section 2.3.2.2). This error notification aborts the secure
secure DTLS session establishment. When this notification is DTLS session establishment. When this notification is
received, the FailedDTLSSessionCount counter is incremented. received, the FailedDTLSSessionCount counter is incremented.
The Listener thread then invokes the DTLSListen command (see
Section 2.3.2.1).
DTLS Setup to Authorize (f): This transition occurs when an incoming DTLS Setup to Authorize (5): This transition occurs when an incoming
DTLS session is being established, and the DTLS stack needs DTLS session is being established, and the DTLS stack needs
authorization to proceed with the session establishment. authorization to proceed with the session establishment.
WTP: This state transition occurs when the WTP receives the WTP: This state transition occurs when the WTP receives the
DTLSPeerAuthorize notification (see Section 2.3.2.2). Upon DTLSPeerAuthorize notification (see Section 2.3.2.2). Upon
entering this state, the WTP performs an authorization check entering this state, the WTP performs an authorization check
against the AC credentials. See Section 2.4.4 for more against the AC credentials. See Section 2.4.4 for more
information on AC authorization. information on AC authorization.
AC: This state transition occurs when the AC receives the AC: This state transition is handled by the AC's Listener thread
DTLSPeerAuthorize notification (see Section 2.3.2.2). Upon when the DTLS module initiates the DTLSPeerAuthorize
entering this state, the AC performs an authorization check notification (see Section 2.3.2.2). The Listener thread forks
against the WTP credentials. See Section 2.4.4 for more an instance of the Service thread, along with a copy of the
information on WTP authorization. state context. Once created, the Service thread performs an
authorization check against the WTP credentials. See
Section 2.4.4 for more information on WTP authorization.
Authorize to DTLS Connect (g): This transition occurs to notify the Authorize to DTLS Setup (6): This transition is executed by the
Listener thread to enable it to listen for new incoming sessions.
WTP: This is an invalid state transition for the WTP.
AC: This state transition occurs when the AC's Listener thread
has created the WTP context and the Service thread. The
Listener thread then invokes the DTLSListen command (see
Section 2.3.2.1).
Authorize to DTLS Connect (a): This transition occurs to notify the
DTLS stack that the session should be established. DTLS stack that the session should be established.
WTP: This state transition occurs when the WTP has successfully WTP: This state transition occurs when the WTP has successfully
authorized the AC's credentials (see Section 2.4.4). This is authorized the AC's credentials (see Section 2.4.4). This is
done by invoking the DTLSAccept DTLS command (see done by invoking the DTLSAccept DTLS command (see
Section 2.3.2.1). Section 2.3.2.1).
AC: This state transition occurs when the AC has successfully AC: This state transition occurs when the AC has successfully
authorized the WTP's credentials (see Section 2.4.4). This is authorized the WTP's credentials (see Section 2.4.4). This is
done by invoking the DTLSAccept DTLS command (see done by invoking the DTLSAccept DTLS command (see
Section 2.3.2.1). Section 2.3.2.1).
Authorize to DTLS Teardown (h): This transition occurs to notify the Authorize to DTLS Teardown (b): This transition occurs to notify the
DTLS stack that the session should be aborted. DTLS stack that the session should be aborted.
WTP: This state transition occurs when the WTP was unable to WTP: This state transition occurs when the WTP was unable to
authorize the AC, using the AC credentials. The WTP then authorize the AC, using the AC credentials. The WTP then
aborts the DTLS session by invoking the DTLSAbortSession aborts the DTLS session by invoking the DTLSAbortSession
command (see Section 2.3.2.1). command (see Section 2.3.2.1).
AC: This state transition occurs when the AC was unable to AC: This state transition occurs when the AC was unable to
authorize the WTP, using the WTP credentials. The AC then authorize the WTP, using the WTP credentials. The AC then
aborts the DTLS session by invoking the DTLSAbortSession aborts the DTLS session by invoking the DTLSAbortSession
command (see Section 2.3.2.1). command (see Section 2.3.2.1).
DTLS Connect to DTLS Teardown (7): This transition occurs when the DTLS Connect to DTLS Teardown (c): This transition occurs when the
DTLS Session failed to be established. DTLS Session failed to be established.
WTP: This state transition occurs when the WTP receives either a WTP: This state transition occurs when the WTP receives either a
DTLSAborted or DTLSAuthenticateFail notification (see DTLSAborted or DTLSAuthenticateFail notification (see
Section 2.3.2.2), indicating that the DTLS session was not Section 2.3.2.2), indicating that the DTLS session was not
successfully established. When this transition occurs due to successfully established. When this transition occurs due to
the DTLSAuthenticateFail notification, the the DTLSAuthenticateFail notification, the
FailedDTLSAuthFailCount is incremented, otherwise the FailedDTLSAuthFailCount is incremented, otherwise the
FailedDTLSSessionCount counter is incremented. FailedDTLSSessionCount counter is incremented.
AC: This is an invalid state transition for the AC.
DTLS Connect to DTLS Setup (i): This transition occurs when the DTLS
Session failed to be established.
WTP: This is an invalid state transition for the WTP.
AC: This state transition occurs when the AC receives either a AC: This state transition occurs when the AC receives either a
DTLSAborted or DTLSAuthenticateFail notification (see DTLSAborted or DTLSAuthenticateFail notification (see
Section 2.3.2.2), indicating that the DTLS session was not Section 2.3.2.2), indicating that the DTLS session was not
successfully established, and both of the successfully established, and both of the
FailedDTLSAuthFailCount and FailedDTLSSessionCount counters FailedDTLSAuthFailCount and FailedDTLSSessionCount counters
have not reached the value of the MaxFailedDTLSSessionRetry have not reached the value of the MaxFailedDTLSSessionRetry
variable (see Section 4.8). variable (see Section 4.8).
DTLS Connect to Dead (j): This transition occurs when the DTLS DTLS Connect to Join (d): This transition occurs when the DTLS
Session failed to be established.
WTP: This is an invalid state transition for the WTP.
AC: This state transition occurs when the AC receives either a
DTLSAborted or DTLSAuthenticateFail notification (see
Section 2.3.2.2), indicating that the DTLS session was not
successfully established, and either the
FailedDTLSAuthFailCount and FailedDTLSSessionCount counters
have reached the value of the MaxFailedDTLSSessionRetry
variable (see Section 4.8).
DTLS Connect to Join (k): This transition occurs when the DTLS
Session is successfully established. Session is successfully established.
WTP: This state transition occurs when the WTP receives the WTP: This state transition occurs when the WTP receives the
DTLSEstablished notification (see Section 2.3.2.2), indicating DTLSEstablished notification (see Section 2.3.2.2), indicating
that the DTLS session was successfully established. When this that the DTLS session was successfully established. When this
notification is received, the FailedDTLSSessionCount counter is notification is received, the FailedDTLSSessionCount counter is
set to zero. set to zero.
AC: This state transition occurs when the AC receives the AC: This state transition occurs when the AC receives the
DTLSEstablished notification (see Section 2.3.2.2), indicating DTLSEstablished notification (see Section 2.3.2.2), indicating
that the DTLS session was successfully established. When this that the DTLS session was successfully established. When this
notification is received, the FailedDTLSSessionCount counter is notification is received, the FailedDTLSSessionCount counter is
set to zero, and the WaitJoin timer is started (see set to zero, and the WaitJoin timer is started (see
Section 4.7). Section 4.7).
Join to DTLS Teardown (l): This transition occurs when the join Join to DTLS Teardown (e): This transition occurs when the join
process failed. process failed.
WTP: This state transition occurs when the WTP receives a Join WTP: This state transition occurs when the WTP receives a Join
Response message with a Result Code message element containing Response message with a Result Code message element containing
an error, if the Image Identifier provided by the AC in the an error, if the Image Identifier provided by the AC in the
Join Response message differs from the WTP's currently running Join Response message differs from the WTP's currently running
firmware version and the WTP has the requested image in its firmware version and the WTP has the requested image in its
non-volatile memory, or if the WaitDTLS timer expires. This non-volatile memory, or if the WaitDTLS timer expires. This
causes the WTP to initiate the DTLSShutdown command (see causes the WTP to initiate the DTLSShutdown command (see
Section 2.3.2.1). This transition also occurs if the WTP Section 2.3.2.1). This transition also occurs if the WTP
skipping to change at page 24, line 43 skipping to change at page 24, line 27
DTLSReassemblyFailure or DTLSPeerDisconnect. DTLSReassemblyFailure or DTLSPeerDisconnect.
AC: This state transition occurs either if the WaitJoin timer AC: This state transition occurs either if the WaitJoin timer
expires or if the AC transmits a Join Response message with a expires or if the AC transmits a Join Response message with a
Result Code message element containing an error. This causes Result Code message element containing an error. This causes
the AC to initiate the DTLSShutdown command (see the AC to initiate the DTLSShutdown command (see
Section 2.3.2.1). This transition also occurs if the AC Section 2.3.2.1). This transition also occurs if the AC
receives one of the following DTLS notifications: DTLSAborted, receives one of the following DTLS notifications: DTLSAborted,
DTLSReassemblyFailure or DTLSPeerDisconnect. DTLSReassemblyFailure or DTLSPeerDisconnect.
Join to Image Data (m): This state transition is used by the WTP and Join to Image Data (f): This state transition is used by the WTP and
the AC to download executable firmware. the AC to download executable firmware.
WTP: The WTP enters the Image Data state when it receives a WTP: The WTP enters the Image Data state when it receives a
successful Join Response message and determines and the successful Join Response message and determines and the
included Image Identifier message element is not the same as included Image Identifier message element is not the same as
its currently running image. The WTP also detects that the its currently running image. The WTP also detects that the
requested image version is not currently available in the WTP's requested image version is not currently available in the WTP's
non-volatile storage (see Section 9.1 for a full description of non-volatile storage (see Section 9.1 for a full description of
the firmware download process). The WTP initializes the the firmware download process). The WTP initializes the
EchoInterval timer (see Section 4.7), and transmits the Image EchoInterval timer (see Section 4.7), and transmits the Image
Data Request message (see Section 9.1.1) requesting the start Data Request message (see Section 9.1.1) requesting the start
of the firmware download. of the firmware download.
AC: This state transition occurs when the AC receives the Image AC: This state transition occurs when the AC receives the Image
Data Request message from the WTP. The AC MUST transmit an Data Request message from the WTP. The AC MUST transmit an
Image Data Response message (see Section 9.1.2) to the WTP, Image Data Response message (see Section 9.1.2) to the WTP,
which includes a portion of the firmware. The AC MUST start which includes a portion of the firmware. The AC MUST start
the ImageDataStartTimer timer (see Section 4.7). the ImageDataStartTimer timer (see Section 4.7).
Join to Configure (n): This state transition is used by the WTP and Join to Configure (g): This state transition is used by the WTP and
the AC to exchange configuration information. the AC to exchange configuration information.
WTP: The WTP enters the Configure state when it receives a WTP: The WTP enters the Configure state when it receives a
successful Join Response message, and determines that the successful Join Response message, and determines that the
included Image Identifier message element is the same as its included Image Identifier message element is the same as its
currently running image. The WTP transmits the Configuration currently running image. The WTP transmits the Configuration
Status message (see Section 8.2) to the AC with message Status message (see Section 8.2) to the AC with message
elements describing its current configuration. The WTP also elements describing its current configuration. The WTP also
starts the ResponseTimeout timer (see Section 4.7). starts the ResponseTimeout timer (see Section 4.7).
AC: This state transition occurs immediately after the AC AC: This state transition occurs immediately after the AC
transmits the Join Response message to the WTP. If the AC transmits the Join Response message to the WTP. If the AC
receives the Configuration Status message from the WTP, the AC receives the Configuration Status message from the WTP, the AC
MUST transmit a Configuration Status Response message (see MUST transmit a Configuration Status Response message (see
Section 8.3) to the WTP, and MAY include specific message Section 8.3) to the WTP, and MAY include specific message
elements to override the WTP's configuration. The AC also elements to override the WTP's configuration. The AC also
starts the ChangeStatePendingTimer timer (see Section 4.7). starts the ChangeStatePendingTimer timer (see Section 4.7).
Configure to Reset (o): This state transition is used to reset the Configure to Reset (h): This state transition is used to reset the
connection either due to an error during the configuration phase, connection either due to an error during the configuration phase,
or when the WTP determines it needs to reset in order for the new or when the WTP determines it needs to reset in order for the new
configuration to take effect. configuration to take effect.
WTP: The WTP enters the Reset state when it receives a WTP: The WTP enters the Reset state when it receives a
Configuration Status Response message indicating an error or Configuration Status Response message indicating an error or
when it determines that a reset of the WTP is required, due to when it determines that a reset of the WTP is required, due to
the characteristics of a new configuration. the characteristics of a new configuration.
AC: The AC transitions to the Reset state when it receives a AC: The AC transitions to the Reset state when it receives a
Change State Event message from the WTP that contains an error Change State Event message from the WTP that contains an error
for which AC policy does not permit the WTP to provide service. for which AC policy does not permit the WTP to provide service.
This state transition also occurs when the AC This state transition also occurs when the AC
ChangeStatePendingTimer timer expires. ChangeStatePendingTimer timer expires.
Configure to DTLS Teardown (p): This transition occurs when the Configure to DTLS Teardown (i): This transition occurs when the
configuration process aborts due to a DTLS error. configuration process aborts due to a DTLS error.
WTP: The WTP enters this state when it receives one of the WTP: The WTP enters this state when it receives one of the
following DTLS notifications: DTLSAborted, following DTLS notifications: DTLSAborted,
DTLSReassemblyFailure or DTLSPeerDisconnect (see DTLSReassemblyFailure or DTLSPeerDisconnect (see
Section 2.3.2.2). The WTP MAY tear down the DTLS session if it Section 2.3.2.2). The WTP MAY tear down the DTLS session if it
receives frequent DTLSDecapFailure notifications. receives frequent DTLSDecapFailure notifications.
AC: The AC enters this state when it receives one of the AC: The AC enters this state when it receives one of the
following DTLS notifications: DTLSAborted, following DTLS notifications: DTLSAborted,
DTLSReassemblyFailure or DTLSPeerDisconnect (see DTLSReassemblyFailure or DTLSPeerDisconnect (see
Section 2.3.2.2). The WTP MAY tear down the DTLS session if it Section 2.3.2.2). The WTP MAY tear down the DTLS session if it
receives frequent DTLSDecapFailure notifications. receives frequent DTLSDecapFailure notifications.
Image Data to Image Data (q): The Image Data state is used by the Image Data to Image Data (j): The Image Data state is used by the
WTP and the AC during the firmware download phase. WTP and the AC during the firmware download phase.
WTP: The WTP enters the Image Data state when it receives an WTP: The WTP enters the Image Data state when it receives an
Image Data Response message indicating that the AC has more Image Data Response message indicating that the AC has more
data to send. data to send.
AC: This state transition occurs when the AC receives the Image AC: This state transition occurs when the AC receives the Image
Data Request message from the WTP while already in the Image Data Request message from the WTP while already in the Image
Data state. The AC resets the ImageDataStartTimer timer. Data state. The AC resets the ImageDataStartTimer timer.
Image Data to Reset (r): This state transition is used to reset the Image Data to Reset (k): This state transition is used to reset the
DTLS connection prior to restarting the WTP after an image DTLS connection prior to restarting the WTP after an image
download. download.
WTP: When an image download completes, the WTP enters the Reset WTP: When an image download completes, the WTP enters the Reset
state. The WTP MAY also transition to this state upon state. The WTP MAY also transition to this state upon
receiving an Image Data Response message from the AC (see receiving an Image Data Response message from the AC (see
Section 9.1.2) indicating a failure. Section 9.1.2) indicating a failure.
AC: The AC enters the Reset state when an error occurs during the AC: The AC enters the Reset state when an error occurs during the
image download process or if the ImageDataStartTimer timer image download process or if the ImageDataStartTimer timer
expires. expires.
Image Data to DTLS Teardown (s): This transition occurs when the Image Data to DTLS Teardown (l): This transition occurs when the
firmware download process aborts due to a DTLS error. firmware download process aborts due to a DTLS error.
WTP: The WTP enters this state when it receives one of the WTP: The WTP enters this state when it receives one of the
following DTLS notifications: DTLSAborted, following DTLS notifications: DTLSAborted,
DTLSReassemblyFailure or DTLSPeerDisconnect (see DTLSReassemblyFailure or DTLSPeerDisconnect (see
Section 2.3.2.2). The WTP MAY tear down the DTLS session if it Section 2.3.2.2). The WTP MAY tear down the DTLS session if it
receives frequent DTLSDecapFailure notifications. receives frequent DTLSDecapFailure notifications.
AC: The AC enters this state when it receives one of the AC: The AC enters this state when it receives one of the
following DTLS notifications: DTLSAborted, following DTLS notifications: DTLSAborted,
DTLSReassemblyFailure or DTLSPeerDisconnect (see DTLSReassemblyFailure or DTLSPeerDisconnect (see
Section 2.3.2.2). The WTP MAY tear down the DTLS session if it Section 2.3.2.2). The WTP MAY tear down the DTLS session if it
receives frequent DTLSDecapFailure notifications. receives frequent DTLSDecapFailure notifications.
Configure to Data Check (t): This state transition occurs when the Configure to Data Check (m): This state transition occurs when the
WTP and AC confirm the configuration. WTP and AC confirm the configuration.
WTP: The WTP enters this state when it receives a successful WTP: The WTP enters this state when it receives a successful
Configuration Status Response message from the AC. The WTP Configuration Status Response message from the AC. The WTP
initializes the EchoInterval timer (see Section 4.7), and initializes the EchoInterval timer (see Section 4.7), and
transmits the Change State Event Request message (see transmits the Change State Event Request message (see
Section 8.6). Section 8.6).
AC: This state transition occurs when the AC receives the Change AC: This state transition occurs when the AC receives the Change
State Event Request message (see Section 8.6) from the WTP. State Event Request message (see Section 8.6) from the WTP.
The AC responds with a Change State Event Response message (see The AC responds with a Change State Event Response message (see
Section 8.7). The AC MUST start the DataCheckTimer timer (see Section 8.7). The AC MUST start the DataCheckTimer timer (see
Section 4.7). Section 4.7).
Data Check to DTLS Teardown (u): This transition occurs when the WTP Data Check to DTLS Teardown (n): This transition occurs when the WTP
does not complete the Data Check exchange. does not complete the Data Check exchange.
WTP: This state transition occurs if the WTP does not receive the WTP: This state transition occurs if the WTP does not receive the
Change State Event Response message before a CAPWAP Change State Event Response message before a CAPWAP
transmission timeout occurs. transmission timeout occurs.
AC: The AC enters this state when the DataCheckTimer timer AC: The AC enters this state when the DataCheckTimer timer
expires (see Section 4.7). expires (see Section 4.7).
Data Check to Run (V): This state transition occurs when the linkage Data Check to Run (o): This state transition occurs when the linkage
between the control and data channels is established, causing the between the control and data channels is established, causing the
WTP and AC to enter their normal state of operation. WTP and AC to enter their normal state of operation.
WTP: The WTP enters this state when it receives a successful WTP: The WTP enters this state when it receives a successful
Change State Event Response message from the AC. The WTP Change State Event Response message from the AC. The WTP
initiates the data channel, which MAY require the establishment initiates the data channel, which MAY require the establishment
of a DTLS session, starts the DataChannelKeepAlive timer (see of a DTLS session, starts the DataChannelKeepAlive timer (see
Section 4.7) and transmits a Data Channel Keep Alive packet Section 4.7) and transmits a Data Channel Keep Alive packet
(see Section 4.4.1). The WTP then starts the (see Section 4.4.1). The WTP then starts the
DataChannelDeadInterval timer (see Section 4.7). DataChannelDeadInterval timer (see Section 4.7).
skipping to change at page 28, line 9 skipping to change at page 27, line 43
AC: This state transition occurs when the AC receives the Data AC: This state transition occurs when the AC receives the Data
Channel Keep Alive packet (see Section 4.4.1), with a Session Channel Keep Alive packet (see Section 4.4.1), with a Session
ID message element matching that included by the WTP in the ID message element matching that included by the WTP in the
Join Request message. The AC disables the DataCheckTimer Join Request message. The AC disables the DataCheckTimer
timer. Note that if AC policy is to require the data channel timer. Note that if AC policy is to require the data channel
to be encrypted, this process would also require the to be encrypted, this process would also require the
establishment of a data channel DTLS session. Upon receiving establishment of a data channel DTLS session. Upon receiving
the Data Channel Keep Alive packet, the AC transmits its own the Data Channel Keep Alive packet, the AC transmits its own
Data Channel Keep Alive packet. Data Channel Keep Alive packet.
Run to DTLS Teardown (w): This state transition occurs when an error Run to DTLS Teardown (p): This state transition occurs when an error
has occurred in the DTLS stack, causing the DTLS session to be has occurred in the DTLS stack, causing the DTLS session to be
torn down. torn down.
WTP: The WTP enters this state when it receives one of the WTP: The WTP enters this state when it receives one of the
following DTLS notifications: DTLSAborted, following DTLS notifications: DTLSAborted,
DTLSReassemblyFailure or DTLSPeerDisconnect (see DTLSReassemblyFailure or DTLSPeerDisconnect (see
Section 2.3.2.2). The WTP MAY tear down the DTLS session if it Section 2.3.2.2). The WTP MAY tear down the DTLS session if it
receives frequent DTLSDecapFailure notifications. The WTP also receives frequent DTLSDecapFailure notifications. The WTP also
transitions to this state if the underlying reliable transitions to this state if the underlying reliable
transport's RetransmitCount counter has reached the transport's RetransmitCount counter has reached the
skipping to change at page 28, line 31 skipping to change at page 28, line 16
AC: The AC enters this state when it receives one of the AC: The AC enters this state when it receives one of the
following DTLS notifications: DTLSAborted, following DTLS notifications: DTLSAborted,
DTLSReassemblyFailure or DTLSPeerDisconnect (see DTLSReassemblyFailure or DTLSPeerDisconnect (see
Section 2.3.2.2). The WTP MAY tear down the DTLS session if it Section 2.3.2.2). The WTP MAY tear down the DTLS session if it
receives frequent DTLSDecapFailure notifications. The AC receives frequent DTLSDecapFailure notifications. The AC
transitions to this state if the underlying reliable transitions to this state if the underlying reliable
transport's RetransmitCount counter has reached the transport's RetransmitCount counter has reached the
MaxRetransmit variable (see Section 4.7). MaxRetransmit variable (see Section 4.7).
Run to Run (x): This is the normal state of operation. Run to Run (q): This is the normal state of operation.
WTP: This is the WTP's normal state of operation. There are many WTP: This is the WTP's normal state of operation. There are many
events that result this state transition: events that result this state transition:
Configuration Update: The WTP receives a Configuration Update Configuration Update: The WTP receives a Configuration Update
Request message(see Section 8.4). The WTP MUST respond with Request message(see Section 8.4). The WTP MUST respond with
a Configuration Update Response message (see Section 8.5). a Configuration Update Response message (see Section 8.5).
Change State Event: The WTP receives a Change State Event Change State Event: The WTP receives a Change State Event
Response message, or determines that it must initiate a Response message, or determines that it must initiate a
skipping to change at page 30, line 10 skipping to change at page 29, line 38
Data Transfer: The AC receives a Data Transfer Request message Data Transfer: The AC receives a Data Transfer Request message
from the WTP (see Section 9.6) and MUST generate a from the WTP (see Section 9.6) and MUST generate a
corresponding Data Transfer Response message (see corresponding Data Transfer Response message (see
Section 9.7). Section 9.7).
Station Configuration Request: The AC sends a Station Station Configuration Request: The AC sends a Station
Configuration Request message (see Section 10.1) or receives Configuration Request message (see Section 10.1) or receives
the corresponding Station Configuration Response message the corresponding Station Configuration Response message
(see Section 10.2) from the WTP. (see Section 10.2) from the WTP.
Run to Reset (y): This state transition is used when either the AC Run to Reset (r): This state transition is used when either the AC
or WTP tear down the connection. This may occur as part of normal or WTP tear down the connection. This may occur as part of normal
operation, or due to error conditions. operation, or due to error conditions.
WTP: The WTP enters the Reset state when it receives a Reset WTP: The WTP enters the Reset state when it receives a Reset
Request message from the AC. Request message from the AC.
AC: The AC enters the Reset state when it transmits a Reset AC: The AC enters the Reset state when it transmits a Reset
Request message to the WTP. Request message to the WTP.
Reset to DTLS Teardown (z): This transition occurs when the CAPWAP Reset to DTLS Teardown (s): This transition occurs when the CAPWAP
reset is complete, to terminate the DTLS session. reset is complete, to terminate the DTLS session.
WTP: This state transition occurs when the WTP receives a Reset WTP: This state transition occurs when the WTP receives a Reset
Response message. This causes the WTP to initiate the Response message. This causes the WTP to initiate the
DTLSShutdown command (see Section 2.3.2.1). DTLSShutdown command (see Section 2.3.2.1).
AC: This state transition occurs when the AC transmits a Reset AC: This state transition occurs when the AC transmits a Reset
Response message. The AC does not invoke the DTLSShutdown Response message. The AC does not invoke the DTLSShutdown
command (see Section 2.3.2.1). command (see Section 2.3.2.1).
DTLS Teardown to Idle (8): This transition occurs when the DTLS DTLS Teardown to Idle (t): This transition occurs when the DTLS
session has been shutdown. session has been shutdown.
WTP: This state transition occurs when the WTP has successfully WTP: This state transition occurs when the WTP has successfully
cleaned up all resources associated with the control plane DTLS cleaned up all resources associated with the control plane DTLS
session. The data plane DTLS session is also shutdown, and all session. The data plane DTLS session is also shutdown, and all
resources released, if a DTLS session was established for the resources released, if a DTLS session was established for the
data plane. Any timers set for the current instance of the data plane. Any timers set for the current instance of the
state machine are also cleared. state machine are also cleared.
AC: This is an invalid state transition for the AC. AC: This is an invalid state transition for the AC.
DTLS Teardown to Sulking (9): This transition occurs when repeated DTLS Teardown to Sulking (u): This transition occurs when repeated
attempts to setup the DTLS connection have failed. attempts to setup the DTLS connection have failed.
WTP: The WTP enters this state when the FailedDTLSSessionCount or WTP: The WTP enters this state when the FailedDTLSSessionCount or
the FailedDTLSAuthFailCount counter reaches the value of the the FailedDTLSAuthFailCount counter reaches the value of the
MaxFailedDTLSSessionRetry variable (see Section 4.8). Upon MaxFailedDTLSSessionRetry variable (see Section 4.8). Upon
entering this state, the WTP MUST start the SilentInterval entering this state, the WTP MUST start the SilentInterval
timer. While in the Sulking state, all received CAPWAP and timer. While in the Sulking state, all received CAPWAP and
DTLS protocol messages received MUST be ignored. DTLS protocol messages received MUST be ignored.
AC: This is an invalid state transition for the AC. AC: This is an invalid state transition for the AC.
DTLS Teardown to Dead (~): This transition occurs when the DTLS DTLS Teardown to Dead (w): This transition occurs when the DTLS
session has been shutdown. session has been shutdown.
WTP: This is an invalid state transition for the WTP. WTP: This is an invalid state transition for the WTP.
AC: This state transition occurs when the AC has successfully AC: This state transition occurs when the AC has successfully
cleaned up all resources associated with the control plane DTLS cleaned up all resources associated with the control plane DTLS
session. The data plane DTLS session is also shutdown, and all session. The data plane DTLS session is also shutdown, and all
resources released, if a DTLS session was established for the resources released, if a DTLS session was established for the
data plane. Any timers set for the current instance of the data plane. Any timers set for the current instance of the
state machine are also cleared. The AC's Service thread is state machine are also cleared. The AC's Service thread is
skipping to change at page 33, line 37 skipping to change at page 33, line 23
available acceleration hardware, it is both convenient and forward- available acceleration hardware, it is both convenient and forward-
looking to maintain a modular distinction in this document. looking to maintain a modular distinction in this document.
This section describes a detailed walk-through of the interactions This section describes a detailed walk-through of the interactions
between the DTLS module and the CAPWAP module, via 'commands' (CAPWAP between the DTLS module and the CAPWAP module, via 'commands' (CAPWAP
to DTLS) and 'notifications' (DTLS to CAPWAP) as they would be to DTLS) and 'notifications' (DTLS to CAPWAP) as they would be
encountered during the normal course of operation. encountered during the normal course of operation.
2.4.1. DTLS Handshake Processing 2.4.1. DTLS Handshake Processing
Details of the DTLS handshake process are specified in [8]. This Details of the DTLS handshake process are specified in [RFC4347].
section describes the interactions between the DTLS session This section describes the interactions between the DTLS session
establishment process and the CAPWAP protocol. Note that the establishment process and the CAPWAP protocol. Note that the
conceptual DTLS state is shown below to help understand the point at conceptual DTLS state is shown below to help understand the point at
which the DTLS states transition. In the normal case, the DTLS which the DTLS states transition. In the normal case, the DTLS
handshake will proceed as follows (NOTE: this example uses handshake will proceed as follows (NOTE: this example uses
certificates, but preshared keys are also supported): certificates, but preshared keys are also supported):
============ ============ ============ ============
WTP AC WTP AC
============ ============ ============ ============
ClientHello ------> ClientHello ------>
skipping to change at page 36, line 45 skipping to change at page 36, line 45
2.4.4. DTLS EndPoint Authentication and Authorization 2.4.4. DTLS EndPoint Authentication and Authorization
DTLS supports endpoint authentication with certificates or preshared DTLS supports endpoint authentication with certificates or preshared
keys. The TLS algorithm suites for each endpoint authentication keys. The TLS algorithm suites for each endpoint authentication
method are described below. method are described below.
2.4.4.1. Authenticating with Certificates 2.4.4.1. Authenticating with Certificates
Note that only block ciphers are currently recommended for use with Note that only block ciphers are currently recommended for use with
DTLS. To understand the reasoning behind this, see [21]. At DTLS. To understand the reasoning behind this, see [DTLS-DESIGN].
present, the following algorithms MUST be supported when using At present, the following algorithms MUST be supported when using
certificates for CAPWAP authentication: certificates for CAPWAP authentication:
o TLS_RSA_WITH_AES_128_CBC_SHA o TLS_RSA_WITH_AES_128_CBC_SHA
The following algorithms SHOULD be supported when using certificates: The following algorithms SHOULD be supported when using certificates:
o TLS_DH_RSA_WITH_AES_128_CBC_SHA o TLS_DH_RSA_WITH_AES_128_CBC_SHA
The following algorithms MAY be supported when using certificates: The following algorithms MAY be supported when using certificates:
o TLS_RSA_WITH_AES_256_CBC_SHA o TLS_RSA_WITH_AES_256_CBC_SHA
o TLS_DH_RSA_WITH_AES_256_CBC_SHA o TLS_DH_RSA_WITH_AES_256_CBC_SHA
2.4.4.2. Authenticating with Preshared Keys 2.4.4.2. Authenticating with Preshared Keys
Pre-shared keys present significant challenges from a security Pre-shared keys present significant challenges from a security
perspective, and for that reason, their use is strongly discouraged. perspective, and for that reason, their use is strongly discouraged.
Several methods for authenticating with preshared keys are defined Several methods for authenticating with preshared keys are defined
[6], and we focus on the following two: [RFC4279], and we focus on the following two:
o PSK key exchange algorithm - simplest method, ciphersuites use o PSK key exchange algorithm - simplest method, ciphersuites use
only symmetric key algorithms only symmetric key algorithms
o DHE_PSK key exchange algorithm - use a PSK to authenticate a o DHE_PSK key exchange algorithm - use a PSK to authenticate a
Diffie-Hellman exchange. These ciphersuites give some additional Diffie-Hellman exchange. These ciphersuites give some additional
protection against dictionary attacks and also provide Perfect protection against dictionary attacks and also provide Perfect
Forward Secrecy (PFS). Forward Secrecy (PFS).
The first approach (plain PSK) is susceptible to passive dictionary The first approach (plain PSK) is susceptible to passive dictionary
skipping to change at page 38, line 6 skipping to change at page 38, line 6
o TLS_DHE_PSK_WITH_AES_256_CBC_SHA o TLS_DHE_PSK_WITH_AES_256_CBC_SHA
2.4.4.3. Certificate Usage 2.4.4.3. Certificate Usage
Certificate authorization by the AC and WTP is required so that only Certificate authorization by the AC and WTP is required so that only
an AC may perform the functions of an AC and that only a WTP may an AC may perform the functions of an AC and that only a WTP may
perform the functions of a WTP. This restriction of functions to the perform the functions of a WTP. This restriction of functions to the
AC or WTP requires that the certificates used by the AC MUST be AC or WTP requires that the certificates used by the AC MUST be
distinguishable from the certificate used by the WTP. To accomplish distinguishable from the certificate used by the WTP. To accomplish
this differentiation, the x.509 certificates MUST include the this differentiation, the x.509 certificates MUST include the
Extended Key Usage (EKU) certificate extension [4]. Extended Key Usage (EKU) certificate extension [RFC3280].
The EKU field indicates one or more purposes for which a certificate The EKU field indicates one or more purposes for which a certificate
may be used. It is an essential part in authorization. Its syntax may be used. It is an essential part in authorization. Its syntax
is as follows: is as follows:
ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId
KeyPurposeId ::= OBJECT IDENTIFIER KeyPurposeId ::= OBJECT IDENTIFIER
Here we define two KeyPurposeId values, one for the WTP and one for Here we define two KeyPurposeId values, one for the WTP and one for
skipping to change at page 38, line 29 skipping to change at page 38, line 29
formatted as id-kp fields. formatted as id-kp fields.
id-kp OBJECT IDENTIFIER ::= id-kp OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1) { iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) 3 } security(5) mechanisms(5) pkix(7) 3 }
id-kp-capwapAC OBJECT IDENTIFIER ::= { id-kp 18 } id-kp-capwapAC OBJECT IDENTIFIER ::= { id-kp 18 }
id-kp-capwapWTP OBJECT IDENTIFIER ::= { id-kp 19 } id-kp-capwapWTP OBJECT IDENTIFIER ::= { id-kp 19 }
For an AC, the id-kp-capwapAC EKU MUST be present in the certificate. All capwap devices MUST support the ExtendedKeyUsage certificate
For a WTP, the id-kp-capwapWTP EKU MUST be present in the extension if it is present in a certificate. If the extension is
certificate. The id-kp-anyExtendedKeyUsage, if present, SHOULD be present, then the certificate MUST have either the id-kp-capwapAC or
ignored. the id-kp-anyExtendedKeyUsage keyPurposeID to act as an AC.
Similarly, if the extension is present, a device must have the id-kp-
capwapWTP or id-kp-anyExtendedKeyUsage keyPurposeID to act as a WTP.
Part of the CAPWAP certificate validation process includes ensuring Part of the CAPWAP certificate validation process includes ensuring
that the proper EKU is included and allowing the CAPWAP session to be that the proper EKU is included and allowing the CAPWAP session to be
established only if the extension properly represents the device. established only if the extension properly represents the device.
For instance, an AC SHOULD NOT accept a connection request from For instance, an AC SHOULD NOT accept a connection request from
another AC, and therefore MUST verify that the id-kp-capwapWTP EKU is another AC, and therefore MUST verify that the id-kp-capwapWTP EKU is
present in the certificate. present in the certificate.
CAPWAP implementations MUST support certificates where the common CAPWAP implementations MUST support certificates where the common
name (CN) for both the WTP and AC is the MAC address of that device. name (CN) for both the WTP and AC is the MAC address of that device.
The MAC address MUST be formatted as ASCII HEX, e.g. The MAC address MUST be formatted as ASCII HEX, e.g.
01:23:45:67:89:ab. Note that the CN field MAY contain either of the 01:23:45:67:89:ab. Note that the CN field MAY contain either of the
EUI-48 [22] or EUI-64 [23] MAC Address formats. EUI-48 [EUI-48] or EUI-64 [EUI-64] MAC Address formats.
ACs and WTPs MUST authorize (e.g. through access control lists) ACs and WTPs MUST authorize (e.g. through access control lists)
certificates of devices to which they are connecting, e.g., based on certificates of devices to which they are connecting, e.g., based on
the issuer, MAC address, or organizational information specified in the issuer, MAC address, or organizational information specified in
the certificate. The identities specified in the certificates bind a the certificate. The identities specified in the certificates bind a
particular DTLS session to a specific pair of mutually-authenticated particular DTLS session to a specific pair of mutually-authenticated
and authorized MAC addresses. The particulars of authorization and authorized MAC addresses. The particulars of authorization
filter construction are implementation details which are, for the filter construction are implementation details which are, for the
most part, not within the scope of this specification. However, at most part, not within the scope of this specification. However, at
minimum, all devices MUST verify that the appropriate EKU bit is set minimum, all devices MUST verify that the appropriate EKU bit is set
skipping to change at page 40, line 9 skipping to change at page 40, line 9
If a single PSK is being used for multiple devices on a CAPWAP If a single PSK is being used for multiple devices on a CAPWAP
network, which is NOT RECOMMENDED, the PSK Hint and Identity can no network, which is NOT RECOMMENDED, the PSK Hint and Identity can no
longer be a MAC address, so appropriate hints and identities SHOULD longer be a MAC address, so appropriate hints and identities SHOULD
be selected to identify the group of devices to which the PSK is be selected to identify the group of devices to which the PSK is
provisioned. provisioned.
3. CAPWAP Transport 3. CAPWAP Transport
Communication between a WTP and an AC is established using the Communication between a WTP and an AC is established using the
standard UDP client/server model. The CAPWAP protocol supports both standard UDP client/server model. The CAPWAP protocol supports both
UDP and UDP-Lite [11] transport protocols. When run over IPv4, UDP UDP and UDP-Lite [RFC3828] transport protocols. When run over IPv4,
is used for the CAPWAP control and data channels. UDP is used for the CAPWAP control and data channels.
When run over IPv6, the CAPWAP control channel always uses UDP, while When run over IPv6, the CAPWAP control channel always uses UDP, while
the CAPWAP data channel may use either UDP or UDP-Lite. UDP-Lite is the CAPWAP data channel may use either UDP or UDP-Lite. UDP-Lite is
the default transport protocol for the CAPWAP data channel. However, the default transport protocol for the CAPWAP data channel. However,
if a middlebox or IPv4 to IPv6 gateway has been discovered, UDP is if a middlebox or IPv4 to IPv6 gateway has been discovered, UDP is
used for the CAPWAP data channel. used for the CAPWAP data channel.
This section describes how the CAPWAP protocol is carried over IP and This section describes how the CAPWAP protocol is carried over IP and
UDP/UDP-Lite transport protocols. The CAPWAP Transport Protocol UDP/UDP-Lite transport protocols. The CAPWAP Transport Protocol
message element Section 4.6.15 describes the rules to use in message element Section 4.6.15 describes the rules to use in
skipping to change at page 40, line 47 skipping to change at page 40, line 47
CAPWAP protocol data packets sent from the WTP to the AC use the CAPWAP protocol data packets sent from the WTP to the AC use the
CAPWAP data channel, as defined in Section 1.4. The CAPWAP data port CAPWAP data channel, as defined in Section 1.4. The CAPWAP data port
at the AC is the well known UDP port [to be IANA assigned]. The at the AC is the well known UDP port [to be IANA assigned]. The
CAPWAP data port at the WTP can be any port selected by the WTP. CAPWAP data port at the WTP can be any port selected by the WTP.
3.2. UDP-Lite Transport 3.2. UDP-Lite Transport
When CAPWAP is run over IPv6, UDP-Lite is the default transport When CAPWAP is run over IPv6, UDP-Lite is the default transport
protocol, which reduces the checksum processing required for each protocol, which reduces the checksum processing required for each
packet (compared to the use of UDP over IPv6 [13]). When UDP-Lite is packet (compared to the use of UDP over IPv6 [RFC1883]). When UDP-
used, the checksum field MUST have a coverage of 8 [11]. Lite is used, the checksum field MUST have a coverage of 8 [RFC3828].
UDP-Lite uses the same port assignments as UDP. UDP-Lite uses the same port assignments as UDP.
3.3. AC Discovery 3.3. AC Discovery
The AC discovery phase allows the WTP to determine which ACs are The AC discovery phase allows the WTP to determine which ACs are
available, and chose the best AC with which to establish a CAPWAP available, and chose the best AC with which to establish a CAPWAP
session. The discovery phase occurs when the WTP enters the optional session. The discovery phase occurs when the WTP enters the optional
Discovery state. A WTP does not need to complete the AC Discovery Discovery state. A WTP does not need to complete the AC Discovery
phase if it uses a pre-configured AC. This section details the phase if it uses a pre-configured AC. This section details the
skipping to change at page 41, line 40 skipping to change at page 41, line 40
WTP use of a limited IP broadcast, multicast or unicast IP address is WTP use of a limited IP broadcast, multicast or unicast IP address is
implementation dependent. implementation dependent.
When a WTP transmits a Discovery Request message to a unicast When a WTP transmits a Discovery Request message to a unicast
address, the WTP must first obtain the IP address of the AC. Any address, the WTP must first obtain the IP address of the AC. Any
static configuration of an AC's IP address on the WTP non-volatile static configuration of an AC's IP address on the WTP non-volatile
storage is implementation dependent. However, additional dynamic storage is implementation dependent. However, additional dynamic
schemes are possible, for example: schemes are possible, for example:
DHCP: See [17] for more information on the use of DHCP to discover DHCP: See [I-D.calhoun-dhc-capwap-ac-option] for more information on
AC IP addresses. the use of DHCP to discover AC IP addresses.
DNS: The DNS name "CAPWAP-AC-Address" MAY be resolvable to one or DNS: The DNS name "CAPWAP-AC-Address" MAY be resolvable to one or
more AC addresses. more AC addresses.
An AC MAY also communicate alternative ACs to the WTP within the An AC MAY also communicate alternative ACs to the WTP within the
Discovery Response message through the AC IPv4 List (see Discovery Response message through the AC IPv4 List (see
Section 4.6.2) and AC IPv6 List (see Section 4.6.2). The addresses Section 4.6.2) and AC IPv6 List (see Section 4.6.2). The addresses
provided in these two message elements are intended to help the WTP provided in these two message elements are intended to help the WTP
discover additional ACs through means other than those listed above. discover additional ACs through means other than those listed above.
skipping to change at page 42, line 37 skipping to change at page 42, line 37
component of the CAPWAP protocol becomes transparent to these component of the CAPWAP protocol becomes transparent to these
intermediate devices. Consequently, the CAPWAP protocol can be used intermediate devices. Consequently, the CAPWAP protocol can be used
in any network configuration. in any network configuration.
3.5. MTU Discovery 3.5. MTU Discovery
Once a WTP has discovered the AC it wishes to establish a CAPWAP Once a WTP has discovered the AC it wishes to establish a CAPWAP
session with, it SHOULD perform a Path MTU (PMTU) discovery. The MTU session with, it SHOULD perform a Path MTU (PMTU) discovery. The MTU
discovered is used to configure the DTLS component (see discovered is used to configure the DTLS component (see
Section 2.3.2.1), while non-DTLS frames need to be fragmented to fit Section 2.3.2.1), while non-DTLS frames need to be fragmented to fit
the MTU, defined in Section 3.4. The procedures described in [14], the MTU, defined in Section 3.4. The procedures described in
for IPv4, or [15], for IPv6 SHOULD be used. Alternatively, [RFC1191], for IPv4, or [RFC1981], for IPv6 SHOULD be used.
implementers MAY use the procedures defined in [12]. The WTP SHOULD Alternatively, implementers MAY use the procedures defined in
also periodically re-evaluate the MTU using the guidelines provided [RFC4821]. The WTP SHOULD also periodically re-evaluate the MTU
in these two RFCs. using the guidelines provided in these two RFCs.
4. CAPWAP Packet Formats 4. CAPWAP Packet Formats
This section contains the CAPWAP protocol packet formats. A CAPWAP This section contains the CAPWAP protocol packet formats. A CAPWAP
protocol packet consists of one or more CAPWAP Transport Layer packet protocol packet consists of one or more CAPWAP Transport Layer packet
headers followed by a CAPWAP message. The CAPWAP message can be headers followed by a CAPWAP message. The CAPWAP message can be
either of type Control or Data, where Control packets carry either of type Control or Data, where Control packets carry
signaling, and Data packets carry user payloads. The CAPWAP frame signaling, and Data packets carry user payloads. The CAPWAP frame
formats for CAPWAP Data packets, and for DTLS encapsulated CAPWAP formats for CAPWAP Data packets, and for DTLS encapsulated CAPWAP
Data and Control packets are defined below. Data and Control packets are defined below.
skipping to change at page 44, line 28 skipping to change at page 44, line 28
UDP Header: All CAPWAP packets are encapsulated within either UDP, UDP Header: All CAPWAP packets are encapsulated within either UDP,
or UDP-Lite when used over IPv6. Section 3 defines the specific or UDP-Lite when used over IPv6. Section 3 defines the specific
UDP or UDP-Lite usage. UDP or UDP-Lite usage.
CAPWAP DTLS Header: All DTLS encrypted CAPWAP protocol packets are CAPWAP DTLS Header: All DTLS encrypted CAPWAP protocol packets are
prefixed with the CAPWAP DTLS header (see Section 4.2). prefixed with the CAPWAP DTLS header (see Section 4.2).
DTLS Header: The DTLS header provides authentication and encryption DTLS Header: The DTLS header provides authentication and encryption
services to the CAPWAP payload it encapsulates. This protocol is services to the CAPWAP payload it encapsulates. This protocol is
defined in RFC 4347 [8]. defined in RFC 4347 [RFC4347].
CAPWAP Header: All CAPWAP protocol packets use a common header that CAPWAP Header: All CAPWAP protocol packets use a common header that
immediately follows the CAPWAP preamble or DTLS header. The immediately follows the CAPWAP preamble or DTLS header. The
CAPWAP Header is defined in Section 4.3. CAPWAP Header is defined in Section 4.3.
Wireless Payload: A CAPWAP protocol packet that contains a wireless Wireless Payload: A CAPWAP protocol packet that contains a wireless
payload is a CAPWAP data packet. The CAPWAP protocol does not payload is a CAPWAP data packet. The CAPWAP protocol does not
specify the format of the wireless payload, which is defined by specify the format of the wireless payload, which is defined by
the appropriate wireless standard. Additional information is in the appropriate wireless standard. Additional information is in
Section 4.4. Section 4.4.
skipping to change at page 45, line 48 skipping to change at page 45, line 48
1 - CAPWAP DTLS Header. The CAPWAP DTLS Header, and DTLS packet, 1 - CAPWAP DTLS Header. The CAPWAP DTLS Header, and DTLS packet,
immediately follows the UDP header (see Section 4.2). immediately follows the UDP header (see Section 4.2).
4.2. CAPWAP DTLS Header 4.2. CAPWAP DTLS Header
The CAPWAP DTLS Header is used to identify the packet as a DTLS The CAPWAP DTLS Header is used to identify the packet as a DTLS
encrypted packet. The first eight bits includes the common CAPWAP encrypted packet. The first eight bits includes the common CAPWAP
Preamble. The remaining 24 bits are padding to ensure 4 byte Preamble. The remaining 24 bits are padding to ensure 4 byte
alignment, and MAY be used in a future version of the protocol. The alignment, and MAY be used in a future version of the protocol. The
DTLS packet [8] always immediately follows this header. The format DTLS packet [RFC4347] always immediately follows this header. The
of the CAPWAP DTLS Header is as follows: format of the CAPWAP DTLS Header is as follows:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|CAPWAP Preamble| Reserved | |CAPWAP Preamble| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
CAPWAP Preamble: The CAPWAP Preamble is defined in Section 4.1. The CAPWAP Preamble: The CAPWAP Preamble is defined in Section 4.1. The
CAPWAP Preamble's Payload Type field MUST be set to one (1). CAPWAP Preamble's Payload Type field MUST be set to one (1).
skipping to change at page 49, line 4 skipping to change at page 49, line 4
field MUST be padded with zeroes (0x00) if it is not 4 byte field MUST be padded with zeroes (0x00) if it is not 4 byte
aligned. aligned.
The field contains the basic format: The field contains the basic format:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | MAC Address | Length | MAC Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length: The length of the MAC Address field [22] [23]. Length: The length of the MAC Address field [EUI-48] [EUI-64].
MAC Address: The MAC Address of the receiving radio. MAC Address: The MAC Address of the receiving radio.
Wireless Specific Information: This optional field contains Wireless Specific Information: This optional field contains
technology specific information that may be used to carry per technology specific information that may be used to carry per
packet wireless information. This field is only present if the packet wireless information. This field is only present if the
'W' bit is set. The WBID field in the CAPWAP header is used to 'W' bit is set. The WBID field in the CAPWAP header is used to
identify the format of the wireless specific information optional identify the format of the wireless specific information optional
field. The HLEN field assumes 4 byte alignment, and this field field. The HLEN field assumes 4 byte alignment, and this field
MUST be padded with zeroes (0x00) if it is not 4 byte aligned. MUST be padded with zeroes (0x00) if it is not 4 byte aligned.
skipping to change at page 51, line 21 skipping to change at page 51, line 21
For 802.3 payload frames, the 802.3 frame is encapsulated (excluding For 802.3 payload frames, the 802.3 frame is encapsulated (excluding
the IEEE 802.3 FCS checksum). If the encapsulated frame would exceed the IEEE 802.3 FCS checksum). If the encapsulated frame would exceed
the transport layer's MTU, the sender is responsible for the transport layer's MTU, the sender is responsible for
fragmentation of the frame, as specified in Section 3.4. fragmentation of the frame, as specified in Section 3.4.
4.4.3. Establishment of a DTLS Data Channel 4.4.3. Establishment of a DTLS Data Channel
If the AC and WTP are configured to tunnel the data channel over If the AC and WTP are configured to tunnel the data channel over
DTLS, the proper DTLS session must be initiated. To avoid having to DTLS, the proper DTLS session must be initiated. To avoid having to
reauthenticate and reauthorize an AC and WTP, the DTLS data channel reauthenticate and reauthorize an AC and WTP, the DTLS data channel
MUST be initiated using the TLS session resumption feature [7]. MUST be initiated using the TLS session resumption feature [RFC4346].
When establishing the DTLS-encrypted data channel, the WTP MUST When establishing the DTLS-encrypted data channel, the WTP MUST
provide the identifier returned during the initialization of the provide the identifier returned during the initialization of the
control channel to the DTLS component so it can perform the control channel to the DTLS component so it can perform the
resumption using the proper session information. resumption using the proper session information.
The AC DTLS implementation MUST NOT accept a session resumption The AC DTLS implementation MUST NOT accept a session resumption
request for a DTLS session in which the control channel for the request for a DTLS session in which the control channel for the
session has been torn down. session has been torn down.
skipping to change at page 62, line 49 skipping to change at page 62, line 49
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp | | Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 6 for AC Timestamp Type: 6 for AC Timestamp
Length: 4 Length: 4
Timestamp: The AC's current time, allowing all of the WTPs to be Timestamp: The AC's current time, allowing all of the WTPs to be
time synchronized in the format defined by Network Time Protocol time synchronized in the format defined by Network Time Protocol
(NTP) in RFC 1305 [3]. (NTP) in RFC 1305 [RFC1305].
4.6.7. Add MAC ACL Entry 4.6.7. Add MAC ACL Entry
The Add MAC Access Control List (ACL) Entry message element is used The Add MAC Access Control List (ACL) Entry message element is used
by an AC to add a MAC ACL list entry on a WTP, ensuring that the WTP by an AC to add a MAC ACL list entry on a WTP, ensuring that the WTP
no longer provides service to the MAC addresses provided in the no longer provides service to the MAC addresses provided in the
message. The MAC Addresses provided in this message element are not message. The MAC Addresses provided in this message element are not
expected to be saved in non-volatile memory on the WTP. expected to be saved in non-volatile memory on the WTP.
0 1 2 3 0 1 2 3
skipping to change at page 83, line 9 skipping to change at page 83, line 9
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor Identifier | | Vendor Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Element ID | Value... | | Element ID | Value... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 37 for Vendor Specific Type: 37 for Vendor Specific
Length: >= 7 Length: >= 7
Vendor Identifier: A 32-bit value containing the IANA assigned "SMI Vendor Identifier: A 32-bit value containing the IANA assigned "SMI
Network Management Private Enterprise Codes" [18] Network Management Private Enterprise Codes" [RFC3232]
Element ID: A 16-bit Element Identifier which is managed by the Element ID: A 16-bit Element Identifier which is managed by the
vendor. vendor.
Value: The value associated with the vendor specific element. Value: The value associated with the vendor specific element.
4.6.40. WTP Board Data 4.6.40. WTP Board Data
The WTP Board Data message element is sent by the WTP to the AC and The WTP Board Data message element is sent by the WTP to the AC and
contains information about the hardware present. contains information about the hardware present.
skipping to change at page 133, line 47 skipping to change at page 133, line 47
a resource shortage. If either the FailedDTLSSessionCount or the a resource shortage. If either the FailedDTLSSessionCount or the
FailedDTLSAuthFailCount counter reaches the value of FailedDTLSAuthFailCount counter reaches the value of
MaxFailedDTLSSessionRetry variable (see Section 4.8), implementations MaxFailedDTLSSessionRetry variable (see Section 4.8), implementations
MAY choose to rate-limit new DTLS handshakes for some period of time. MAY choose to rate-limit new DTLS handshakes for some period of time.
It is RECOMMENDED that implementations choosing to implement rate It is RECOMMENDED that implementations choosing to implement rate
limiting use a random discard technique, rather than mimicking the limiting use a random discard technique, rather than mimicking the
WTP's sulking behavior. This will ensure that messages from valid WTP's sulking behavior. This will ensure that messages from valid
WTPs will have some probability of eliciting a response, even in the WTPs will have some probability of eliciting a response, even in the
face of a significant DoS attack. face of a significant DoS attack.
Some implementations may wish to pass information about clients who Some CAPWAP implementations may wish to restrict the DTLS setup
have passed the discovery phase to the DTLS layer, authorizing only process to only those peers that have been configured in the access
those clients to initiate a DTLS handshake. Note that the impact of control list, authorizing only those clients to initiate a DTLS
this on mitigating denial of service attacks against the DTLS layer handshake. Note that the impact of this on mitigating denial of
is minimal, because DTLS already uses client-side cookies to minimize service attacks against the DTLS layer is minimal, because DTLS
processor consumption attacks. As a result, implementations SHOULD already uses client-side cookies to minimize processor consumption
NOT maintain state between the discovery and DTLS handshake phases of attacks.
the CAPWAP protocol initialization.
12.4. Interference with a DTLS Session 12.4. Interference with a DTLS Session
If a WTP or AC repeatedly receives packets which fail DTLS If a WTP or AC repeatedly receives packets which fail DTLS
authentication or decryption, this could indicate a DTLS authentication or decryption, this could indicate a DTLS
desynchronization between the AC and WTP, a link prone to desynchronization between the AC and WTP, a link prone to
undetectable bit errors, or an attacker trying to disrupt a DTLS undetectable bit errors, or an attacker trying to disrupt a DTLS
session. session.
In the state machine (section 2.3), transitions to the DTLS tear down In the state machine (section 2.3), transitions to the DTLS tear down
state can be triggered by frequently receiving DTLS packets with state can be triggered by frequently receiving DTLS packets with
authentication or decryption errors. The threshold or technique for authentication or decryption errors. The threshold or technique for
deciding when to move to the tear down state should be chosen deciding when to move to the tear down state should be chosen
carefully. Being able to easily transition to DTLS TD allows easy carefully. Being able to easily transition to DTLS TD allows easy
detection of malfunctioning devices, but allows for denial of service detection of malfunctioning devices, but allows for denial of service
attacks. Making it difficult to transition to DTLS TD prevents attacks. Making it difficult to transition to DTLS TD prevents
denial of service attacks, but makes it more difficult to detect and denial of service attacks, but makes it more difficult to detect and
reset a malfunctioning session. Implementers should set this policy reset a malfunctioning session. Implementers should set this policy
with care. with care.
12.5. Use of Preshared Keys in CAPWAP 12.5. CAPWAP Pre-Provisioning
In order for CAPWAP to establish a secure communication with a peer,
some level of pre-provisioning on both the WTP and AC is necessary.
This section will detail the minimal number of configuration
parameters.
When using preshared keys, it is necessary to configure the preshared
key for each possible peer with which a DTLS session may be
established. To support this mode of operation, one or more entries
of the following table may be configured on either the AC or WTP:
o Identity: The identity of the peering AC or WTP. This format MAY
be either in the form of an IP address or host name (the latter of
which needs to be resolved to an IP address using DNS).
o Key: The pre-shared key for use with the peer when establishing
the DTLS session (see Section 12.6 for more information).
o Key Identifier: The pre-shared key identifier, as described in RFC
4279 [RFC4279].
When using certificates, the following items need to be pre-
provisioned:
o Device Certificate: The local device's certificate (see
Section 12.7 for more information)
o Trust Anchor: Trusted root certificate chain used to validate any
certificate received from CAPWAP peers. Note that one or more
root certificate MAY be configured on a given device.
Regardless of the authentication method, the following items need to
be pre-provisioned:
o Access Control List: The access control list table contains the
identities of one or more CAPWAP peers, along with a rule. The
rule is used to determine whether communication with the peer is
permitted (see Section 2.4.4.3 for more information).
12.6. Use of Preshared Keys in CAPWAP
While use of preshared keys may provide deployment and provisioning While use of preshared keys may provide deployment and provisioning
advantages not found in public key based deployments, it also advantages not found in public key based deployments, it also
introduces a number of operational and security concerns. In introduces a number of operational and security concerns. In
particular, because the keys must typically be entered manually, it particular, because the keys must typically be entered manually, it
is common for people to base them on memorable words or phrases. is common for people to base them on memorable words or phrases.
These are referred to as "low entropy passwords/passphrases". These are referred to as "low entropy passwords/passphrases".
Use of low-entropy preshared keys, coupled with the fact that the Use of low-entropy preshared keys, coupled with the fact that the
keys are often not frequently updated, tends to significantly keys are often not frequently updated, tends to significantly
skipping to change at page 134, line 51 skipping to change at page 135, line 44
o When DTLS is used with a preshared-key (PSK) ciphersuite, each WTP o When DTLS is used with a preshared-key (PSK) ciphersuite, each WTP
SHOULD have a unique PSK. Since WTPs will likely be widely SHOULD have a unique PSK. Since WTPs will likely be widely
deployed, their physical security is not guaranteed. If PSKs are deployed, their physical security is not guaranteed. If PSKs are
not unique for each WTP, key reuse would allow the compromise of not unique for each WTP, key reuse would allow the compromise of
one WTP to result in the compromise of others one WTP to result in the compromise of others
o Generating PSKs from low entropy passwords is NOT RECOMMENDED. o Generating PSKs from low entropy passwords is NOT RECOMMENDED.
o It is RECOMMENDED that implementations that allow the o It is RECOMMENDED that implementations that allow the
administrator to manually configure the PSK also provide a administrator to manually configure the PSK also provide a
capability for generation of new random PSKs, taking RFC 4086 [2] capability for generation of new random PSKs, taking RFC 4086
into account. [RFC4086] into account.
o Preshared keys SHOULD be periodically updated. Implementations o Preshared keys SHOULD be periodically updated. Implementations
MAY facilitate this by providing an administrative interface for MAY facilitate this by providing an administrative interface for
automatic key generation and periodic update, or it MAY be automatic key generation and periodic update, or it MAY be
accomplished manually instead. accomplished manually instead.
Every pairwise combination of WTP and AC on the network SHOULD have a Every pairwise combination of WTP and AC on the network SHOULD have a
unique PSK. This prevents the domino effect (see Guidance for AAA unique PSK. This prevents the domino effect (see Guidance for AAA
Key Management [20]). If PSKs are tied to specific WTPs, then Key Management [I-D.housley-aaa-key-mgmt]). If PSKs are tied to
knowledge of the PSK implies a binding to a specified identity that specific WTPs, then knowledge of the PSK implies a binding to a
can be authorized. specified identity that can be authorized.
If PSKs are shared, this binding between device and identity is no If PSKs are shared, this binding between device and identity is no
longer possible. Compromise of one WTP can yield compromise of longer possible. Compromise of one WTP can yield compromise of
another WTP, violating the CAPWAP security hierarchy. Consequently, another WTP, violating the CAPWAP security hierarchy. Consequently,
sharing keys between WTPs is NOT RECOMMENDED. sharing keys between WTPs is NOT RECOMMENDED.
12.6. Use of Certificates in CAPWAP 12.7. Use of Certificates in CAPWAP
For public-key-based DTLS deployments, each device SHOULD have unique For public-key-based DTLS deployments, each device SHOULD have unique
credentials, with an extended key usage authorizing the device to act credentials, with an extended key usage authorizing the device to act
as either a WTP or AC. If devices do not have unique credentials, it as either a WTP or AC. If devices do not have unique credentials, it
is possible that by compromising one device, any other device using is possible that by compromising one device, any other device using
the same credential may also be considered to be compromised. the same credential may also be considered to be compromised.
Certificate validation involves checking a large variety of things. Certificate validation involves checking a large variety of things.
Since the necessary things to validate are often environment- Since the necessary things to validate are often environment-
specific, many are beyond the scope of this document. In this specific, many are beyond the scope of this document. In this
skipping to change at page 136, line 11 skipping to change at page 137, line 5
Proper validation of certificates typically requires checking to Proper validation of certificates typically requires checking to
ensure the certificate has not yet expired. If devices have a real- ensure the certificate has not yet expired. If devices have a real-
time clock, they SHOULD verify the certificate validity dates. If no time clock, they SHOULD verify the certificate validity dates. If no
real-time clock is available, the device SHOULD make a best-effort real-time clock is available, the device SHOULD make a best-effort
attempt to validate the certificate validity dates through other attempt to validate the certificate validity dates through other
means. Failure to check a certificate's temporal validity can make a means. Failure to check a certificate's temporal validity can make a
device vulnerable to man-in-the-middle attacks launched using device vulnerable to man-in-the-middle attacks launched using
compromised, expired certificates, and therefore devices should make compromised, expired certificates, and therefore devices should make
every effort to perform this validation. every effort to perform this validation.
12.7. AAA Security 12.8. AAA Security
The AAA protocol is used to distribute EAP keys to the ACs, and The AAA protocol is used to distribute EAP keys to the ACs, and
consequently its security is important to the overall system consequently its security is important to the overall system
security. When used with TLS or IPsec, security guidelines specified security. When used with TLS or IPsec, security guidelines specified
in RFC 3539 [5] SHOULD be followed. in RFC 3539 [RFC3539] SHOULD be followed.
In general, the link between the AC and AAA server SHOULD be secured In general, the link between the AC and AAA server SHOULD be secured
using a strong ciphersuite keyed with mutually authenticated session using a strong ciphersuite keyed with mutually authenticated session
keys. Implementations SHOULD NOT rely solely on Basic RADIUS shared keys. Implementations SHOULD NOT rely solely on Basic RADIUS shared
secret authentication as it is often vulnerable to dictionary secret authentication as it is often vulnerable to dictionary
attacks, but rather SHOULD use stronger underlying security attacks, but rather SHOULD use stronger underlying security
mechanisms. mechanisms.
13. Management Considerations 13. Management Considerations
skipping to change at page 139, line 21 skipping to change at page 140, line 21
IANA needs to assign an organization local multicast address called IANA needs to assign an organization local multicast address called
the "All ACs multicast address" from the IPv6 multicast address the "All ACs multicast address" from the IPv6 multicast address
registry in Section 3.3 registry in Section 3.3
15.1. CAPWAP Message Types 15.1. CAPWAP Message Types
The Message Type field in the CAPWAP header (Section 4.5.1.1) is used The Message Type field in the CAPWAP header (Section 4.5.1.1) is used
to identify the operation performed by the message. There are to identify the operation performed by the message. There are
multiple namespaces, which is identified via the first three octets multiple namespaces, which is identified via the first three octets
of the field containing the IANA Enterprise Number [10]. When the of the field containing the IANA Enterprise Number [RFC2434]. When
Enterprise Number is set to zero, the message types are reserved for the Enterprise Number is set to zero, the message types are reserved
use by the base CAPWAP specification which are controlled and for use by the base CAPWAP specification which are controlled and
maintained by IANA and requires a Standards Action. maintained by IANA and requires a Standards Action.
15.2. Wireless Binding Identifiers 15.2. Wireless Binding Identifiers
The Wireless Binding Identifier (WBID) field in the CAPWAP header The Wireless Binding Identifier (WBID) field in the CAPWAP header
(Section 4.3) is used to identify the wireless technology associated (Section 4.3) is used to identify the wireless technology associated
with the packet. Due to the limited address space available, a new with the packet. Due to the limited address space available, a new
WBID request requires Standards Action. WBID request requires Standards Action.
16. Acknowledgements 16. Acknowledgements
skipping to change at page 141, line 9 skipping to change at page 142, line 9
this protocol specification: Puneet Agarwal, Abhijit Choudhury, this protocol specification: Puneet Agarwal, Abhijit Choudhury,
Saravanan Govindan, Peter Nilsson, and David Perkins. Saravanan Govindan, Peter Nilsson, and David Perkins.
Michael Vakulenko contributed text to describe how CAPWAP can be used Michael Vakulenko contributed text to describe how CAPWAP can be used
over layer 3 (IP/UDP) networks. over layer 3 (IP/UDP) networks.
17. References 17. References
17.1. Normative References 17.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Eastlake, D., Schiller, J., and S. Crocker, "Randomness [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005. Requirements for Security", BCP 106, RFC 4086, June 2005.
[3] Mills, D., "Network Time Protocol (Version 3) Specification, [RFC1305] Mills, D., "Network Time Protocol (Version 3)
Implementation", RFC 1305, March 1992. Specification, Implementation", RFC 1305, March 1992.
[4] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
Public Key Infrastructure Certificate and Certificate X.509 Public Key Infrastructure Certificate and
Revocation List (CRL) Profile", RFC 3280, April 2002. Certificate Revocation List (CRL) Profile", RFC 3280,
April 2002.
[5] Aboba, B. and J. Wood, "Authentication, Authorization and [RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and
Accounting (AAA) Transport Profile", RFC 3539, June 2003. Accounting (AAA) Transport Profile", RFC 3539, June 2003.
[6] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites for [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites
Transport Layer Security (TLS)", RFC 4279, December 2005. for Transport Layer Security (TLS)", RFC 4279,
December 2005.
[7] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
Protocol Version 1.1", RFC 4346, April 2006. (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[8] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security", RFC 4347, April 2006. Security", RFC 4347, April 2006.
[9] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997. Extensions", RFC 2132, March 1997.
[10] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
Considerations Section in RFCs", BCP 26, RFC 2434, IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998. October 1998.
[11] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and G. [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and
Fairhurst, "The Lightweight User Datagram Protocol (UDP-Lite)", G. Fairhurst, "The Lightweight User Datagram Protocol
RFC 3828, July 2004. (UDP-Lite)", RFC 3828, July 2004.
[12] Mathis, M. and J. Heffner, "Packetization Layer Path MTU [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
Discovery", RFC 4821, March 2007. Discovery", RFC 4821, March 2007.
[13] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) [RFC1883] Deering, S. and R. Hinden, "Internet Protocol, Version 6
Specification", RFC 1883, December 1995. (IPv6) Specification", RFC 1883, December 1995.
[14] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
November 1990. November 1990.
[15] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
IP version 6", RFC 1981, August 1996. for IP version 6", RFC 1981, August 1996.
[16] Calhoun, P., "CAPWAP Protocol Binding for IEEE 802.11", [I-D.ietf-capwap-protocol-binding-ieee80211]
Calhoun, P., "CAPWAP Protocol Binding for IEEE 802.11",
draft-ietf-capwap-protocol-binding-ieee80211-06 (work in draft-ietf-capwap-protocol-binding-ieee80211-06 (work in
progress), February 2008. progress), February 2008.
[17] Calhoun, P., "CAPWAP Access Controller DHCP Option", [I-D.calhoun-dhc-capwap-ac-option]
draft-calhoun-dhc-capwap-ac-option-00 (work in progress), Calhoun, P., "CAPWAP Access Controller DHCP Option",
April 2007. draft-calhoun-dhc-capwap-ac-option-02 (work in progress),
March 2008.
17.2. Informational References 17.2. Informational References
[18] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On- [RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by
line Database", RFC 3232, January 2002. an On-line Database", RFC 3232, January 2002.
[19] Manner, J. and M. Kojo, "Mobility Related Terminology", [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004. RFC 3753, June 2004.
[20] Housley, R. and B. Aboba, "Guidance for AAA Key Management", [I-D.housley-aaa-key-mgmt]
draft-housley-aaa-key-mgmt-09 (work in progress), Housley, R. and B. Aboba, "Guidance for AAA Key
February 2007. Management", draft-housley-aaa-key-mgmt-09 (work in
progress), February 2007.
[21] Modadugu et al, N., "The Design and Implementation of Datagram [DTLS-DESIGN]
TLS", Feb 2004. Modadugu et al, N., "The Design and Implementation of
Datagram TLS", Feb 2004.
[22] IEEE, "Guidelines for use of a 48-bit Extended Unique [EUI-48] IEEE, "Guidelines for use of a 48-bit Extended Unique
Identifier", Dec 2005. Identifier", Dec 2005.
[23] IEEE, "GUIDELINES FOR 64-BIT GLOBAL IDENTIFIER (EUI-64) [EUI-64] IEEE, "GUIDELINES FOR 64-BIT GLOBAL IDENTIFIER (EUI-64)
REGISTRATION AUTHORITY". REGISTRATION AUTHORITY".
Editors' Addresses Editors' Addresses
Pat R. Calhoun Pat R. Calhoun
Cisco Systems, Inc. Cisco Systems, Inc.
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
Phone: +1 408-853-5269 Phone: +1 408-853-5269
skipping to change at page 144, line 44 skipping to change at line 6157
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 111 change blocks. 
271 lines changed or deleted 304 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/