| Re: Proposed Text: Issue 40: State Machine inconsistency around Discovery being optional | <– Date –> <– Thread –> |
From: Scott G. Kelly (s.kelly ix.netcom.com)
|
|
| Date: Thu, 13 Mar 2008 11:20:39 -0700 (PDT) | |
This looks fine to me. -----Original Message----- >From: "Pat Calhoun (pacalhou)" <pcalhoun [at] cisco.com> >Sent: Mar 12, 2008 11:33 AM >To: capwap [at] frascone.com >Subject: [Capwap] Proposed Text: Issue 40: State Machine inconsistency around >Discovery being optional > >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? >_________________________________________________________________ >To unsubscribe or modify your subscription options, please visit: >http://lists.frascone.com/mailman/listinfo/capwap > >Archives: http://lists.frascone.com/pipermail/capwap
- (no other messages in thread)
Results generated by Tiger Technologies using MHonArc.