| Proposed Text: Issue 40: State Machine inconsistency around Discovery being optional | <– Date –> <– Thread –> |
From: Pat Calhoun (pacalhou) (pcalhoun cisco.com)
|
|
| Date: Wed, 12 Mar 2008 11:33:16 -0700 (PDT) | |
All,
Following up on issue 40, which was created as a result of the
presentation made during the face to face in Philadelphia, I am
including here the proposed text. The issue, as described by Scott, was
that the text was inconsistent when it came to whether Discovery
Requests should be optional. Of note, the Listener state was expected to
call DTLSListen() when an event would occur, but if no Discovery
Requests were received, no event would cause the function to be called,
and therefore no incoming DTLS sessions would be accepted.
The fix is to introduce a new thread, called Discovery. It is
responsible for the handling of the Discovery Requests on the AC. The
listener thread now sits in DTLSListen(), and when a ClientHello has
been validated, a notification is received causing the state transition
to move to the Authorized state, which is the trigger that causes the
Listener thread to for a WTP specific Service thread.
Note that I am only including the modified text. The state labels were
changed, and I did not include the modified text that reflects that
because it would be too complex to identify the changes for issue 40.
As we agreed during the meeting, the plan is to submit the -10 version
by week's end so the chairs can start the WG last call. I would
appreciate a quick review.
<text>
2.3. CAPWAP State Machine Definition
[...]
/-------------------------------------\
| /-------------------------\|
| p| ||
| q+----------+ r +------------+ ||
| | Run |-->| Reset |-\||
| +----------+ +------------+ |||
n| o ^ ^ ^ s|||
+------------+--------/ | | |||
| Data Check | /-------/ | |||
+------------+<-------\ | | |||
| | | |||
/------------------+--------\ | |||
f| m| h| j v k| |||
+--------+ +-----------+ +--------------+|||
| Join |---->| Configure | | Image Data ||||
+--------+ n +-----------+ +--------------+|||
^ |g i| l| |||
| | \-------------------\ | |||
| \--------------------------------------\| | |||
\------------------------\ || | |||
/--------------<----------------+---------------\ || | |||
| /------------<----------------+-------------\ | || | |||
| | 4 |d t| | vv v vvv
| | +----------------+ +--------------+ +-----------+
| | | DTLS Setup | | DTLS Connect |-->| DTLS TD |
/-|-|---+----------------+ +--------------+ e +-----------+
| | | |$ ^ ^ |5 ^6 ^ ^ |w
v v v | | | | \-------\ | | |
| | | | | | \---------\ | | /-----------/ |
| | | | | \--\ | | | | |
| | | | | | | | | | |
| | | v 3| 1 |% # v | |a |b v
| | \->+------+-->+------+ +-----------+ +--------+
| | | Idle | | Disc | | Authorize | | Dead |
| | +------+<--+------+ +-----------+ +--------+
| | ^ 0^ 2 |!
| | | | | +-------+
*| |u | \---------+---| Start |
| | |@ | +-------+
| \->+---------+<------/
\--->| Sulking |
+---------+&
[...]
Since the WTP only communicates with a single AC, it only has a
single instance of the CAPWAP state machine. The state machine works
differently on the AC since it communicates with many WTPs. The AC
uses the concept of three threads. Note that the term thread used
here does not necessarily imply that implementers must use threads,
but it is one possible way of implementing the AC's state machine.
Listener Thread: The AC's Listener thread handles inbound DTLS
session establishment requests, through the DTLSListen command.
Upon creation, the Listener thread starts in the DTLS Setup state.
Once a DTLS session has been validated, which occurs when the
state machine enters the "Authorize" state, the Listener thread
creates a WTP session specific Service thread and state context.
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.
Discovery Thread: The AC's Discovery thread is responsible for
receiving, and responding to, Discovery Request messages. The
state machine transitions in figure Figure 3 are represented by
numerals. Note that the Discovery thread does not maintain any
per-WTP specific context information, and a single state context
exists. 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 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
[...]
Start to Idle (0): This transition occurs once device initialization
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
first Discovery Request message (see Section 5.1). Upon
entering this state, the WTP sets the DiscoveryInterval timer
(see Section 4.7). The WTP resets the DiscoveryCount counter
to zero (0) (see Section 4.8). The WTP also clears all
information from ACs it may have received during a previous
Discovery phase.
AC: This state transition is executed by the AC's Discovery
thread, and occurs when a Discovery Request message is
received. The AC SHOULD respond with a Discovery Response
message (see Section 5.2).
[...]
Discovery to Idle (2): This transition occurs on the AC's Discovery
thread when the Discovery processing is complete.
WTP: This is an invalid state transition for the WTP.
AC: This state transition is executed by the AC's Discovery
thread when it has transmitted the Discovery Response, in
response to a Discovery Request.
[...]
Idle to DTLS Setup (3): This transition occurs to establish a secure
DTLS session with the peer.
WTP: The WTP initiates this transition by invoking the DTLSStart
command, which starts the DTLS session establishment with the
chosen AC. When the discovery phase is bypassed, it is assumed
the WTP has locally configured ACs.
AC: Upon entering the Idle state from the Start state, the newly
created Listener thread automatically transitions to the DTLS
Setup and invokes the DTLSListen command (see Section 2.3.2.1).
[...]
DTLS Setup to DTLS Setup (4): This transition occurs when the DTLS
Session failed to be established.
WTP: This is an invalid state transition for the WTP.
AC: The AC's Listener 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 Listener thread then invokes the DTLSListen command (see
Section 2.3.2.1).
DTLS Setup to Authorize (5): This transition occurs when an incoming
DTLS session is being established, and the DTLS stack needs
authorization to proceed with the session establishment.
WTP: This state transition occurs when the WTP receives the
DTLSPeerAuthorize notification (see Section 2.3.2.2). Upon
entering this state, the WTP performs an authorization check
against the AC credentials. See Section 2.4.4 for more
information on AC authorization.
AC: This state transition is handled by the AC's Listener thread
when the DTLS module initiates the DTLSPeerAuthorize
notification (see Section 2.3.2.2). The Listener thread forks
an instance of the Service thread, along with a copy of the
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 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).
[...]
12.3. Discovery or DTLS Setup Attacks
[...]
Some CAPWAP implementations may wish to restrict the DTLS setup
process to only those peers that have been configured in the access
control list, authorizing only those clients to initiate a DTLS
handshake. Note that the impact of this on mitigating denial of
service attacks against the DTLS layer is minimal, because DTLS
already uses client-side cookies to minimize processor consumption
attacks.
</text>
Further, in the process of making this change, two state transitions
were removed (one of them was actually duplicative. Here is the removed
text from -09.
<removed text>
DTLS Connect to DTLS Teardown (7): This transition occurs when the
DTLS Session failed to be established.
WTP: This state transition occurs when the WTP receives either a
DTLSAborted or DTLSAuthenticateFail notification (see
Section 2.3.2.2), indicating that the DTLS session was not
successfully established. When this transition occurs due to
the DTLSAuthenticateFail notification, the
FailedDTLSAuthFailCount is incremented, otherwise the
FailedDTLSSessionCount counter is incremented.
AC: This is an invalid state transition for the AC.
DTLS Connect to Dead (j): 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).
</removed text>
Comments?
- (no other messages in thread)
Results generated by Tiger Technologies using MHonArc.